DPDK patches and discussions
 help / color / mirror / Atom feed
From: Kevin Traynor <ktraynor@redhat.com>
To: "Zhou, YidingX" <yidingx.zhou@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [PATCH v2] net/iavf: revert fix VLAN insertion
Date: Thu, 20 Oct 2022 08:47:47 +0100	[thread overview]
Message-ID: <30c5f90a-acd5-eacb-7ad9-8e8e6819d67d@redhat.com> (raw)
In-Reply-To: <DM5PR1101MB210785179B34A4EAF87A3780852A9@DM5PR1101MB2107.namprd11.prod.outlook.com>

On 20/10/2022 02:33, Zhou, YidingX wrote:
> 
> 
>> -----Original Message-----
>> From: Kevin Traynor <ktraynor@redhat.com>
>> Sent: Wednesday, October 19, 2022 4:53 PM
>> To: Zhou, YidingX <yidingx.zhou@intel.com>; dev@dpdk.org
>> Subject: Re: [PATCH v2] net/iavf: revert fix VLAN insertion
>>
>> On 19/10/2022 08:54, Yiding Zhou wrote:
>>> When the kernel driver tells to use the L2TAG2 field for VLAN
>>> insertion, the context descriptor needs to be used. There is an issue
>>> on the vector Tx path, because it does not support the context descriptor.
>>>
>>> The previous commit forces to select normal path to avoid the above
>>> issue, but it results in a performance loss of around 40%. So it needs
>>> to be reverted and the original issue needed to be fixed by rework.
>>>
>>
>> Thank you, that is a much clearer explanation.
>>
>> Now on the approach, the commit being reverted says:
>> "When the driver tells the VF to insert VLAN tag using the L2TAG2 field, vector
>> Tx path does not use Tx context descriptor and would cause VLAN tag inserted
>> into the wrong location."
>>
>> So it means this revert is solving a performance regression, but re-introducing
>> the functional issue above.
>>
>> Is there a correct fix for the original issue sent that can be applied too? If not,
>> wouldn't it be better to wait until it is before doing the revert?
>>
> 
> Sorry, there is no correct fix yet.
> We plan to support context descriptor on vector path to fix the original issue,
> It may take more time and cannot be completed within this cycle.
> 

ok, but you didn't answer the second question.

"When the driver tells the VF to insert VLAN tag using the L2TAG2 field, 
vector Tx path does not use Tx context descriptor and would cause VLAN 
tag inserted into the wrong location."

Please explain your justification for (re-)introducing this bug?

Why is better to get (corrupt?) packets with incorrect VLAN tags than 
lose performance for this case? Or have I mis-interpreted the patches.


>>> To reverts
>>> commit 0d58caa7d6d1 ("net/iavf: fix VLAN insertion")
>>>
>>> Fixes: 0d58caa7d6d1 ("net/iavf: fix VLAN insertion")
>>>
>>> Signed-off-by: Yiding Zhou <yidingx.zhou@intel.com>
>>> ---
>>>    drivers/net/iavf/iavf_rxtx_vec_common.h | 3 ---
>>>    1 file changed, 3 deletions(-)
>>>
>>> diff --git a/drivers/net/iavf/iavf_rxtx_vec_common.h
>>> b/drivers/net/iavf/iavf_rxtx_vec_common.h
>>> index 4ab22c6b2b..a59cb2ceee 100644
>>> --- a/drivers/net/iavf/iavf_rxtx_vec_common.h
>>> +++ b/drivers/net/iavf/iavf_rxtx_vec_common.h
>>> @@ -253,9 +253,6 @@ iavf_tx_vec_queue_default(struct iavf_tx_queue *txq)
>>>    	if (txq->offloads & IAVF_TX_NO_VECTOR_FLAGS)
>>>    		return -1;
>>>
>>> -	if (txq->vlan_flag == IAVF_TX_FLAGS_VLAN_TAG_LOC_L2TAG2)
>>> -		return -1;
>>> -
>>>    	if (txq->offloads & IAVF_TX_VECTOR_OFFLOAD)
>>>    		return IAVF_VECTOR_OFFLOAD_PATH;
>>>
> 


  reply	other threads:[~2022-10-20  7:47 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-18 10:26 [PATCH] " Yiding Zhou
2022-10-18 12:17 ` Kevin Traynor
2022-10-19  7:54 ` [PATCH v2] " Yiding Zhou
2022-10-19  8:53   ` Kevin Traynor
2022-10-20  1:33     ` Zhou, YidingX
2022-10-20  7:47       ` Kevin Traynor [this message]
2022-10-21  2:42         ` Zhou, YidingX
     [not found]           ` <CY4PR1101MB21039FCA7958A8B49BF5521885389@CY4PR1101MB2103.namprd11.prod.outlook.com>
     [not found]             ` <322c348e-3461-c7ab-a845-2782ffce5ef9@redhat.com>
2022-11-03 12:43               ` Kevin Traynor
     [not found]               ` <MWHPR11MB18863EA1EEE5DA7452AF7899E5389@MWHPR11MB1886.namprd11.prod.outlook.com>
2022-11-03 14:42                 ` Kevin Traynor
2022-11-04  6:10 ` [PATCH v3] " Yiding Zhou
2022-11-08  9:26   ` Zhou, YidingX
2022-11-09  0:45   ` Zhang, Qi Z
2022-11-10  2:10     ` Zhou, YidingX
2022-11-10  9:57       ` Zhang, Qi Z
2022-11-11  8:18 ` [PATCH v4] " Yiding Zhou
2022-11-13 16:30 ` [PATCH v5] " Yiding Zhou
2022-11-14  0:52   ` Zhang, Qi Z

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=30c5f90a-acd5-eacb-7ad9-8e8e6819d67d@redhat.com \
    --to=ktraynor@redhat.com \
    --cc=dev@dpdk.org \
    --cc=yidingx.zhou@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).