From: Kevin Traynor <ktraynor@redhat.com>
To: "Zhou, YidingX" <yidingx.zhou@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: "Yang, Qiming" <qiming.yang@intel.com>,
"Zhang, Qi Z" <qi.z.zhang@intel.com>
Subject: Re: [PATCH v2] net/iavf: revert fix VLAN insertion
Date: Thu, 3 Nov 2022 12:43:32 +0000 [thread overview]
Message-ID: <b1b00328-6336-ad00-8c48-0a4bc83d32c2@redhat.com> (raw)
In-Reply-To: <322c348e-3461-c7ab-a845-2782ffce5ef9@redhat.com>
re-adding dev mailing list
On 03/11/2022 10:51, Kevin Traynor wrote:
> On 03/11/2022 10:38, Zhou, YidingX wrote:
>> Hi, Kevin
>>
>> According to suggestion, we did many deep investigation and various attempts, unfortunately that the performance drop(about 40%) caused by
>> the previous commit:
>> 0d58caa7d6d1 ("net/iavf: fix VLAN insertion")
>> Still can not be resolved in this cycle due to tight schedule.
>>
>> Because the performance drop is too serious and the scope of impact is relatively large, we think the previous commit is a mistake.
>
> ok, I'm trying to understand why a performance drop is worse than some
> corrupt packets.
>
> What is the scope of the performance drop? Does the scope impact more
> cases than just when the L2TAG2 is used?
>
> IOW, is it a functional issue in a small use case, and performance issue
> in more use cases? If so, I can understand you wanting to revert.
>
>> For the original bug, we plan to fix it in the next cycle (by supporting L2TAG2 on the vector path).
>>
>
> With the revert, is there a way to disable use of L2TAG2 being used
> while it is incorrect? At very least, the issue should be
> documented/bugzilla so a user can know what doesn't work correctly.
>
>> So we are expecting to revert the above commit from main branch and it should not be merged to stable branch.
>
> It has already been merged but if the decision for main branch is to
> revert, then I can revert on stable also.
>
> thanks,
> Kevin.
>
>> Sorry I'm a little late in explaining the situation. Your understanding would be appreciated.
>>
>> /Yiding
>>
>>> -----Original Message-----
>>> From: Zhou, YidingX
>>> Sent: Friday, October 21, 2022 10:43 AM
>>> To: Kevin Traynor <ktraynor@redhat.com>; dev@dpdk.org
>>> Subject: RE: [PATCH v2] net/iavf: revert fix VLAN insertion
>>>
>>>
>>>
>>>>>> -----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.
>>>>
>>>>
>>> Thanks for your review.
>>> I agree with you. It should not re-introduce functional issue .
>>> This revert is not needed. I will resubmit a new patch for the performance loss.
>>>
>>>>>>> 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;
>>>>>>>
>>>>>
>>
>
next prev parent reply other threads:[~2022-11-03 12:43 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
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 [this message]
[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=b1b00328-6336-ad00-8c48-0a4bc83d32c2@redhat.com \
--to=ktraynor@redhat.com \
--cc=dev@dpdk.org \
--cc=qi.z.zhang@intel.com \
--cc=qiming.yang@intel.com \
--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).