[dpdk-stable] [dpdk-dev] [PATCH v2] net/bnx2x: handle guest vlan for SR-IOV case

Dey, Souvik sodey at rbbn.com
Thu Mar 5 14:51:19 CET 2020


Thanks will do that. And will also try to remove the trailer in the patches. Thanks for pointing it out.

From: dev <dev-bounces at dpdk.org> On Behalf Of Rasesh Mody
Sent: Tuesday, March 3, 2020 6:01 PM
To: Dey, Souvik <sodey at rbbn.com>; Shahed Shaikh <shshaikh at marvell.com>; Jerin Jacob Kollanukkaran <jerinj at marvell.com>; ferruh.yigit at intel.com; thomas at monjalon.net
Cc: dev at dpdk.org; stable at dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2] net/bnx2x: handle guest vlan for SR-IOV case

________________________________
NOTICE: This email was received from an EXTERNAL sender
________________________________

>From: dev <dev-bounces at dpdk.org<mailto:dev-bounces at dpdk.org>> On Behalf Of Dey, Souvik
>Sent: Monday, March 02, 2020 5:29 PM
>
>In case of bnx2xvf pmd, tx packets can support vland id in 2 ways :
>1. setting the mbuf ol_flags=PKT_TX_VLAN_PKT and passing the vlanid in
>mbuf->vlan_tci.
>2. the tx packet itself has the vlan id included in the packet.
>The first case is working as expected but the second case where the vlan id is
>included in thetx packets itself was found not working as expected. To handle
>that we need to properly set the start_bd bitfield and the vlan_or_ethertype
>instead of setting it to just the ethertype in case of VF.
>
>
>Signed-off-by: "Dey, Souvik" <sodey at rbbn.com<mailto:sodey at rbbn.com>>
>---

May be it would be good to use --in-reply-to when generating the patch and resubmit. This will ensure it lands up in the same thread as the first patch.
http://mails.dpdk.org/archives/test-report/2020-March/119108.html<http://mails.dpdk.org/archives/test-report/2020-March/119108.html>

Acked-by: Rasesh Mody <rmody at marvell.com<mailto:rmody at marvell.com>>

>v2:
> * Fix compilation issues.
> * Changed the Subject Line as recommended.
>
>
> drivers/net/bnx2x/bnx2x.c | 20 +++++++++++++++++---
> 1 file changed, 17 insertions(+), 3 deletions(-)
>
>diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c index
>0b4030e..0afa602 100644
>--- a/drivers/net/bnx2x/bnx2x.c
>+++ b/drivers/net/bnx2x/bnx2x.c
>@@ -2216,11 +2216,25 @@ int bnx2x_tx_encap(struct bnx2x_tx_queue *txq,
>struct rte_mbuf *m0)
> tx_start_bd->vlan_or_ethertype =
> rte_cpu_to_le_16(pkt_prod);
> else {
>+ /* when transmitting in a vf, start bd must hold the
>ethertype
>+ * for fw to enforce it
>+ */
> struct rte_ether_hdr *eh =
> rte_pktmbuf_mtod(m0, struct rte_ether_hdr *);
>-
>- tx_start_bd->vlan_or_ethertype =
>- rte_cpu_to_le_16(rte_be_to_cpu_16(eh-
>>ether_type));
>+ /* Still need to consider inband vlan for enforced */
>+ if (eh->ether_type ==
>rte_cpu_to_be_16(RTE_ETHER_TYPE_VLAN)) {
>+ struct rte_vlan_hdr *vh =
>+ (struct rte_vlan_hdr *)(eh + 1);
>+ tx_start_bd->bd_flags.as_bitfield |=
>+ (X_ETH_INBAND_VLAN <<
>+
> ETH_TX_BD_FLAGS_VLAN_MODE_SHIFT);
>+ tx_start_bd->vlan_or_ethertype =
>+ rte_cpu_to_le_16(ntohs(vh-
>>vlan_tci));
>+ } else {
>+ tx_start_bd->vlan_or_ethertype =
>+ (rte_cpu_to_le_16
>+ (rte_be_to_cpu_16(eh-
>>ether_type)));
>+ }
> }
> }
>
>--
>2.9.3
>
>
>-----------------------------------------------------------------------------------------------
>------------------------
>Notice: This e-mail together with any attachments may contain information of
>Ribbon Communications Inc. that
>is confidential and/or proprietary for the sole use of the intended recipient.
>Any review, disclosure, reliance or
>distribution by others or forwarding without express permission is strictly
>prohibited. If you are not the intended
>recipient, please notify the sender immediately and then delete all copies,
>including any attachments.
>-----------------------------------------------------------------------------------------------
>------------------------

When we are doing open source work, the contents of above footer is not compatible with what we are doing. Please remove the footer in patches and mailing list interactions for future.


-----------------------------------------------------------------------------------------------------------------------
Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. that
is confidential and/or proprietary for the sole use of the intended recipient.  Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly prohibited.  If you are not the intended
recipient, please notify the sender immediately and then delete all copies, including any attachments.
-----------------------------------------------------------------------------------------------------------------------


More information about the stable mailing list