Re: DSA vs envelope frames
On 2016/11/30 23:58, Nikita Yushchenko wrote: >>> (1) When DSA is in use, frames processed by FEC chip contain DSA tag and >>> thus can be larger than hardcoded limit of 1522. This issue is not >>> FEC-specific, any driver that hardcodes maximum frame size to 1522 (many >>> do) will have this issue if used with DSA. >> >> BTW I'm trying to introduce envelope frames to solve this kind of problems. >> http://marc.info/?t=14749669155=1=2 >> http://marc.info/?t=14749669153=1=2 >> http://marc.info/?t=14749669152=1=2 >> http://marc.info/?t=14749669154=1=2 >> http://marc.info/?t=14749669151=1=2 >> >> It needs jumbo frame support of NICs though. > > Thanks for pointing to this. > > Indeed frame with DSA tag conceptually is an envelope frame. > > ndev->env_hdr_len introduced by your patches, actually is explicitly > handled difference between (MTU + 18) and frame that HW should allow. > If this is known, hardware can be configured to work with DSA. At least > FEC hardware that can send and receive "slightly larger" frames after > simple register configuration. > > Furthermore, since DSA configuration is known statically (it comes from > device tree), ndo_set_env_hdr_len method could be automatically called > at init, making setup working by default if driver supports that. And if > not, perhaps can automatically lower MTU. > > Looks like a solution :) > > What's current status of this work? Thank you for taking a look. I'm planning to post v2 soon. > What is not really clear - what if several tagging protocols are used > together. AFAIU, things may be more complex that simple appending of > tags, e.g. EDSA tag can carry VLAN id inside. If kernel is aware of VLAN configuration, add 4 bytes + DSA tag size. (I'm not familiar with how dsa knows vlan configuration, but probably through switchdev_port_obj_add()? If so, dsa should be able to take into account additional vlan tag size.) If vlan tag is opaque from kernel, e.g. forwarding vlan tagged frames without configuring vlan_filtering in bridge, admin needs to set env_hdr_len manually. This is why I'm proposing manual operation. Regards, Toshiaki Makita
Re: DSA vs envelope frames
On 11/30/2016 07:10 AM, Andrew Lunn wrote: >> What is not really clear - what if several tagging protocols are used >> together. AFAIU, things may be more complex that simple appending of >> tags, e.g. EDSA tag can carry VLAN id inside. > > Hi Nikita > > At least for all current tagging protocols, the size of the tag is > constant. And you cannot run different tagging protocols on the same > master interface at the same time. I am not sure if using envelope frames is entirely appropriate here, because there are existing switch tagging protocols that: - don't have a specific Ethernet type allocated (Broadcom tags, DSA) - could be appended at the end of the frame instead of pre-pended Alexander Duyck suggested a while ago that we may be able to use the headers_ops to implement the DSA tag pop/push, as well as get an appropriate MTU adjustment, can you see if that would work? > > However, i think Florian tried something funky with the SF2 and B53 > driver. He has a b53 hanging off a sf2. So i think he used nested > tagging protocols! Well, this actually did not work, because the SF2 and B53 switches essentially terminate switch tags when they ingress their switch ports, so the tag inserted by B53 ingressing into the SF2 port does not get sent all the way to the CPU hanging off the SF2... With the B53 hanging off the SF2, we essentially have to disable Broadcom tags in the B53 device, because the tag and switches were never designed to be cascaded in the first place (at least not these specific cores). -- Florian
Re: DSA vs envelope frames
> What is not really clear - what if several tagging protocols are used > together. AFAIU, things may be more complex that simple appending of > tags, e.g. EDSA tag can carry VLAN id inside. Hi Nikita At least for all current tagging protocols, the size of the tag is constant. And you cannot run different tagging protocols on the same master interface at the same time. However, i think Florian tried something funky with the SF2 and B53 driver. He has a b53 hanging off a sf2. So i think he used nested tagging protocols! Andrew
DSA vs envelope frames
>> (1) When DSA is in use, frames processed by FEC chip contain DSA tag and >> thus can be larger than hardcoded limit of 1522. This issue is not >> FEC-specific, any driver that hardcodes maximum frame size to 1522 (many >> do) will have this issue if used with DSA. > > BTW I'm trying to introduce envelope frames to solve this kind of problems. > http://marc.info/?t=14749669155=1=2 > http://marc.info/?t=14749669153=1=2 > http://marc.info/?t=14749669152=1=2 > http://marc.info/?t=14749669154=1=2 > http://marc.info/?t=14749669151=1=2 > > It needs jumbo frame support of NICs though. Thanks for pointing to this. Indeed frame with DSA tag conceptually is an envelope frame. ndev->env_hdr_len introduced by your patches, actually is explicitly handled difference between (MTU + 18) and frame that HW should allow. If this is known, hardware can be configured to work with DSA. At least FEC hardware that can send and receive "slightly larger" frames after simple register configuration. Furthermore, since DSA configuration is known statically (it comes from device tree), ndo_set_env_hdr_len method could be automatically called at init, making setup working by default if driver supports that. And if not, perhaps can automatically lower MTU. Looks like a solution :) What's current status of this work? What is not really clear - what if several tagging protocols are used together. AFAIU, things may be more complex that simple appending of tags, e.g. EDSA tag can carry VLAN id inside. Nikita
