Understanding RX_OFFLOAD_VLAN_EXTEND

Understanding RX_OFFLOAD_VLAN_EXTEND

[Ivan Malov]

Hi!

We have a hard time figuring out what the API contract of
RX_OFFLOAD_VLAN_EXTEND might be. The best educated guess
we can make is that the feature might have something to
do with identifying VLAN packets and extracting TCI
without stripping the tags from incoming packets.

Is this understanding correct?

You see, things aren't helped by the offload bit having
almost no commentary. Such could've shed light on its
meaning. Perhaps this gap in documentation should
be addressed somehow. Any opinions?

Thank you.

Re: Understanding RX_OFFLOAD_VLAN_EXTEND

[Ferruh Yigit]

On 10/31/2022 6:46 PM, Ivan Malov wrote:
> Hi!
> 
> We have a hard time figuring out what the API contract of
> RX_OFFLOAD_VLAN_EXTEND might be. The best educated guess
> we can make is that the feature might have something to
> do with identifying VLAN packets and extracting TCI
> without stripping the tags from incoming packets.
> 
> Is this understanding correct?
> 
> You see, things aren't helped by the offload bit having
> almost no commentary. Such could've shed light on its
> meaning. Perhaps this gap in documentation should
> be addressed somehow. Any opinions?
> 
> Thank you.


Hi Ivan,

It is legacy from ixgbe driver, you can find more details on the ixgbe 
(82599) datasheet [1].

RX_OFFLOAD_VLAN_EXTEND is *like*, QinQ but not, that is why we have 
'QINQ_STRIP' offload.

And RX_OFFLOAD_VLAN_EXTEND is more a configuration option, briefly you 
can ignore it.
But in detail that is to configure device in a mode that it knows that 
received packets always has at least one VLAN tag, I assume it is for a 
case that some in the middle networking device inserts/requires VLAN 
tags. But optionally packet can have two VLAN tags. But as far as I can 
see this is not for to strip the VLAN tag or to filter packet based on 
it, this is just to configure device for this environment.



[1] copy/paste from a public datasheet 
(http://iommu.com/datasheets/ixgbe-datasheets/82599-datasheet-v3-4.pdf), 
not sure if this is up to date version, but I think it is OK for this 
context:

Double VLAN and Single VLAN Support
The 82599 supports a mode where all received and sent packets have at 
least one VLAN tag in addition to the regular tagging that might 
optionally be added. In this document, when a packet carries two VLAN 
headers, the first header is referred to as an outer VLAN and the second 
header as an inner VLAN header (as listed in the table that follows). 
This mode is used for systems where the near end switch adds the outer 
VLAN header containing switching information. This mode is enabled by 
the following configuration:
• This mode is activated by setting the DMATXCTL.GDV and the Extended 
VLAN bit in the CTRL_EXT register.
• The EtherType of the VLAN tag used for the additional VLAN is defined 
in the VET EXT field in the EXVET register.

Re: Understanding RX_OFFLOAD_VLAN_EXTEND

[Ivan Malov]

[-- Attachment #1: Type: text/plain, Size: 2456 bytes --]

Thank you, Ferruh. You have been most helpful.

On Mon, 31 Oct 2022, Ferruh Yigit wrote:

> On 10/31/2022 6:46 PM, Ivan Malov wrote:
>> Hi!
>> 
>> We have a hard time figuring out what the API contract of
>> RX_OFFLOAD_VLAN_EXTEND might be. The best educated guess
>> we can make is that the feature might have something to
>> do with identifying VLAN packets and extracting TCI
>> without stripping the tags from incoming packets.
>> 
>> Is this understanding correct?
>> 
>> You see, things aren't helped by the offload bit having
>> almost no commentary. Such could've shed light on its
>> meaning. Perhaps this gap in documentation should
>> be addressed somehow. Any opinions?
>> 
>> Thank you.
>
>
> Hi Ivan,
>
> It is legacy from ixgbe driver, you can find more details on the ixgbe 
> (82599) datasheet [1].
>
> RX_OFFLOAD_VLAN_EXTEND is *like*, QinQ but not, that is why we have 
> 'QINQ_STRIP' offload.
>
> And RX_OFFLOAD_VLAN_EXTEND is more a configuration option, briefly you can 
> ignore it.
> But in detail that is to configure device in a mode that it knows that 
> received packets always has at least one VLAN tag, I assume it is for a case 
> that some in the middle networking device inserts/requires VLAN tags. But 
> optionally packet can have two VLAN tags. But as far as I can see this is not 
> for to strip the VLAN tag or to filter packet based on it, this is just to 
> configure device for this environment.
>
>
>
> [1] copy/paste from a public datasheet 
> (http://iommu.com/datasheets/ixgbe-datasheets/82599-datasheet-v3-4.pdf), not 
> sure if this is up to date version, but I think it is OK for this context:
>
> Double VLAN and Single VLAN Support
> The 82599 supports a mode where all received and sent packets have at least 
> one VLAN tag in addition to the regular tagging that might optionally be 
> added. In this document, when a packet carries two VLAN headers, the first 
> header is referred to as an outer VLAN and the second header as an inner VLAN 
> header (as listed in the table that follows). This mode is used for systems 
> where the near end switch adds the outer VLAN header containing switching 
> information. This mode is enabled by the following configuration:
> • This mode is activated by setting the DMATXCTL.GDV and the Extended VLAN 
> bit in the CTRL_EXT register.
> • The EtherType of the VLAN tag used for the additional VLAN is defined in 
> the VET EXT field in the EXVET register.
>