+5
−12
+32
−28
Loading
Gitlab 现已全面支持 git over ssh 与 git over https。通过 HTTPS 访问请配置带有 read_repository / write_repository 权限的 Personal access token。通过 SSH 端口访问请使用 22 端口或 13389 端口。如果使用CAS注册了账户但不知道密码,可以自行至设置中更改;如有其他问题,请发邮件至 service@cra.moe 寻求协助。
Vlad Yasevich says:
====================
Add packet capture support on macvtap device
Change from RFC:
- moved to the rx_handler approach.
This series adds support for packet capturing on macvtap device.
The initial approach was to simply export the capturing code as
a function from the core network. While simple, it was not
a very architecturally clean approach.
The new appraoch is to provide macvtap with its rx_handler which can
is attached to the macvtap device itself. Macvlan will simply requeue
the packet with an updated skb->dev. BTW, macvlan layer already does this
for macvlan devices. So, now macvtap and macvlan have almost the
same exact input path.
I've toyed with short-circuting the input path for macvtap by returning
RX_HANDLER_ANOTHER, but that just made the code more complicated and
didn't provide any kind of measurable gain (at least according to
netperf and perf runs on the host).
To see if there was a performance regression, I ran 1, 2 and 4 netperf
STREAM and MAERTS tests agains the VM from both remote host and another
guest on the same system. The command ran was
netperf -H $host -t $test -l 20 -i 10 -I 95 -c -C
The numbers I was getting with the new code were consistently very
slightly (1-2%) better then the old code. I don't consider this
an improvement, but it's not a regression! :)
Running 'perf record' on the host didn't show any new hot spots
and cpu utilization stayed about the same. This was better
then I expected from simply looking at the code.
====================
Signed-off-by:
David S. Miller <davem@davemloft.net>
CRA Git | Maintained and supported by SUSTech CRA and CCSE