From: "Loftus, Ciara" <ciara.loftus@intel.com>
To: "Richardson, Bruce" <bruce.richardson@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"Medvedkin, Vladimir" <vladimir.medvedkin@intel.com>
Subject: RE: [PATCH 1/3] net/iavf: support qinq insertion offload for scalar path
Date: Tue, 5 Aug 2025 11:09:57 +0000 [thread overview]
Message-ID: <DM3PPF7D18F34A15BEE3066942172FC92C28E22A@DM3PPF7D18F34A1.namprd11.prod.outlook.com> (raw)
In-Reply-To: <aIdc_kAgHNGL853b@bricha3-mobl1.ger.corp.intel.com>
>
> On Thu, Jun 19, 2025 at 01:36:56PM +0000, Ciara Loftus wrote:
> > Enable Tx QINQ offload if the VF reports support for inserting both an
> > outer and inner VLAN tag. The VF capabilities report the locations for
> > placing each of the tags - either L2TAG1 in the tx descriptor or L2TAG2
> > in the context descriptor. Use this information to configure the
> > descriptors correctly.
> > This offload was previously incorrectly reported as always supported in
> > the device configuration, so this is corrected.
> >
> > Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
> > ---
> > doc/guides/nics/features/iavf.ini | 1 +
> > drivers/net/intel/iavf/iavf_ethdev.c | 8 +++-
> > drivers/net/intel/iavf/iavf_rxtx.c | 55 +++++++++++++++++++++-------
> > 3 files changed, 48 insertions(+), 16 deletions(-)
> >
> > diff --git a/doc/guides/nics/features/iavf.ini
> b/doc/guides/nics/features/iavf.ini
> > index ce9860e963..61c4742197 100644
> > --- a/doc/guides/nics/features/iavf.ini
> > +++ b/doc/guides/nics/features/iavf.ini
> > @@ -29,6 +29,7 @@ Traffic manager = Y
> > Inline crypto = Y
> > CRC offload = Y
> > VLAN offload = P
> > +QinQ offload = P
> > L3 checksum offload = Y
> > L4 checksum offload = Y
> > Timestamp offload = Y
> > diff --git a/drivers/net/intel/iavf/iavf_ethdev.c
> b/drivers/net/intel/iavf/iavf_ethdev.c
> > index b3dacbef84..d058b87d54 100644
> > --- a/drivers/net/intel/iavf/iavf_ethdev.c
> > +++ b/drivers/net/intel/iavf/iavf_ethdev.c
> > @@ -622,7 +622,7 @@ iavf_dev_vlan_insert_set(struct rte_eth_dev *dev)
> > return 0;
> >
> > enable = !!(dev->data->dev_conf.txmode.offloads &
> > - RTE_ETH_TX_OFFLOAD_VLAN_INSERT);
> > + (RTE_ETH_TX_OFFLOAD_VLAN_INSERT |
> RTE_ETH_TX_OFFLOAD_QINQ_INSERT));
> > iavf_config_vlan_insert_v2(adapter, enable);
> >
> > return 0;
> > @@ -1158,7 +1158,6 @@ iavf_dev_info_get(struct rte_eth_dev *dev, struct
> rte_eth_dev_info *dev_info)
> >
> > dev_info->tx_offload_capa =
> > RTE_ETH_TX_OFFLOAD_VLAN_INSERT |
> > - RTE_ETH_TX_OFFLOAD_QINQ_INSERT |
> > RTE_ETH_TX_OFFLOAD_IPV4_CKSUM |
> > RTE_ETH_TX_OFFLOAD_UDP_CKSUM |
> > RTE_ETH_TX_OFFLOAD_TCP_CKSUM |
> > @@ -1182,6 +1181,11 @@ iavf_dev_info_get(struct rte_eth_dev *dev,
> struct rte_eth_dev_info *dev_info)
> > if (vf->vf_res->vf_cap_flags & VIRTCHNL_VF_CAP_PTP)
> > dev_info->rx_offload_capa |=
> RTE_ETH_RX_OFFLOAD_TIMESTAMP;
> >
> > + if (vf->vf_res->vf_cap_flags & VIRTCHNL_VF_OFFLOAD_VLAN_V2 &&
> > + vf->vlan_v2_caps.offloads.insertion_support.inner
> &&
> > + vf->vlan_v2_caps.offloads.insertion_support.outer)
> > + dev_info->tx_offload_capa |=
> RTE_ETH_TX_OFFLOAD_QINQ_INSERT;
> > +
> > if (iavf_ipsec_crypto_supported(adapter)) {
> > dev_info->rx_offload_capa |=
> RTE_ETH_RX_OFFLOAD_SECURITY;
> > dev_info->tx_offload_capa |=
> RTE_ETH_TX_OFFLOAD_SECURITY;
> > diff --git a/drivers/net/intel/iavf/iavf_rxtx.c
> b/drivers/net/intel/iavf/iavf_rxtx.c
> > index 5411eb6897..1ce9de0699 100644
> > --- a/drivers/net/intel/iavf/iavf_rxtx.c
> > +++ b/drivers/net/intel/iavf/iavf_rxtx.c
> > @@ -797,17 +797,32 @@ iavf_dev_tx_queue_setup(struct rte_eth_dev
> *dev,
> > &adapter-
> >vf.vlan_v2_caps.offloads.insertion_support;
> > uint32_t insertion_cap;
> >
> > - if (insertion_support->outer)
> > - insertion_cap = insertion_support->outer;
> > - else
> > - insertion_cap = insertion_support->inner;
> > -
> > - if (insertion_cap & VIRTCHNL_VLAN_TAG_LOCATION_L2TAG1)
> {
> > - txq->vlan_flag =
> IAVF_TX_FLAGS_VLAN_TAG_LOC_L2TAG1;
> > - PMD_INIT_LOG(DEBUG, "VLAN insertion_cap:
> L2TAG1");
> > - } else if (insertion_cap &
> VIRTCHNL_VLAN_TAG_LOCATION_L2TAG2) {
> > - txq->vlan_flag =
> IAVF_TX_FLAGS_VLAN_TAG_LOC_L2TAG2;
> > - PMD_INIT_LOG(DEBUG, "VLAN insertion_cap:
> L2TAG2");
> > + if (insertion_support->outer ==
> VIRTCHNL_VLAN_UNSUPPORTED ||
> > + insertion_support->inner ==
> VIRTCHNL_VLAN_UNSUPPORTED) {
> > + /* Only one insertion is supported. */
> > + if (insertion_support->outer)
> > + insertion_cap = insertion_support->outer;
> > + else
> > + insertion_cap = insertion_support->inner;
> > +
> > + if (insertion_cap &
> VIRTCHNL_VLAN_TAG_LOCATION_L2TAG1) {
> > + txq->vlan_flag =
> IAVF_TX_FLAGS_VLAN_TAG_LOC_L2TAG1;
> > + PMD_INIT_LOG(DEBUG, "VLAN insertion_cap:
> L2TAG1");
> > + } else if (insertion_cap &
> VIRTCHNL_VLAN_TAG_LOCATION_L2TAG2) {
> > + txq->vlan_flag =
> IAVF_TX_FLAGS_VLAN_TAG_LOC_L2TAG2;
> > + PMD_INIT_LOG(DEBUG, "VLAN insertion_cap:
> L2TAG2");
>
> Is this scenario possible - we only support insertion of a single vlan tag,
> and it's to go in the context descriptor. In this case, do we not need to
> add in the VLAN offload flag to the list of offloads needing a context
> descriptor below?
This scenario is possible. It's the case I hit when I test with a VF from my Fortville card.
This code block is the same as what's in the existing code, it's wrapped around a new if condition checking if only one insertion capability is supported (inner or outer). The new code is in the else {}.
No update is needed to iavf_calc_context_desc because what you are describing is already in place.
>
> > + }
> > + } else {
> > + /* Both outer and inner insertion supported. */
> > + if (insertion_support->inner &
> VIRTCHNL_VLAN_TAG_LOCATION_L2TAG1) {
> > + txq->vlan_flag =
> IAVF_TX_FLAGS_VLAN_TAG_LOC_L2TAG1;
> > + PMD_INIT_LOG(DEBUG, "Inner VLAN
> insertion_cap: L2TAG1");
> > + PMD_INIT_LOG(DEBUG, "Outer VLAN
> insertion_cap: L2TAG2");
> > + } else {
> > + txq->vlan_flag =
> IAVF_TX_FLAGS_VLAN_TAG_LOC_L2TAG2;
> > + PMD_INIT_LOG(DEBUG, "Inner VLAN
> insertion_cap: L2TAG2");
> > + PMD_INIT_LOG(DEBUG, "Outer VLAN
> insertion_cap: L2TAG1");
> > + }
> > }
> > } else {
> > txq->vlan_flag = IAVF_TX_FLAGS_VLAN_TAG_LOC_L2TAG1;
> > @@ -2391,7 +2406,7 @@ iavf_calc_context_desc(struct rte_mbuf *mb,
> uint8_t vlan_flag)
> > uint64_t flags = mb->ol_flags;
> > if (flags & (RTE_MBUF_F_TX_TCP_SEG | RTE_MBUF_F_TX_UDP_SEG |
> > RTE_MBUF_F_TX_TUNNEL_MASK |
> RTE_MBUF_F_TX_OUTER_IP_CKSUM |
> > - RTE_MBUF_F_TX_OUTER_UDP_CKSUM))
> > + RTE_MBUF_F_TX_OUTER_UDP_CKSUM | RTE_MBUF_F_TX_QINQ))
> > return 1;
>
> In this check, do we need to take into account possible case for only a
> single vlan offload, and requiring an L2TAG2 field for it?
This already exists. Here's what's already there:
if (flags & RTE_MBUF_F_TX_VLAN &&
vlan_flag & IAVF_TX_FLAGS_VLAN_TAG_LOC_L2TAG2)
return 1;
Thanks,
Ciara
>
> /Bruce
prev parent reply other threads:[~2025-08-05 11:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-19 13:36 Ciara Loftus
2025-06-19 13:36 ` [PATCH 2/3] net/iavf: fix tx vector path selection logic Ciara Loftus
2025-06-19 13:36 ` [PATCH 3/3] net/iavf: support vlan insertion offload for the avx-512 path Ciara Loftus
2025-07-28 11:20 ` [PATCH 1/3] net/iavf: support qinq insertion offload for scalar path Bruce Richardson
2025-08-05 11:09 ` Loftus, Ciara [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DM3PPF7D18F34A15BEE3066942172FC92C28E22A@DM3PPF7D18F34A1.namprd11.prod.outlook.com \
--to=ciara.loftus@intel.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=vladimir.medvedkin@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).