Re: let vlan(4) mtu be limited by the parents hardmtu instead of current mtu
> On 20 Aug 2014, at 9:54 am, David Gwynne wrote:
>
> this lets you have networks on the "native" vlan on an interface
> at 1500, while setting a child vlan interfaces mtu to jumbos.
>
> ok?
how about now?
i believe both ix and oce unconditionally set their mru now, and it's the start
of the cycle.
ok?
>
> Index: if_vlan.c
> ===
> RCS file: /cvs/src/sys/net/if_vlan.c,v
> retrieving revision 1.108
> diff -u -p -r1.108 if_vlan.c
> --- if_vlan.c 12 Jul 2014 18:44:22 - 1.108
> +++ if_vlan.c 19 Aug 2014 23:52:15 -
> @@ -528,9 +528,9 @@ vlan_ioctl(struct ifnet *ifp, u_long cmd
> case SIOCSIFMTU:
> if (ifv->ifv_p != NULL) {
> if (ifv->ifv_p->if_capabilities & IFCAP_VLAN_MTU)
> - p_mtu = ifv->ifv_p->if_mtu;
> + p_mtu = ifv->ifv_p->if_hardmtu;
> else
> - p_mtu = ifv->ifv_p->if_mtu - EVL_ENCAPLEN;
> + p_mtu = ifv->ifv_p->if_hardmtu - EVL_ENCAPLEN;
>
> if (ifr->ifr_mtu > p_mtu || ifr->ifr_mtu < ETHERMIN)
> error = EINVAL;
Re: let vlan(4) mtu be limited by the parents hardmtu instead of current mtu
On 27 August 2014 13:23, David Gwynne wrote: > On Tue, Aug 26, 2014 at 09:11:14PM -0400, Brad Smith wrote: >> On 20/08/14 8:03 PM, David Gwynne wrote: >> >sthen@ says this is likely a bit optimistic. while most of our drivers >> >unconditionally configure their max mru, there's some stupid ones that >> >still interpret the configured mtu as a what the mru should be. >> > >> >dlg >> >> oce(4) and ix(4) need to be fixed. > > this might fix oce. can anyone test? > works fine here. i think we can go with this one. OK mikeb
Re: let vlan(4) mtu be limited by the parents hardmtu instead of current mtu
On 27 August 2014 13:17, David Gwynne wrote: > On Tue, Aug 26, 2014 at 09:11:14PM -0400, Brad Smith wrote: >> On 20/08/14 8:03 PM, David Gwynne wrote: >> >sthen@ says this is likely a bit optimistic. while most of our drivers >> >unconditionally configure their max mru, there's some stupid ones that >> >still interpret the configured mtu as a what the mru should be. >> > >> >dlg >> >> oce(4) and ix(4) need to be fixed. > > this might fix ix(4). anyone able to test? > ix and oce (internally though) calculate various paramethers related to flow control, internal buffer sizes and so on based on the maximum frame size. therefore if i set max frame size to 16k but always use 1,5k all these calculations will be off. and by killing SIOCSIFMTU you make it impossible for the driver to readjust them. we have no idea at the moment how will this affect nic's behavior. pieces of such black magic such as the code under /* Hardware Packet Buffer & Flow Control setup */ comment must be studied before making such changes. and as i've mentioned to dlg, ix diff also switches it to using 16k cluster pool no matter what you actually need. this can be changed, but needs testing (i'm doing it now).
Re: let vlan(4) mtu be limited by the parents hardmtu instead of current mtu
On Tue, Aug 26, 2014 at 09:11:14PM -0400, Brad Smith wrote:
> On 20/08/14 8:03 PM, David Gwynne wrote:
> >sthen@ says this is likely a bit optimistic. while most of our drivers
> >unconditionally configure their max mru, there's some stupid ones that still
> >interpret the configured mtu as a what the mru should be.
> >
> >dlg
>
> oce(4) and ix(4) need to be fixed.
this might fix oce. can anyone test?
Index: if_oce.c
===
RCS file: /cvs/src/sys/dev/pci/if_oce.c,v
retrieving revision 1.78
diff -u -p -r1.78 if_oce.c
--- if_oce.c14 Aug 2014 09:52:03 - 1.78
+++ if_oce.c27 Aug 2014 11:21:53 -
@@ -879,14 +879,6 @@ oce_ioctl(struct ifnet *ifp, u_long comm
oce_stop(sc);
}
break;
- case SIOCSIFMTU:
- if (ifr->ifr_mtu < OCE_MIN_MTU || ifr->ifr_mtu > OCE_MAX_MTU)
- error = EINVAL;
- else if (ifp->if_mtu != ifr->ifr_mtu) {
- ifp->if_mtu = ifr->ifr_mtu;
- oce_init(sc);
- }
- break;
case SIOCGIFMEDIA:
case SIOCSIFMEDIA:
error = ifmedia_ioctl(ifp, ifr, &sc->sc_media, command);
@@ -1084,7 +1076,7 @@ oce_init(void *arg)
goto error;
OCE_RQ_FOREACH(sc, rq, i) {
- rq->mtu = ifp->if_mtu + ETHER_HDR_LEN + ETHER_CRC_LEN +
+ rq->mtu = ifp->if_hardmtu + ETHER_HDR_LEN + ETHER_CRC_LEN +
ETHER_VLAN_ENCAP_LEN;
if (oce_new_rq(sc, rq)) {
printf("%s: failed to create rq\n",
Re: let vlan(4) mtu be limited by the parents hardmtu instead of current mtu
On Tue, Aug 26, 2014 at 09:11:14PM -0400, Brad Smith wrote:
> On 20/08/14 8:03 PM, David Gwynne wrote:
> >sthen@ says this is likely a bit optimistic. while most of our drivers
> >unconditionally configure their max mru, there's some stupid ones that still
> >interpret the configured mtu as a what the mru should be.
> >
> >dlg
>
> oce(4) and ix(4) need to be fixed.
this might fix ix(4). anyone able to test?
Index: if_ix.c
===
RCS file: /cvs/src/sys/dev/pci/if_ix.c,v
retrieving revision 1.99
diff -u -p -r1.99 if_ix.c
--- if_ix.c 26 Aug 2014 11:01:22 - 1.99
+++ if_ix.c 27 Aug 2014 11:16:53 -
@@ -441,18 +441,6 @@ ixgbe_ioctl(struct ifnet * ifp, u_long c
#endif
break;
- case SIOCSIFMTU:
- IOCTL_DEBUGOUT("ioctl: SIOCSIFMTU (Set Interface MTU)");
- if (ifr->ifr_mtu < ETHERMIN || ifr->ifr_mtu > ifp->if_hardmtu)
- error = EINVAL;
- else if (ifp->if_mtu != ifr->ifr_mtu) {
- ifp->if_mtu = ifr->ifr_mtu;
- sc->max_frame_size =
- ifp->if_mtu + ETHER_HDR_LEN + ETHER_CRC_LEN;
- ixgbe_init(sc);
- }
- break;
-
case SIOCSIFFLAGS:
IOCTL_DEBUGOUT("ioctl: SIOCSIFFLAGS (Set Interface Flags)");
if (ifp->if_flags & IFF_UP) {
@@ -690,7 +678,7 @@ ixgbe_init(void *arg)
IXGBE_WRITE_REG(&sc->hw, IXGBE_GPIE, gpie);
/* Set MTU size */
- if (ifp->if_mtu > ETHERMTU) {
+ if (ifp->if_hardmtu > ETHERMTU) {
mhadd = IXGBE_READ_REG(&sc->hw, IXGBE_MHADD);
mhadd &= ~IXGBE_MHADD_MFS_MASK;
mhadd |= sc->max_frame_size << IXGBE_MHADD_MFS_SHIFT;
@@ -1596,7 +1584,7 @@ ixgbe_setup_interface(struct ix_softc *s
ether_ifattach(ifp);
sc->max_frame_size =
- ifp->if_mtu + ETHER_HDR_LEN + ETHER_CRC_LEN;
+ ifp->if_hardmtu + ETHER_HDR_LEN + ETHER_CRC_LEN;
}
void
@@ -2680,7 +2668,7 @@ ixgbe_initialize_receive_units(struct ix
/* Set for Jumbo Frames? */
hlreg = IXGBE_READ_REG(&sc->hw, IXGBE_HLREG0);
- if (ifp->if_mtu > ETHERMTU)
+ if (ifp->if_hardmtu > ETHERMTU)
hlreg |= IXGBE_HLREG0_JUMBOEN;
else
hlreg &= ~IXGBE_HLREG0_JUMBOEN;
Re: let vlan(4) mtu be limited by the parents hardmtu instead of current mtu
On 20/08/14 8:03 PM, David Gwynne wrote: sthen@ says this is likely a bit optimistic. while most of our drivers unconditionally configure their max mru, there's some stupid ones that still interpret the configured mtu as a what the mru should be. dlg oce(4) and ix(4) need to be fixed. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: let vlan(4) mtu be limited by the parents hardmtu instead of current mtu
Stuart Henderson [st...@openbsd.org] wrote: > On 2014/08/21 08:45, Chris Cappuccio wrote: > > Stuart Henderson [st...@openbsd.org] wrote: > > > On 2014/08/20 17:17, Chris Cappuccio wrote: > > > > David Gwynne [da...@gwynne.id.au] wrote: > > > > > sthen@ says this is likely a bit optimistic. while most of our > > > > > drivers unconditionally configure their max mru, there's some stupid > > > > > ones that still interpret the configured mtu as a what the mru should > > > > > be. > > > > > > > > > > > > > All the more reason to make this change, I'd say :) > > > > > > it's not just that - there are some like et(4) with obvious trade-offs > > > visible > > > in the driver source code which are only wanted in the case where jumbos > > > are > > > actually in use. and who knows what various chips will do internally when > > > the > > > command to permit jumbos or raise the valid packet size is sent. > > > > > > > I don't think this is relevant. If a chip or driver is buggy in the jumbo > > MTU > > non-vlan case, now it will be buggy in the (somewhat unique) vlan jumbo MTU > > case as well > > Oh I was thinking of the case where we changed those drivers to fix things > so that the "1500 MTU untagged / high MTU tagged" state worked which would > involve downsides for non-jumbo. If you don't care if the new support > actually works on some chips then that wouldn't apply.. > Well in the case of if_et, the change the dlg proposes in if_vlan would not make a difference to the if_et behavior at all. My first glance at et says hardmtu == mtu
Re: let vlan(4) mtu be limited by the parents hardmtu instead of current mtu
On 2014/08/21 08:45, Chris Cappuccio wrote: > Stuart Henderson [st...@openbsd.org] wrote: > > On 2014/08/20 17:17, Chris Cappuccio wrote: > > > David Gwynne [da...@gwynne.id.au] wrote: > > > > sthen@ says this is likely a bit optimistic. while most of our drivers > > > > unconditionally configure their max mru, there's some stupid ones that > > > > still interpret the configured mtu as a what the mru should be. > > > > > > > > > > All the more reason to make this change, I'd say :) > > > > it's not just that - there are some like et(4) with obvious trade-offs > > visible > > in the driver source code which are only wanted in the case where jumbos are > > actually in use. and who knows what various chips will do internally when > > the > > command to permit jumbos or raise the valid packet size is sent. > > > > I don't think this is relevant. If a chip or driver is buggy in the jumbo MTU > non-vlan case, now it will be buggy in the (somewhat unique) vlan jumbo MTU > case as well Oh I was thinking of the case where we changed those drivers to fix things so that the "1500 MTU untagged / high MTU tagged" state worked which would involve downsides for non-jumbo. If you don't care if the new support actually works on some chips then that wouldn't apply.. > > that said, there is a clear use case for being able to do 1500 MTU packets > > untagged while using jumbos on a vlan... > > Yeah >
Re: let vlan(4) mtu be limited by the parents hardmtu instead of current mtu
Stuart Henderson [st...@openbsd.org] wrote: > On 2014/08/20 17:17, Chris Cappuccio wrote: > > David Gwynne [da...@gwynne.id.au] wrote: > > > sthen@ says this is likely a bit optimistic. while most of our drivers > > > unconditionally configure their max mru, there's some stupid ones that > > > still interpret the configured mtu as a what the mru should be. > > > > > > > All the more reason to make this change, I'd say :) > > it's not just that - there are some like et(4) with obvious trade-offs visible > in the driver source code which are only wanted in the case where jumbos are > actually in use. and who knows what various chips will do internally when the > command to permit jumbos or raise the valid packet size is sent. > I don't think this is relevant. If a chip or driver is buggy in the jumbo MTU non-vlan case, now it will be buggy in the (somewhat unique) vlan jumbo MTU case as well > that said, there is a clear use case for being able to do 1500 MTU packets > untagged while using jumbos on a vlan... Yeah
Re: let vlan(4) mtu be limited by the parents hardmtu instead of current mtu
On 2014/08/20 17:17, Chris Cappuccio wrote: > David Gwynne [da...@gwynne.id.au] wrote: > > sthen@ says this is likely a bit optimistic. while most of our drivers > > unconditionally configure their max mru, there's some stupid ones that > > still interpret the configured mtu as a what the mru should be. > > > > All the more reason to make this change, I'd say :) it's not just that - there are some like et(4) with obvious trade-offs visible in the driver source code which are only wanted in the case where jumbos are actually in use. and who knows what various chips will do internally when the command to permit jumbos or raise the valid packet size is sent. that said, there is a clear use case for being able to do 1500 MTU packets untagged while using jumbos on a vlan...
Re: let vlan(4) mtu be limited by the parents hardmtu instead of current mtu
David Gwynne [da...@gwynne.id.au] wrote: > sthen@ says this is likely a bit optimistic. while most of our drivers > unconditionally configure their max mru, there's some stupid ones that still > interpret the configured mtu as a what the mru should be. > All the more reason to make this change, I'd say :)
Re: let vlan(4) mtu be limited by the parents hardmtu instead of current mtu
sthen@ says this is likely a bit optimistic. while most of our drivers
unconditionally configure their max mru, there's some stupid ones that still
interpret the configured mtu as a what the mru should be.
dlg
On 21 Aug 2014, at 6:29, Chris Cappuccio wrote:
> ok chris@
>
> David Gwynne [da...@gwynne.id.au] wrote:
>> this lets you have networks on the "native" vlan on an interface
>> at 1500, while setting a child vlan interfaces mtu to jumbos.
>>
>> ok?
>>
>> Index: if_vlan.c
>> ===
>> RCS file: /cvs/src/sys/net/if_vlan.c,v
>> retrieving revision 1.108
>> diff -u -p -r1.108 if_vlan.c
>> --- if_vlan.c12 Jul 2014 18:44:22 - 1.108
>> +++ if_vlan.c19 Aug 2014 23:52:15 -
>> @@ -528,9 +528,9 @@ vlan_ioctl(struct ifnet *ifp, u_long cmd
>> case SIOCSIFMTU:
>> if (ifv->ifv_p != NULL) {
>> if (ifv->ifv_p->if_capabilities & IFCAP_VLAN_MTU)
>> -p_mtu = ifv->ifv_p->if_mtu;
>> +p_mtu = ifv->ifv_p->if_hardmtu;
>> else
>> -p_mtu = ifv->ifv_p->if_mtu - EVL_ENCAPLEN;
>> +p_mtu = ifv->ifv_p->if_hardmtu - EVL_ENCAPLEN;
>>
>> if (ifr->ifr_mtu > p_mtu || ifr->ifr_mtu < ETHERMIN)
>> error = EINVAL;
Re: let vlan(4) mtu be limited by the parents hardmtu instead of current mtu
ok chris@
David Gwynne [da...@gwynne.id.au] wrote:
> this lets you have networks on the "native" vlan on an interface
> at 1500, while setting a child vlan interfaces mtu to jumbos.
>
> ok?
>
> Index: if_vlan.c
> ===
> RCS file: /cvs/src/sys/net/if_vlan.c,v
> retrieving revision 1.108
> diff -u -p -r1.108 if_vlan.c
> --- if_vlan.c 12 Jul 2014 18:44:22 - 1.108
> +++ if_vlan.c 19 Aug 2014 23:52:15 -
> @@ -528,9 +528,9 @@ vlan_ioctl(struct ifnet *ifp, u_long cmd
> case SIOCSIFMTU:
> if (ifv->ifv_p != NULL) {
> if (ifv->ifv_p->if_capabilities & IFCAP_VLAN_MTU)
> - p_mtu = ifv->ifv_p->if_mtu;
> + p_mtu = ifv->ifv_p->if_hardmtu;
> else
> - p_mtu = ifv->ifv_p->if_mtu - EVL_ENCAPLEN;
> + p_mtu = ifv->ifv_p->if_hardmtu - EVL_ENCAPLEN;
>
> if (ifr->ifr_mtu > p_mtu || ifr->ifr_mtu < ETHERMIN)
> error = EINVAL;
let vlan(4) mtu be limited by the parents hardmtu instead of current mtu
this lets you have networks on the "native" vlan on an interface
at 1500, while setting a child vlan interfaces mtu to jumbos.
ok?
Index: if_vlan.c
===
RCS file: /cvs/src/sys/net/if_vlan.c,v
retrieving revision 1.108
diff -u -p -r1.108 if_vlan.c
--- if_vlan.c 12 Jul 2014 18:44:22 - 1.108
+++ if_vlan.c 19 Aug 2014 23:52:15 -
@@ -528,9 +528,9 @@ vlan_ioctl(struct ifnet *ifp, u_long cmd
case SIOCSIFMTU:
if (ifv->ifv_p != NULL) {
if (ifv->ifv_p->if_capabilities & IFCAP_VLAN_MTU)
- p_mtu = ifv->ifv_p->if_mtu;
+ p_mtu = ifv->ifv_p->if_hardmtu;
else
- p_mtu = ifv->ifv_p->if_mtu - EVL_ENCAPLEN;
+ p_mtu = ifv->ifv_p->if_hardmtu - EVL_ENCAPLEN;
if (ifr->ifr_mtu > p_mtu || ifr->ifr_mtu < ETHERMIN)
error = EINVAL;
