DEV_RX_OFFLOAD_VLAN_EXTEND offload
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
Quoted 8 lines · Jerin Jacob
Does anyone know the expectation of
DEV_RX_OFFLOAD_VLAN_EXTENDoffload? 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.
Quoted 13 lines
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.
-----Original Message-----
Quoted 38 lines
Date: Fri, 26 Oct 2018 14:40:42 +0100
From: Ferruh Yigit <[email protected]>
To: Jerin Jacob <[email protected]>, "[email protected]"
<[email protected]>
CC: "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, Wenzhuo Lu <[email protected]>, Konstantin Ananyev <[email protected]>
Subject: Re: [dpdk-dev]DEV_RX_OFFLOAD_VLAN_EXTENDoffload
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.9.1Quoted 8 lines · Jerin Jacob
Does anyone know the expectation of
DEV_RX_OFFLOAD_VLAN_EXTENDoffload? 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.
Quoted 13 lines
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
Quoted 1 line
This looks similar to QinQ but it seems not, in ixgbe datasheet it has:
Yes. QinQ there is an already an offload calledDEV_RX_OFFLOAD_QINQ_STRIP
Quoted 13 lines
"
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
0x88A8but 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.
Quoted 55 lines
-----Original Message-----
From: dev [mailto:[email protected]] On Behalf Of Jerin Jacob
Sent: Friday, October 26, 2018 10:35 PM
To: Yigit, Ferruh <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; Zhang, Qi Z <[email protected]>; Xing, Beilei <[email protected]>; Lu, Wenzhuo <[email protected]>; Ananyev, Konstantin <[email protected]>
Subject: Re: [dpdk-dev]DEV_RX_OFFLOAD_VLAN_EXTENDoffload-----Original Message-----
Quoted 7 lines
Date: Fri, 26 Oct 2018 14:40:42 +0100
From: Ferruh Yigit <[email protected]>
To: Jerin Jacob <[email protected]>, "[email protected]"
<[email protected]>
CC: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>,Quoted 9 lines
<[email protected]>, "[email protected]"
<[email protected]>, Wenzhuo Lu <[email protected]>, Konstantin Ananyev <[email protected]>
Subject: Re: [dpdk-dev]DEV_RX_OFFLOAD_VLAN_EXTENDoffload
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.9.1Quoted 3 lines
Quoted 2 lines · Jerin Jacob
Does anyone know the expectation of
DEV_RX_OFFLOAD_VLAN_EXTENDQuoted 6 lines
Quoted 6 lines
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.
Quoted 8 lines
Quoted 8 lines
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 isadded by the host.
Quoted 6 lines
Quoted 5 lines
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
Quoted 4 lines
Quoted 1 line
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.
Quoted 16 lines
Quoted 12 lines
"
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. <...>
"Quoted 3 lines
And it in this mode hw doesn't insert or strip the outer VLAN, it expect SW does it. The ethernet type is not
0x88A8but can be anything set on EXVET.VET_EXT. So looks like it is to let switch to add custom VLANtags and NIC to ignore them.
-----Original Message-----
Quoted 68 lines
Date: Thu, 1 Nov 2018 09:50:12 +0000
From: "Zhao1, Wei" <[email protected]>
To: Jerin Jacob <[email protected]>, "Yigit, Ferruh"
<[email protected]>
CC: "[email protected]" <[email protected]>, "[email protected]"
<[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "Zhang, Qi Z" <[email protected]>, "Xing, Beilei" <[email protected]>, "Lu, Wenzhuo" <[email protected]>, "Ananyev, Konstantin" <[email protected]>
Subject: RE: [dpdk-dev]DEV_RX_OFFLOAD_VLAN_EXTENDoffloadQuoted 55 lines
-----Original Message-----
From: dev [mailto:[email protected]] On Behalf Of Jerin Jacob
Sent: Friday, October 26, 2018 10:35 PM
To: Yigit, Ferruh <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; Zhang, Qi Z <[email protected]>; Xing, Beilei <[email protected]>; Lu, Wenzhuo <[email protected]>; Ananyev, Konstantin <[email protected]>
Subject: Re: [dpdk-dev]DEV_RX_OFFLOAD_VLAN_EXTENDoffload-----Original Message-----
Quoted 7 lines
Date: Fri, 26 Oct 2018 14:40:42 +0100
From: Ferruh Yigit <[email protected]>
To: Jerin Jacob <[email protected]>, "[email protected]"
<[email protected]>
CC: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>,Quoted 9 lines
<[email protected]>, "[email protected]"
<[email protected]>, Wenzhuo Lu <[email protected]>, Konstantin Ananyev <[email protected]>
Subject: Re: [dpdk-dev]DEV_RX_OFFLOAD_VLAN_EXTENDoffload
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.9.1Quoted 3 lines
Quoted 2 lines · Jerin Jacob
Does anyone know the expectation of
DEV_RX_OFFLOAD_VLAN_EXTENDQuoted 6 lines
Quoted 6 lines
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.
Quoted 8 lines
Quoted 8 lines
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 isadded by the host.
Quoted 7 lines
Quoted 5 lines
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 typeThis looks similar to QinQ but it seems not, in ixgbe datasheet it has:
Quoted 8 lines
Quoted 2 lines
Yes. QinQ there is an already an offload called
DEV_RX_OFFLOAD_QINQ_STRIPExcuse me, I have some thought, is that right?
maybeDEV_RX_OFFLOAD_QINQ_STRIPandDEV_RX_OFFLOAD_VLAN_EXTENDis just two thing that play a different role each.DEV_RX_OFFLOAD_VLAN_EXTENDtell NIC to recognize QinQ PACKETS, it is a filter for NIC.DEV_RX_OFFLOAD_QINQ_STRIPtell 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.
Quoted 17 lines
Quoted 17 lines
Quoted 13 lines
"
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. <...>
"Quoted 3 lines
And it in this mode hw doesn't insert or strip the outer VLAN, it expect SW does it. The ethernet type is not
0x88A8but can be anything set on EXVET.VET_EXT. So looks like it is to let switch to add custom VLANtags and NIC to ignore them.
Hi, Jerin Jacob
Quoted 93 lines
-----Original Message-----
From: Jerin Jacob [mailto:[email protected]]
Sent: Thursday, November 1, 2018 6:34 PM
To: Zhao1, Wei <[email protected]>
Cc: Yigit, Ferruh <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; Zhang, Qi Z <[email protected]>; Xing, Beilei <[email protected]>; Lu, Wenzhuo <[email protected]>; Ananyev, Konstantin <[email protected]>
Subject: Re: [dpdk-dev]DEV_RX_OFFLOAD_VLAN_EXTENDoffload-----Original Message-----
Quoted 69 lines
Date: Thu, 1 Nov 2018 09:50:12 +0000
From: "Zhao1, Wei" <[email protected]>
To: Jerin Jacob <[email protected]>, "Yigit, Ferruh"
<[email protected]>
CC: "[email protected]" <[email protected]>, "[email protected]"
<[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "Zhang, Qi Z" <[email protected]>,
"Xing, Beilei" <[email protected]>, "Lu, Wenzhuo" <[email protected]>, "Ananyev, Konstantin" <[email protected]>
Subject: RE: [dpdk-dev]DEV_RX_OFFLOAD_VLAN_EXTENDoffloadQuoted 55 lines
-----Original Message-----
From: dev [mailto:[email protected]] On Behalf Of Jerin Jacob
Sent: Friday, October 26, 2018 10:35 PM
To: Yigit, Ferruh <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; Zhang, Qi Z <[email protected]>; Xing, Beilei <[email protected]>; Lu, Wenzhuo <[email protected]>; Ananyev, Konstantin <[email protected]>
Subject: Re: [dpdk-dev]DEV_RX_OFFLOAD_VLAN_EXTENDoffload-----Original Message-----
Quoted 7 lines
Date: Fri, 26 Oct 2018 14:40:42 +0100
From: Ferruh Yigit <[email protected]>
To: Jerin Jacob <[email protected]>, "[email protected]"
<[email protected]>
CC: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>,Quoted 9 lines
<[email protected]>, "[email protected]"
<[email protected]>, Wenzhuo Lu <[email protected]>, Konstantin Ananyev <[email protected]>
Subject: Re: [dpdk-dev]DEV_RX_OFFLOAD_VLAN_EXTENDoffload
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.9.1Quoted 3 lines
Quoted 2 lines · Jerin Jacob
Does anyone know the expectation of
DEV_RX_OFFLOAD_VLAN_EXTENDQuoted 6 lines
Quoted 6 lines
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.
Quoted 9 lines
Quoted 9 lines
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 isadded by the host.
Quoted 7 lines
Quoted 6 lines
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 typeQuoted 7 lines
Quoted 4 lines
Quoted 1 line
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_STRIPExcuse me, I have some thought, is that right?
maybeDEV_RX_OFFLOAD_QINQ_STRIPand
DEV_RX_OFFLOAD_VLAN_EXTENDis just two thing that play a different role each.Quoted 1 line
DEV_RX_OFFLOAD_VLAN_EXTENDtell NIC to recognize QinQ PACKETS, it isa filter for NIC.
Quoted 1 line
DEV_RX_OFFLOAD_QINQ_STRIPtell nic to strip 2 inner and outer vlan head
Quoted 9 lines
when moving packets from nic to host memory.
Quoted 1 line
I40e NIC is the normative terms when handling qinq packets.
Yes, it makes sense if the meaning of
DEV_RX_OFFLOAD_VLAN_EXTENDis QINQ filter. But it looks like not, as .vlan_filter_set ethdev callback accepts only single vlan id as "uint16_tvlan_id".
If it needs to be treated as QinQ filter then QinQvlan_idsneeds 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.
Quoted 3 lines
Probably we may need to deprecate these vlan API in long-term and enable it through
rte_flow.
Good idea!
Quoted 19 lines
Quoted 14 lines
Quoted 14 lines
Quoted 14 lines
"
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. <...>
"Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
And it in this mode hw doesn't insert or strip the outer VLAN, it expect SW does it. The ethernet type is not
0x88A8but can be anything set on EXVET.VET_EXT. So looks like it is to let switch to add customVLAN
Quoted 1 line
Quoted 1 line
tags and NIC to ignore them.
05/11/2018 05:22, Zhao1, Wei:
Quoted 58 lines
From: Jerin Jacob [mailto:[email protected]]
Quoted 42 lines
From: "Zhao1, Wei" <[email protected]>
Quoted 29 lines
From: dev [mailto:[email protected]] On Behalf Of Jerin Jacob
Quoted 28 lines
From: Ferruh Yigit <[email protected]>
Quoted 3 lines · Jerin Jacob
Quoted 2 lines
Does anyone know the expectation of
DEV_RX_OFFLOAD_VLAN_EXTENDQuoted 6 lines
Quoted 6 lines
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.
Quoted 9 lines
Quoted 9 lines
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 isadded by the host.
Quoted 7 lines
Quoted 6 lines
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 typeQuoted 7 lines
Quoted 4 lines
Quoted 1 line
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_STRIPExcuse me, I have some thought, is that right?
maybeDEV_RX_OFFLOAD_QINQ_STRIPand
DEV_RX_OFFLOAD_VLAN_EXTENDis just two thing that play a different role each.Quoted 1 line
DEV_RX_OFFLOAD_VLAN_EXTENDtell NIC to recognize QinQ PACKETS, it isa filter for NIC.
Quoted 1 line
DEV_RX_OFFLOAD_QINQ_STRIPtell nic to strip 2 inner and outer vlan headQuoted 9 lines
when moving packets from nic to host memory.
Quoted 1 line
I40e NIC is the normative terms when handling qinq packets.
Yes, it makes sense if the meaning of
DEV_RX_OFFLOAD_VLAN_EXTENDis QINQ filter. But it looks like not, as .vlan_filter_set ethdev callback accepts only single vlan id as "uint16_tvlan_id".
If it needs to be treated as QinQ filter then QinQvlan_idsneeds to be send to driver through some means.Yes,
DEV_RX_OFFLOAD_VLAN_EXTENDcan enable the qinq filter, but I do not find the way to config QinQvlan_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.Quoted 1 line
Quoted 4 lines
Quoted 2 lines
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.
Quoted 122 lines
-----Original Message-----
From: Zhao1, Wei
Sent: Monday, November 5, 2018 12:22 PM
To: 'Jerin Jacob' <[email protected]>
Cc: Yigit, Ferruh <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; Zhang, Qi Z <[email protected]>; Xing, Beilei <[email protected]>; Lu, Wenzhuo <[email protected]>; Ananyev, Konstantin <[email protected]>
Subject: RE: [dpdk-dev]DEV_RX_OFFLOAD_VLAN_EXTENDoffloadHi, Jerin Jacob
Quoted 11 lines
-----Original Message-----
From: Jerin Jacob [mailto:[email protected]]
Sent: Thursday, November 1, 2018 6:34 PM
To: Zhao1, Wei <[email protected]>
Cc: Yigit, Ferruh <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; Zhang, Qi Z <[email protected]>; Xing, Beilei <[email protected]>; Lu, Wenzhuo <[email protected]>; Ananyev, Konstantin <[email protected]>
Subject: Re: [dpdk-dev]DEV_RX_OFFLOAD_VLAN_EXTENDoffloadQuoted 20 lines
-----Original Message-----
Quoted 19 lines
Date: Thu, 1 Nov 2018 09:50:12 +0000
From: "Zhao1, Wei" <[email protected]>
To: Jerin Jacob <[email protected]>, "Yigit, Ferruh"
<[email protected]>
CC: "[email protected]" <[email protected]>, "[email protected]"
<[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "Zhang, Qi Z" <[email protected]>,
"Xing, Beilei" <[email protected]>, "Lu, Wenzhuo" <[email protected]>, "Ananyev, Konstantin" <[email protected]>
Subject: RE: [dpdk-dev]DEV_RX_OFFLOAD_VLAN_EXTENDoffloadQuoted 5 lines
-----Original Message-----
From: dev [mailto:[email protected]] On Behalf Of Jerin Jacob
Sent: Friday, October 26, 2018 10:35 PM
To: Yigit, Ferruh <[email protected]>
Cc: [email protected]; [email protected];Quoted 53 lines
Quoted 53 lines
Quoted 53 lines
[email protected]; Zhang, Qi Z <[email protected]>; Xing, Beilei <[email protected]>; Lu, Wenzhuo <[email protected]>; Ananyev, Konstantin <[email protected]>
Subject: Re: [dpdk-dev]DEV_RX_OFFLOAD_VLAN_EXTENDoffload-----Original Message-----
Quoted 7 lines
Date: Fri, 26 Oct 2018 14:40:42 +0100
From: Ferruh Yigit <[email protected]>
To: Jerin Jacob <[email protected]>, "[email protected]"
<[email protected]>
CC: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>,Quoted 9 lines
<[email protected]>, "[email protected]"
<[email protected]>, Wenzhuo Lu <[email protected]>, Konstantin Ananyev <[email protected]>
Subject: Re: [dpdk-dev]DEV_RX_OFFLOAD_VLAN_EXTENDoffload
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.9.1Quoted 3 lines
Quoted 2 lines · Jerin Jacob
Does anyone know the expectation of
DEV_RX_OFFLOAD_VLAN_EXTENDQuoted 6 lines
Quoted 6 lines
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.
Quoted 9 lines
Quoted 9 lines
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 isadded by the host.
Quoted 8 lines
Quoted 6 lines
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:
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
Yes. QinQ there is an already an offload called
DEV_RX_OFFLOAD_QINQ_STRIPExcuse me, I have some thought, is that right?
maybeDEV_RX_OFFLOAD_QINQ_STRIPand
DEV_RX_OFFLOAD_VLAN_EXTENDis just two thing that play a different role each.Quoted 1 line
DEV_RX_OFFLOAD_VLAN_EXTENDtell NIC to recognize QinQ PACKETS, itis
Quoted 12 lines
a filter for NIC.
Quoted 2 lines
DEV_RX_OFFLOAD_QINQ_STRIPtell nic to strip 2 inner and outer vlan headwhen moving packets from nic to host memory.
Quoted 1 line
I40e NIC is the normative terms when handling qinq packets.
Yes, it makes sense if the meaning of
DEV_RX_OFFLOAD_VLAN_EXTENDis QINQ filter. But it looks like not, as .vlan_filter_set ethdev callback accepts only single vlan id as "uint16_tvlan_id". If it needs to be treated as QinQ filter then QinQvlan_idsneeds to be send to driver through some means.
Quoted 5 lines
Yes,
DEV_RX_OFFLOAD_VLAN_EXTENDcan enable the qinq filter, but I do not find the way to config QinQvlan_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".
Quoted 27 lines
Quoted 4 lines
Probably we may need to deprecate these vlan API in long-term and enable it through
rte_flow.Good idea!
Quoted 20 lines
Quoted 14 lines
Quoted 14 lines
Quoted 14 lines
"
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. <...>
"Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
And it in this mode hw doesn't insert or strip the outer VLAN, it expect SW does it. The ethernet type is not
0x88A8but can be anything set on EXVET.VET_EXT. So looks like it is to let switch to add customVLAN
Quoted 1 line
Quoted 1 line
tags and NIC to ignore them.