[dpdk-dev] DEV_RX_OFFLOAD_VLAN_EXTEND offload

[dpdk-dev] DEV_RX_OFFLOAD_VLAN_EXTEND offload

[Jerin Jacob]

Does anyone know the expectation of DEV_RX_OFFLOAD_VLAN_EXTEND
offload? Does not look like it is documented.

Looks like it is very specific to Intel controllers, Based on 82599 HRM,
it is following, not sure what is the real expectation from NIC in
normative terms.

Extended VLAN.
-------------
When set, all incoming Rx packets are expected to have at least one VLAN
with the Ether type as defined in EXVET register. The packets can have
an inner-VLAN that should be used for all filtering purposes. All Tx
packets are expected to have at least one VLAN added to them by the
host. In the case of an additional VLAN request (VLE), the inner-VLAN is
added by the hardware after the outer-VLAN is added by the host.
This bit should only be reset by a PCIe reset and should only be changed
while Tx and Rx processes are stopped.
The exception to this rule are MAC control packets such as flow control,
802.1x, LACP, etc. that never carry a VLAN tag of any type

Re: [dpdk-dev] DEV_RX_OFFLOAD_VLAN_EXTEND offload

[Ferruh Yigit]

On 10/26/2018 11:56 AM, Jerin Jacob wrote:
> 
> Does anyone know the expectation of DEV_RX_OFFLOAD_VLAN_EXTEND
> offload? Does not look like it is documented.
> 
> Looks like it is very specific to Intel controllers, Based on 82599 HRM,
> it is following, not sure what is the real expectation from NIC in
> normative terms.
> 
> Extended VLAN.
> -------------
> When set, all incoming Rx packets are expected to have at least one VLAN
> with the Ether type as defined in EXVET register. The packets can have
> an inner-VLAN that should be used for all filtering purposes. All Tx
> packets are expected to have at least one VLAN added to them by the
> host. In the case of an additional VLAN request (VLE), the inner-VLAN is
> added by the hardware after the outer-VLAN is added by the host.
> This bit should only be reset by a PCIe reset and should only be changed
> while Tx and Rx processes are stopped.
> The exception to this rule are MAC control packets such as flow control,
> 802.1x, LACP, etc. that never carry a VLAN tag of any type
> 

This looks similar to QinQ but it seems not, in ixgbe datasheet it has:

"
Double VLAN and Single VLAN Support
-----------------------------------
<....>
 This mode is used for systems where the near end switch adds the outer VLAN
header containing switching information.
<...>
"

And it in this mode hw doesn't insert or strip the outer VLAN, it expect SW does
it. The ethernet type is not 0x88A8 but can be anything set on EXVET.VET_EXT. So
looks like it is to let switch to add custom VLAN tags and NIC to ignore them.

Re: [dpdk-dev] DEV_RX_OFFLOAD_VLAN_EXTEND offload

[Jerin Jacob]

-----Original Message-----
> Date: Fri, 26 Oct 2018 14:40:42 +0100
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>, "dev@dpdk.org"
>  <dev@dpdk.org>
> CC: "thomas@monjalon.net" <thomas@monjalon.net>,
>  "arybchenko@solarflare.com" <arybchenko@solarflare.com>,
>  "olivier.matz@6wind.com" <olivier.matz@6wind.com>, "qi.z.zhang@intel.com"
>  <qi.z.zhang@intel.com>, "beilei.xing@intel.com" <beilei.xing@intel.com>,
>  Wenzhuo Lu <wenzhuo.lu@intel.com>, Konstantin Ananyev
>  <konstantin.ananyev@intel.com>
> Subject: Re: [dpdk-dev] DEV_RX_OFFLOAD_VLAN_EXTEND offload
> User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
>  Thunderbird/52.9.1
> 
> 
> On 10/26/2018 11:56 AM, Jerin Jacob wrote:
> >
> > Does anyone know the expectation of DEV_RX_OFFLOAD_VLAN_EXTEND
> > offload? Does not look like it is documented.
> >
> > Looks like it is very specific to Intel controllers, Based on 82599 HRM,
> > it is following, not sure what is the real expectation from NIC in
> > normative terms.
> >
> > Extended VLAN.
> > -------------
> > When set, all incoming Rx packets are expected to have at least one VLAN
> > with the Ether type as defined in EXVET register. The packets can have
> > an inner-VLAN that should be used for all filtering purposes. All Tx
> > packets are expected to have at least one VLAN added to them by the
> > host. In the case of an additional VLAN request (VLE), the inner-VLAN is
> > added by the hardware after the outer-VLAN is added by the host.
> > This bit should only be reset by a PCIe reset and should only be changed
> > while Tx and Rx processes are stopped.
> > The exception to this rule are MAC control packets such as flow control,
> > 802.1x, LACP, etc. that never carry a VLAN tag of any type
> >
> 
> This looks similar to QinQ but it seems not, in ixgbe datasheet it has:

Yes. QinQ there is an already an offload called
DEV_RX_OFFLOAD_QINQ_STRIP


> 
> "
> Double VLAN and Single VLAN Support
> -----------------------------------
> <....>
>  This mode is used for systems where the near end switch adds the outer VLAN
> header containing switching information.
> <...>
> "
> 
> And it in this mode hw doesn't insert or strip the outer VLAN, it expect SW does
> it. The ethernet type is not 0x88A8 but can be anything set on EXVET.VET_EXT. So
> looks like it is to let switch to add custom VLAN tags and NIC to ignore them.

Re: [dpdk-dev] DEV_RX_OFFLOAD_VLAN_EXTEND offload

[Zhao1, Wei]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
> Sent: Friday, October 26, 2018 10:35 PM
> To: Yigit, Ferruh <ferruh.yigit@intel.com>
> Cc: dev@dpdk.org; thomas@monjalon.net; arybchenko@solarflare.com;
> olivier.matz@6wind.com; Zhang, Qi Z <qi.z.zhang@intel.com>; Xing, Beilei
> <beilei.xing@intel.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>; Ananyev,
> Konstantin <konstantin.ananyev@intel.com>
> Subject: Re: [dpdk-dev] DEV_RX_OFFLOAD_VLAN_EXTEND offload
> 
> -----Original Message-----
> > Date: Fri, 26 Oct 2018 14:40:42 +0100
> > From: Ferruh Yigit <ferruh.yigit@intel.com>
> > To: Jerin Jacob <jerin.jacob@caviumnetworks.com>, "dev@dpdk.org"
> >  <dev@dpdk.org>
> > CC: "thomas@monjalon.net" <thomas@monjalon.net>,
> > "arybchenko@solarflare.com" <arybchenko@solarflare.com>,
> > "olivier.matz@6wind.com" <olivier.matz@6wind.com>,
> "qi.z.zhang@intel.com"
> >  <qi.z.zhang@intel.com>, "beilei.xing@intel.com"
> > <beilei.xing@intel.com>,  Wenzhuo Lu <wenzhuo.lu@intel.com>,
> > Konstantin Ananyev  <konstantin.ananyev@intel.com>
> > Subject: Re: [dpdk-dev] DEV_RX_OFFLOAD_VLAN_EXTEND offload
> > User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0)
> > Gecko/20100101
> >  Thunderbird/52.9.1
> >
> >
> > On 10/26/2018 11:56 AM, Jerin Jacob wrote:
> > >
> > > Does anyone know the expectation of
> DEV_RX_OFFLOAD_VLAN_EXTEND
> > > offload? Does not look like it is documented.
> > >
> > > Looks like it is very specific to Intel controllers, Based on 82599
> > > HRM, it is following, not sure what is the real expectation from NIC
> > > in normative terms.
> > >
> > > Extended VLAN.
> > > -------------
> > > When set, all incoming Rx packets are expected to have at least one
> > > VLAN with the Ether type as defined in EXVET register. The packets
> > > can have an inner-VLAN that should be used for all filtering
> > > purposes. All Tx packets are expected to have at least one VLAN
> > > added to them by the host. In the case of an additional VLAN request
> > > (VLE), the inner-VLAN is added by the hardware after the outer-VLAN is
> added by the host.
> > > This bit should only be reset by a PCIe reset and should only be
> > > changed while Tx and Rx processes are stopped.
> > > The exception to this rule are MAC control packets such as flow
> > > control, 802.1x, LACP, etc. that never carry a VLAN tag of any type
> > >
> >
> > This looks similar to QinQ but it seems not, in ixgbe datasheet it has:
> 
> Yes. QinQ there is an already an offload called
> DEV_RX_OFFLOAD_QINQ_STRIP

Excuse me, I have some thought, is that right?
maybe DEV_RX_OFFLOAD_QINQ_STRIP and DEV_RX_OFFLOAD_VLAN_EXTEND is just two thing that play a different role each.
DEV_RX_OFFLOAD_VLAN_EXTEND tell NIC to recognize QinQ PACKETS, it is a filter for NIC.
DEV_RX_OFFLOAD_QINQ_STRIP tell nic to strip 2 inner and outer vlan head when moving packets from nic to host memory.
I40e NIC is the normative terms when handling qinq packets.

> 
> 
> >
> > "
> > Double VLAN and Single VLAN Support
> > -----------------------------------
> > <....>
> >  This mode is used for systems where the near end switch adds the
> > outer VLAN header containing switching information.
> > <...>
> > "
> >
> > And it in this mode hw doesn't insert or strip the outer VLAN, it
> > expect SW does it. The ethernet type is not 0x88A8 but can be anything
> > set on EXVET.VET_EXT. So looks like it is to let switch to add custom VLAN
> tags and NIC to ignore them.

Re: [dpdk-dev] DEV_RX_OFFLOAD_VLAN_EXTEND offload

[Jerin Jacob]

-----Original Message-----
> Date: Thu, 1 Nov 2018 09:50:12 +0000
> From: "Zhao1, Wei" <wei.zhao1@intel.com>
> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>, "Yigit, Ferruh"
>  <ferruh.yigit@intel.com>
> CC: "dev@dpdk.org" <dev@dpdk.org>, "thomas@monjalon.net"
>  <thomas@monjalon.net>, "arybchenko@solarflare.com"
>  <arybchenko@solarflare.com>, "olivier.matz@6wind.com"
>  <olivier.matz@6wind.com>, "Zhang, Qi Z" <qi.z.zhang@intel.com>, "Xing,
>  Beilei" <beilei.xing@intel.com>, "Lu, Wenzhuo" <wenzhuo.lu@intel.com>,
>  "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
> Subject: RE: [dpdk-dev] DEV_RX_OFFLOAD_VLAN_EXTEND offload
> 
> 
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
> > Sent: Friday, October 26, 2018 10:35 PM
> > To: Yigit, Ferruh <ferruh.yigit@intel.com>
> > Cc: dev@dpdk.org; thomas@monjalon.net; arybchenko@solarflare.com;
> > olivier.matz@6wind.com; Zhang, Qi Z <qi.z.zhang@intel.com>; Xing, Beilei
> > <beilei.xing@intel.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>; Ananyev,
> > Konstantin <konstantin.ananyev@intel.com>
> > Subject: Re: [dpdk-dev] DEV_RX_OFFLOAD_VLAN_EXTEND offload
> >
> > -----Original Message-----
> > > Date: Fri, 26 Oct 2018 14:40:42 +0100
> > > From: Ferruh Yigit <ferruh.yigit@intel.com>
> > > To: Jerin Jacob <jerin.jacob@caviumnetworks.com>, "dev@dpdk.org"
> > >  <dev@dpdk.org>
> > > CC: "thomas@monjalon.net" <thomas@monjalon.net>,
> > > "arybchenko@solarflare.com" <arybchenko@solarflare.com>,
> > > "olivier.matz@6wind.com" <olivier.matz@6wind.com>,
> > "qi.z.zhang@intel.com"
> > >  <qi.z.zhang@intel.com>, "beilei.xing@intel.com"
> > > <beilei.xing@intel.com>,  Wenzhuo Lu <wenzhuo.lu@intel.com>,
> > > Konstantin Ananyev  <konstantin.ananyev@intel.com>
> > > Subject: Re: [dpdk-dev] DEV_RX_OFFLOAD_VLAN_EXTEND offload
> > > User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0)
> > > Gecko/20100101
> > >  Thunderbird/52.9.1
> > >
> > >
> > > On 10/26/2018 11:56 AM, Jerin Jacob wrote:
> > > >
> > > > Does anyone know the expectation of
> > DEV_RX_OFFLOAD_VLAN_EXTEND
> > > > offload? Does not look like it is documented.
> > > >
> > > > Looks like it is very specific to Intel controllers, Based on 82599
> > > > HRM, it is following, not sure what is the real expectation from NIC
> > > > in normative terms.
> > > >
> > > > Extended VLAN.
> > > > -------------
> > > > When set, all incoming Rx packets are expected to have at least one
> > > > VLAN with the Ether type as defined in EXVET register. The packets
> > > > can have an inner-VLAN that should be used for all filtering
> > > > purposes. All Tx packets are expected to have at least one VLAN
> > > > added to them by the host. In the case of an additional VLAN request
> > > > (VLE), the inner-VLAN is added by the hardware after the outer-VLAN is
> > added by the host.
> > > > This bit should only be reset by a PCIe reset and should only be
> > > > changed while Tx and Rx processes are stopped.
> > > > The exception to this rule are MAC control packets such as flow
> > > > control, 802.1x, LACP, etc. that never carry a VLAN tag of any type
> > > >
> > >
> > > This looks similar to QinQ but it seems not, in ixgbe datasheet it has:
> >
> > Yes. QinQ there is an already an offload called
> > DEV_RX_OFFLOAD_QINQ_STRIP
> 
> Excuse me, I have some thought, is that right?
> maybe DEV_RX_OFFLOAD_QINQ_STRIP and DEV_RX_OFFLOAD_VLAN_EXTEND is just two thing that play a different role each.
> DEV_RX_OFFLOAD_VLAN_EXTEND tell NIC to recognize QinQ PACKETS, it is a filter for NIC.
> DEV_RX_OFFLOAD_QINQ_STRIP tell nic to strip 2 inner and outer vlan head when moving packets from nic to host memory.
> I40e NIC is the normative terms when handling qinq packets.

Yes, it makes sense if the meaning of DEV_RX_OFFLOAD_VLAN_EXTEND is QINQ
filter. But it looks like not, as .vlan_filter_set ethdev callback accepts 
only single vlan id as "uint16_t vlan_id".
If it needs to be treated as QinQ filter then QinQ vlan_ids needs to be
send to driver through some means.


Probably we may need to deprecate these vlan API in long-term and
enable it through rte_flow.

> 
> >
> >
> > >
> > > "
> > > Double VLAN and Single VLAN Support
> > > -----------------------------------
> > > <....>
> > >  This mode is used for systems where the near end switch adds the
> > > outer VLAN header containing switching information.
> > > <...>
> > > "
> > >
> > > And it in this mode hw doesn't insert or strip the outer VLAN, it
> > > expect SW does it. The ethernet type is not 0x88A8 but can be anything
> > > set on EXVET.VET_EXT. So looks like it is to let switch to add custom VLAN
> > tags and NIC to ignore them.

Re: [dpdk-dev] DEV_RX_OFFLOAD_VLAN_EXTEND offload

[Zhao1, Wei]

Hi,  Jerin Jacob

> -----Original Message-----
> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> Sent: Thursday, November 1, 2018 6:34 PM
> To: Zhao1, Wei <wei.zhao1@intel.com>
> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; dev@dpdk.org;
> thomas@monjalon.net; arybchenko@solarflare.com;
> olivier.matz@6wind.com; Zhang, Qi Z <qi.z.zhang@intel.com>; Xing, Beilei
> <beilei.xing@intel.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>; Ananyev,
> Konstantin <konstantin.ananyev@intel.com>
> Subject: Re: [dpdk-dev] DEV_RX_OFFLOAD_VLAN_EXTEND offload
> 
> -----Original Message-----
> > Date: Thu, 1 Nov 2018 09:50:12 +0000
> > From: "Zhao1, Wei" <wei.zhao1@intel.com>
> > To: Jerin Jacob <jerin.jacob@caviumnetworks.com>, "Yigit, Ferruh"
> >  <ferruh.yigit@intel.com>
> > CC: "dev@dpdk.org" <dev@dpdk.org>, "thomas@monjalon.net"
> >  <thomas@monjalon.net>, "arybchenko@solarflare.com"
> >  <arybchenko@solarflare.com>, "olivier.matz@6wind.com"
> >  <olivier.matz@6wind.com>, "Zhang, Qi Z" <qi.z.zhang@intel.com>,
> > "Xing,  Beilei" <beilei.xing@intel.com>, "Lu, Wenzhuo"
> > <wenzhuo.lu@intel.com>,  "Ananyev, Konstantin"
> > <konstantin.ananyev@intel.com>
> > Subject: RE: [dpdk-dev] DEV_RX_OFFLOAD_VLAN_EXTEND offload
> >
> >
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
> > > Sent: Friday, October 26, 2018 10:35 PM
> > > To: Yigit, Ferruh <ferruh.yigit@intel.com>
> > > Cc: dev@dpdk.org; thomas@monjalon.net; arybchenko@solarflare.com;
> > > olivier.matz@6wind.com; Zhang, Qi Z <qi.z.zhang@intel.com>; Xing,
> > > Beilei <beilei.xing@intel.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>;
> > > Ananyev, Konstantin <konstantin.ananyev@intel.com>
> > > Subject: Re: [dpdk-dev] DEV_RX_OFFLOAD_VLAN_EXTEND offload
> > >
> > > -----Original Message-----
> > > > Date: Fri, 26 Oct 2018 14:40:42 +0100
> > > > From: Ferruh Yigit <ferruh.yigit@intel.com>
> > > > To: Jerin Jacob <jerin.jacob@caviumnetworks.com>, "dev@dpdk.org"
> > > >  <dev@dpdk.org>
> > > > CC: "thomas@monjalon.net" <thomas@monjalon.net>,
> > > > "arybchenko@solarflare.com" <arybchenko@solarflare.com>,
> > > > "olivier.matz@6wind.com" <olivier.matz@6wind.com>,
> > > "qi.z.zhang@intel.com"
> > > >  <qi.z.zhang@intel.com>, "beilei.xing@intel.com"
> > > > <beilei.xing@intel.com>,  Wenzhuo Lu <wenzhuo.lu@intel.com>,
> > > > Konstantin Ananyev  <konstantin.ananyev@intel.com>
> > > > Subject: Re: [dpdk-dev] DEV_RX_OFFLOAD_VLAN_EXTEND offload
> > > > User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0)
> > > > Gecko/20100101
> > > >  Thunderbird/52.9.1
> > > >
> > > >
> > > > On 10/26/2018 11:56 AM, Jerin Jacob wrote:
> > > > >
> > > > > Does anyone know the expectation of
> > > DEV_RX_OFFLOAD_VLAN_EXTEND
> > > > > offload? Does not look like it is documented.
> > > > >
> > > > > Looks like it is very specific to Intel controllers, Based on
> > > > > 82599 HRM, it is following, not sure what is the real
> > > > > expectation from NIC in normative terms.
> > > > >
> > > > > Extended VLAN.
> > > > > -------------
> > > > > When set, all incoming Rx packets are expected to have at least
> > > > > one VLAN with the Ether type as defined in EXVET register. The
> > > > > packets can have an inner-VLAN that should be used for all
> > > > > filtering purposes. All Tx packets are expected to have at least
> > > > > one VLAN added to them by the host. In the case of an additional
> > > > > VLAN request (VLE), the inner-VLAN is added by the hardware
> > > > > after the outer-VLAN is
> > > added by the host.
> > > > > This bit should only be reset by a PCIe reset and should only be
> > > > > changed while Tx and Rx processes are stopped.
> > > > > The exception to this rule are MAC control packets such as flow
> > > > > control, 802.1x, LACP, etc. that never carry a VLAN tag of any
> > > > > type
> > > > >
> > > >
> > > > This looks similar to QinQ but it seems not, in ixgbe datasheet it has:
> > >
> > > Yes. QinQ there is an already an offload called
> > > DEV_RX_OFFLOAD_QINQ_STRIP
> >
> > Excuse me, I have some thought, is that right?
> > maybe DEV_RX_OFFLOAD_QINQ_STRIP and
> DEV_RX_OFFLOAD_VLAN_EXTEND is just two thing that play a different role
> each.
> > DEV_RX_OFFLOAD_VLAN_EXTEND tell NIC to recognize QinQ PACKETS, it is
> a filter for NIC.
> > DEV_RX_OFFLOAD_QINQ_STRIP tell nic to strip 2 inner and outer vlan head
> when moving packets from nic to host memory.
> > I40e NIC is the normative terms when handling qinq packets.
> 
> Yes, it makes sense if the meaning of DEV_RX_OFFLOAD_VLAN_EXTEND is
> QINQ filter. But it looks like not, as .vlan_filter_set ethdev callback accepts
> only single vlan id as "uint16_t vlan_id".
> If it needs to be treated as QinQ filter then QinQ vlan_ids needs to be send
> to driver through some means.
> 

Yes,  DEV_RX_OFFLOAD_VLAN_EXTEND can enable the qinq filter, but I do not find the way to config QinQ vlan_ids,
May be we need some means to send inner and outer vlan id to PMD, may be it is already exist but we do not find it.
I will check that and report in this mail if I get the result.

> 
> Probably we may need to deprecate these vlan API in long-term and
> enable it through rte_flow.

Good idea!

> 
> >
> > >
> > >
> > > >
> > > > "
> > > > Double VLAN and Single VLAN Support
> > > > -----------------------------------
> > > > <....>
> > > >  This mode is used for systems where the near end switch adds the
> > > > outer VLAN header containing switching information.
> > > > <...>
> > > > "
> > > >
> > > > And it in this mode hw doesn't insert or strip the outer VLAN, it
> > > > expect SW does it. The ethernet type is not 0x88A8 but can be anything
> > > > set on EXVET.VET_EXT. So looks like it is to let switch to add custom
> VLAN
> > > tags and NIC to ignore them.

Re: [dpdk-dev] DEV_RX_OFFLOAD_VLAN_EXTEND offload

[Thomas Monjalon]

05/11/2018 05:22, Zhao1, Wei:
> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> > From: "Zhao1, Wei" <wei.zhao1@intel.com>
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
> > > > From: Ferruh Yigit <ferruh.yigit@intel.com>
> > > > > On 10/26/2018 11:56 AM, Jerin Jacob wrote:
> > > > > >
> > > > > > Does anyone know the expectation of
> > > > DEV_RX_OFFLOAD_VLAN_EXTEND
> > > > > > offload? Does not look like it is documented.
> > > > > >
> > > > > > Looks like it is very specific to Intel controllers, Based on
> > > > > > 82599 HRM, it is following, not sure what is the real
> > > > > > expectation from NIC in normative terms.
> > > > > >
> > > > > > Extended VLAN.
> > > > > > -------------
> > > > > > When set, all incoming Rx packets are expected to have at least
> > > > > > one VLAN with the Ether type as defined in EXVET register. The
> > > > > > packets can have an inner-VLAN that should be used for all
> > > > > > filtering purposes. All Tx packets are expected to have at least
> > > > > > one VLAN added to them by the host. In the case of an additional
> > > > > > VLAN request (VLE), the inner-VLAN is added by the hardware
> > > > > > after the outer-VLAN is
> > > > added by the host.
> > > > > > This bit should only be reset by a PCIe reset and should only be
> > > > > > changed while Tx and Rx processes are stopped.
> > > > > > The exception to this rule are MAC control packets such as flow
> > > > > > control, 802.1x, LACP, etc. that never carry a VLAN tag of any
> > > > > > type
> > > > > >
> > > > >
> > > > > This looks similar to QinQ but it seems not, in ixgbe datasheet it has:
> > > >
> > > > Yes. QinQ there is an already an offload called
> > > > DEV_RX_OFFLOAD_QINQ_STRIP
> > >
> > > Excuse me, I have some thought, is that right?
> > > maybe DEV_RX_OFFLOAD_QINQ_STRIP and
> > DEV_RX_OFFLOAD_VLAN_EXTEND is just two thing that play a different role
> > each.
> > > DEV_RX_OFFLOAD_VLAN_EXTEND tell NIC to recognize QinQ PACKETS, it is
> > a filter for NIC.
> > > DEV_RX_OFFLOAD_QINQ_STRIP tell nic to strip 2 inner and outer vlan head
> > when moving packets from nic to host memory.
> > > I40e NIC is the normative terms when handling qinq packets.
> > 
> > Yes, it makes sense if the meaning of DEV_RX_OFFLOAD_VLAN_EXTEND is
> > QINQ filter. But it looks like not, as .vlan_filter_set ethdev callback accepts
> > only single vlan id as "uint16_t vlan_id".
> > If it needs to be treated as QinQ filter then QinQ vlan_ids needs to be send
> > to driver through some means.
> > 
> 
> Yes,  DEV_RX_OFFLOAD_VLAN_EXTEND can enable the qinq filter, but I do not find the way to config QinQ vlan_ids,
> May be we need some means to send inner and outer vlan id to PMD, may be it is already exist but we do not find it.
> I will check that and report in this mail if I get the result.
> 
> > 
> > Probably we may need to deprecate these vlan API in long-term and
> > enable it through rte_flow.
> 
> Good idea!

Generally speaking, all APIs which are also covered by rte_flow must
be deprecated. We must migrate all PMDs to the new APIs.

Re: [dpdk-dev] DEV_RX_OFFLOAD_VLAN_EXTEND offload

[Zhao1, Wei]

> -----Original Message-----
> From: Zhao1, Wei
> Sent: Monday, November 5, 2018 12:22 PM
> To: 'Jerin Jacob' <jerin.jacob@caviumnetworks.com>
> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; dev@dpdk.org;
> thomas@monjalon.net; arybchenko@solarflare.com;
> olivier.matz@6wind.com; Zhang, Qi Z <qi.z.zhang@intel.com>; Xing, Beilei
> <beilei.xing@intel.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>; Ananyev,
> Konstantin <konstantin.ananyev@intel.com>
> Subject: RE: [dpdk-dev] DEV_RX_OFFLOAD_VLAN_EXTEND offload
> 
> Hi,  Jerin Jacob
> 
> > -----Original Message-----
> > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> > Sent: Thursday, November 1, 2018 6:34 PM
> > To: Zhao1, Wei <wei.zhao1@intel.com>
> > Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; dev@dpdk.org;
> > thomas@monjalon.net; arybchenko@solarflare.com;
> > olivier.matz@6wind.com; Zhang, Qi Z <qi.z.zhang@intel.com>; Xing,
> > Beilei <beilei.xing@intel.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>;
> > Ananyev, Konstantin <konstantin.ananyev@intel.com>
> > Subject: Re: [dpdk-dev] DEV_RX_OFFLOAD_VLAN_EXTEND offload
> >
> > -----Original Message-----
> > > Date: Thu, 1 Nov 2018 09:50:12 +0000
> > > From: "Zhao1, Wei" <wei.zhao1@intel.com>
> > > To: Jerin Jacob <jerin.jacob@caviumnetworks.com>, "Yigit, Ferruh"
> > >  <ferruh.yigit@intel.com>
> > > CC: "dev@dpdk.org" <dev@dpdk.org>, "thomas@monjalon.net"
> > >  <thomas@monjalon.net>, "arybchenko@solarflare.com"
> > >  <arybchenko@solarflare.com>, "olivier.matz@6wind.com"
> > >  <olivier.matz@6wind.com>, "Zhang, Qi Z" <qi.z.zhang@intel.com>,
> > > "Xing,  Beilei" <beilei.xing@intel.com>, "Lu, Wenzhuo"
> > > <wenzhuo.lu@intel.com>,  "Ananyev, Konstantin"
> > > <konstantin.ananyev@intel.com>
> > > Subject: RE: [dpdk-dev] DEV_RX_OFFLOAD_VLAN_EXTEND offload
> > >
> > >
> > > > -----Original Message-----
> > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
> > > > Sent: Friday, October 26, 2018 10:35 PM
> > > > To: Yigit, Ferruh <ferruh.yigit@intel.com>
> > > > Cc: dev@dpdk.org; thomas@monjalon.net;
> arybchenko@solarflare.com;
> > > > olivier.matz@6wind.com; Zhang, Qi Z <qi.z.zhang@intel.com>; Xing,
> > > > Beilei <beilei.xing@intel.com>; Lu, Wenzhuo
> > > > <wenzhuo.lu@intel.com>; Ananyev, Konstantin
> > > > <konstantin.ananyev@intel.com>
> > > > Subject: Re: [dpdk-dev] DEV_RX_OFFLOAD_VLAN_EXTEND offload
> > > >
> > > > -----Original Message-----
> > > > > Date: Fri, 26 Oct 2018 14:40:42 +0100
> > > > > From: Ferruh Yigit <ferruh.yigit@intel.com>
> > > > > To: Jerin Jacob <jerin.jacob@caviumnetworks.com>, "dev@dpdk.org"
> > > > >  <dev@dpdk.org>
> > > > > CC: "thomas@monjalon.net" <thomas@monjalon.net>,
> > > > > "arybchenko@solarflare.com" <arybchenko@solarflare.com>,
> > > > > "olivier.matz@6wind.com" <olivier.matz@6wind.com>,
> > > > "qi.z.zhang@intel.com"
> > > > >  <qi.z.zhang@intel.com>, "beilei.xing@intel.com"
> > > > > <beilei.xing@intel.com>,  Wenzhuo Lu <wenzhuo.lu@intel.com>,
> > > > > Konstantin Ananyev  <konstantin.ananyev@intel.com>
> > > > > Subject: Re: [dpdk-dev] DEV_RX_OFFLOAD_VLAN_EXTEND offload
> > > > > User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0)
> > > > > Gecko/20100101
> > > > >  Thunderbird/52.9.1
> > > > >
> > > > >
> > > > > On 10/26/2018 11:56 AM, Jerin Jacob wrote:
> > > > > >
> > > > > > Does anyone know the expectation of
> > > > DEV_RX_OFFLOAD_VLAN_EXTEND
> > > > > > offload? Does not look like it is documented.
> > > > > >
> > > > > > Looks like it is very specific to Intel controllers, Based on
> > > > > > 82599 HRM, it is following, not sure what is the real
> > > > > > expectation from NIC in normative terms.
> > > > > >
> > > > > > Extended VLAN.
> > > > > > -------------
> > > > > > When set, all incoming Rx packets are expected to have at
> > > > > > least one VLAN with the Ether type as defined in EXVET
> > > > > > register. The packets can have an inner-VLAN that should be
> > > > > > used for all filtering purposes. All Tx packets are expected
> > > > > > to have at least one VLAN added to them by the host. In the
> > > > > > case of an additional VLAN request (VLE), the inner-VLAN is
> > > > > > added by the hardware after the outer-VLAN is
> > > > added by the host.
> > > > > > This bit should only be reset by a PCIe reset and should only
> > > > > > be changed while Tx and Rx processes are stopped.
> > > > > > The exception to this rule are MAC control packets such as
> > > > > > flow control, 802.1x, LACP, etc. that never carry a VLAN tag
> > > > > > of any type
> > > > > >
> > > > >
> > > > > This looks similar to QinQ but it seems not, in ixgbe datasheet it has:
> > > >
> > > > Yes. QinQ there is an already an offload called
> > > > DEV_RX_OFFLOAD_QINQ_STRIP
> > >
> > > Excuse me, I have some thought, is that right?
> > > maybe DEV_RX_OFFLOAD_QINQ_STRIP and
> > DEV_RX_OFFLOAD_VLAN_EXTEND is just two thing that play a different
> > role each.
> > > DEV_RX_OFFLOAD_VLAN_EXTEND tell NIC to recognize QinQ PACKETS, it
> is
> > a filter for NIC.
> > > DEV_RX_OFFLOAD_QINQ_STRIP tell nic to strip 2 inner and outer vlan
> > > head
> > when moving packets from nic to host memory.
> > > I40e NIC is the normative terms when handling qinq packets.
> >
> > Yes, it makes sense if the meaning of DEV_RX_OFFLOAD_VLAN_EXTEND is
> > QINQ filter. But it looks like not, as .vlan_filter_set ethdev
> > callback accepts only single vlan id as "uint16_t vlan_id".
> > If it needs to be treated as QinQ filter then QinQ vlan_ids needs to
> > be send to driver through some means.
> >
> 
> Yes,  DEV_RX_OFFLOAD_VLAN_EXTEND can enable the qinq filter, but I do
> not find the way to config QinQ vlan_ids, May be we need some means to
> send inner and outer vlan id to PMD, may be it is already exist but we do not
> find it.
> I will check that and report in this mail if I get the result.

I have do a double check for that, it seems you are right, we have only one the API for 
" as .vlan_filter_set ethdev  callback accepts only single vlan id as "uint16_t vlan_id".


> 
> >
> > Probably we may need to deprecate these vlan API in long-term and
> > enable it through rte_flow.
> 
> Good idea!
> 
> >
> > >
> > > >
> > > >
> > > > >
> > > > > "
> > > > > Double VLAN and Single VLAN Support
> > > > > -----------------------------------
> > > > > <....>
> > > > >  This mode is used for systems where the near end switch adds
> > > > > the outer VLAN header containing switching information.
> > > > > <...>
> > > > > "
> > > > >
> > > > > And it in this mode hw doesn't insert or strip the outer VLAN,
> > > > > it expect SW does it. The ethernet type is not 0x88A8 but can be
> > > > > anything set on EXVET.VET_EXT. So looks like it is to let switch
> > > > > to add custom
> > VLAN
> > > > tags and NIC to ignore them.