New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tap(4): allow full-duplex and non-zero speed #745
Conversation
hey @snar ; i just found your Patch in Bugzilla and thought resurrecting it here would be better. |
If this is an updated version of the patch originally submitted in the PR then we ought to use the |
@emaste all I've done is moved the original author's patch into the new file. |
tap(4) devices advertise themselves as just 'ethernet autoselect', without duplex or speed capabilities. This advertisement makes them unable to be aggregated into lacp-based lagg(4): - lacp code requires underlying interfaces to be full-duplex, else interface will not participate in lacp at all - lacp code requires underlying interface to have non-zero speed, else this interface can not be selected as active aggregator PR#: 217374 Reported by: Alexandre Snarskii <snar@snar.spb.ru> Co-authored-by: Mina Galić <freebsd@igalic.co>
83ab603
to
10991aa
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Basically looks good to me.
@@ -1341,7 +1341,7 @@ tunifioctl(struct ifnet *ifp, u_long cmd, caddr_t data) | |||
dummy = ifmr->ifm_count; | |||
ifmr->ifm_count = 1; | |||
ifmr->ifm_status = IFM_AVALID; | |||
ifmr->ifm_active = IFM_ETHER; | |||
ifmr->ifm_active = IFM_ETHER | IFM_FDX | IFM_1000_T; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer 10Gbps, although higher is also possible but this keeps align with some virtual interfaces such as epair.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
netgtaph and ether switch use IFM_1000_T, so we should bump then as well
(and vxlan doesn't set a limit… hmmmm)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A common frontend vtnet (virtio-net) advertise it as Ethernet autoselect (10Gbase-T <full-duplex>)
and there is no choices for supported media
, so I think it should be IFM_10G_T
.
root@freebsd:~ # ifconfig -m vtnet0
vtnet0: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=80028<VLAN_MTU,JUMBO_MTU,LINKSTATE>
capabilities=90028<VLAN_MTU,JUMBO_MTU,VLAN_HWFILTER,LINKSTATE>
ether 52:54:00:12:34:56
inet 192.168.99.31 netmask 0xffffff00 broadcast 192.168.99.255
media: Ethernet autoselect (10Gbase-T <full-duplex>)
status: active
supported media:
media autoselect
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
I'll test and report later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Test looks good, except the default if_baudrate
(of tap interface) is not set correspondingly.
# ifconfig
tap0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=80000<LINKSTATE>
ether 8a:d6:1b:7f:b6:28
groups: tap
media: Ethernet 10Gbase-T <full-duplex>
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
Opened by PID 56600
tap1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=80000<LINKSTATE>
ether 8a:d6:1b:7f:b6:28
hwaddr 6e:b3:f0:23:3d:9c
groups: tap
media: Ethernet 10Gbase-T <full-duplex>
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
Opened by PID 56600
lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=80000<LINKSTATE>
ether 8a:d6:1b:7f:b6:28
inet 192.168.199.1 netmask 0xffffff00 broadcast 192.168.199.255
laggproto lacp lagghash l2,l3,l4
laggport: tap0 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
laggport: tap1 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
groups: lagg
media: Ethernet autoselect
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ng does a much better job doing all of this, but it also sets every negotiable speed.
I also don't see how to access ifmedia
from the point at which baudrate is set in tuntap.
I think this might need more refactoring to do right then.
tap(4) devices advertise themselves as just 'ethernet autoselect', without duplex or speed capabilities. This advertisement makes them unable to be aggregated into lacp-based lagg(4): - lacp code requires underlying interfaces to be full-duplex, else interface will not participate in lacp at all - lacp code requires underlying interface to have non-zero speed, else this interface can not be selected as active aggregator PR: 217374 Reported-by: Alexandre Snarskii <snar@snar.spb.ru> Co-authored-by: Mina Galić <freebsd@igalic.co> Reviewed-by: imp,karles Pull-request: #745
I've landed this patch, even though it's imperfect in the review. It helps many things, though a future version could help even more. I'll let that future version be submitted when it's ready. |
tap(4) devices advertise themselves as just 'ethernet autoselect', without duplex or speed capabilities. This advertisement makes them unable to be aggregated into lacp-based lagg(4): - lacp code requires underlying interfaces to be full-duplex, else interface will not participate in lacp at all - lacp code requires underlying interface to have non-zero speed, else this interface can not be selected as active aggregator PR: 217374 Reported-by: Alexandre Snarskii <snar@snar.spb.ru> Co-authored-by: Mina Galić <freebsd@igalic.co> Reviewed-by: imp,karles Pull-request: freebsd/freebsd-src#745
tap(4) devices advertise themselves as just 'ethernet autoselect', without duplex or speed capabilities.
This advertisement makes them unable to be aggregated into lacp-based lagg(4):
PR#: 217374
Reported by: Alexandre Snarskii snar@snar.spb.ru
Co-authored-by: Mina Galić freebsd@igalic.co