net/iavf: fix segmentation offload buffer size
Checks
Commit Message
This reverts commit ff8b8bcd2ebe, which resulted in incorrect buffer size
being computed for TSO packets.
Fixes: ff8b8bcd2ebe ("net/iavf: fix segmentation offload condition")
Signed-off-by: Radu Nicolau <radu.nicolau@intel.com>
---
drivers/net/iavf/iavf_rxtx.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
Comments
> -----Original Message-----
> From: Radu Nicolau <radu.nicolau@intel.com>
> Sent: Thursday, February 10, 2022 9:09 PM
> To: Wu, Jingjing <jingjing.wu@intel.com>; Xing, Beilei <beilei.xing@intel.com>
> Cc: dev@dpdk.org; Jiang, YuX <yux.jiang@intel.com>; Nicolau, Radu
> <radu.nicolau@intel.com>
> Subject: [PATCH] net/iavf: fix segmentation offload buffer size
>
> This reverts commit ff8b8bcd2ebe, which resulted in incorrect buffer size being
> computed for TSO packets.
>
> Fixes: ff8b8bcd2ebe ("net/iavf: fix segmentation offload condition")
>
> Signed-off-by: Radu Nicolau <radu.nicolau@intel.com>
> ---
> drivers/net/iavf/iavf_rxtx.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
Tested-by: Zhimin Huang <zhiminx.huang@intel.com >
> -----Original Message-----
> From: Huang, ZhiminX <zhiminx.huang@intel.com>
> Sent: Tuesday, February 15, 2022 2:17 PM
> To: Nicolau, Radu <radu.nicolau@intel.com>; Wu, Jingjing
> <jingjing.wu@intel.com>; Xing, Beilei <beilei.xing@intel.com>
> Cc: dev@dpdk.org; Jiang, YuX <yux.jiang@intel.com>; Nicolau, Radu
> <radu.nicolau@intel.com>
> Subject: RE: [PATCH] net/iavf: fix segmentation offload buffer size
>
> > -----Original Message-----
> > From: Radu Nicolau <radu.nicolau@intel.com>
> > Sent: Thursday, February 10, 2022 9:09 PM
> > To: Wu, Jingjing <jingjing.wu@intel.com>; Xing, Beilei
> > <beilei.xing@intel.com>
> > Cc: dev@dpdk.org; Jiang, YuX <yux.jiang@intel.com>; Nicolau, Radu
> > <radu.nicolau@intel.com>
> > Subject: [PATCH] net/iavf: fix segmentation offload buffer size
> >
> > This reverts commit ff8b8bcd2ebe, which resulted in incorrect buffer
> > size being computed for TSO packets.
> >
> > Fixes: ff8b8bcd2ebe ("net/iavf: fix segmentation offload condition")
> >
> > Signed-off-by: Radu Nicolau <radu.nicolau@intel.com>
> > ---
> > drivers/net/iavf/iavf_rxtx.c | 7 ++++---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> Tested-by: Zhimin Huang <zhiminx.huang@intel.com >
Applied to dpdk-next-net-intel.
Thanks
Qi
>
>
On 2/10/2022 1:09 PM, Radu Nicolau wrote:
> This reverts commit ff8b8bcd2ebe, which resulted in incorrect buffer size
> being computed for TSO packets.
>
> Fixes: ff8b8bcd2ebe ("net/iavf: fix segmentation offload condition")
>
Commit 'ff8b8bcd2ebe' was already fixing segmentation offload,
are we having the initial issue back when this patch reverted?
Is there a fix for that initial issue?
+Kevin, Luca,
Since this patch reverts a fix done after 21.11, is there a way
to stop that fix to be merged for 21.11.x?
> Signed-off-by: Radu Nicolau <radu.nicolau@intel.com>
> ---
> drivers/net/iavf/iavf_rxtx.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/iavf/iavf_rxtx.c b/drivers/net/iavf/iavf_rxtx.c
> index b0fed1b992..ba272bb211 100644
> --- a/drivers/net/iavf/iavf_rxtx.c
> +++ b/drivers/net/iavf/iavf_rxtx.c
> @@ -2464,9 +2464,10 @@ iavf_fill_data_desc(volatile struct iavf_tx_desc *desc,
> desc->buffer_addr = rte_mbuf_data_iova(m);
>
> /* calculate data buffer size less set header lengths */
> - if (m->ol_flags & (RTE_MBUF_F_TX_TCP_SEG | RTE_MBUF_F_TX_UDP_SEG)) {
> - if (m->ol_flags & RTE_MBUF_F_TX_TUNNEL_MASK)
> - hdrlen += m->outer_l3_len;
> + if ((m->ol_flags & RTE_MBUF_F_TX_TUNNEL_MASK) &&
> + (m->ol_flags & (RTE_MBUF_F_TX_TCP_SEG |
> + RTE_MBUF_F_TX_UDP_SEG))) {
> + hdrlen += m->outer_l3_len;
> if (m->ol_flags & RTE_MBUF_F_TX_L4_MASK)
> hdrlen += m->l3_len + m->l4_len;
> else
On 15/02/2022 10:06, Ferruh Yigit wrote:
> On 2/10/2022 1:09 PM, Radu Nicolau wrote:
>> This reverts commit ff8b8bcd2ebe, which resulted in incorrect buffer size
>> being computed for TSO packets.
>>
>> Fixes: ff8b8bcd2ebe ("net/iavf: fix segmentation offload condition")
>>
>
> Commit 'ff8b8bcd2ebe' was already fixing segmentation offload,
> are we having the initial issue back when this patch reverted?
> Is there a fix for that initial issue?
>
> +Kevin, Luca,
> Since this patch reverts a fix done after 21.11, is there a way
> to stop that fix to be merged for 21.11.x?
>
This revert patch would show up for us as a relevant one to backport, so
in the worst case where initial fix was already pushed to dpdk.org, the
revert would be taken too and the net result would be ok by release time.
In this case, as the initial fix is not pushed to dpdk.org stable
branches yet and as you have let us know, we can just make a note to
skip it, or remove from a personal staging repo if already backported there.
I'll add an email filter for 'reverts' to catch this so you won't have
to ping manually, but feel free to do that as I suspect (hope :-)) it's
only a handful of patches per release.
Thanks for highlighting, Kevin.
>> Signed-off-by: Radu Nicolau <radu.nicolau@intel.com>
>> ---
>> drivers/net/iavf/iavf_rxtx.c | 7 ++++---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/iavf/iavf_rxtx.c b/drivers/net/iavf/iavf_rxtx.c
>> index b0fed1b992..ba272bb211 100644
>> --- a/drivers/net/iavf/iavf_rxtx.c
>> +++ b/drivers/net/iavf/iavf_rxtx.c
>> @@ -2464,9 +2464,10 @@ iavf_fill_data_desc(volatile struct iavf_tx_desc *desc,
>> desc->buffer_addr = rte_mbuf_data_iova(m);
>>
>> /* calculate data buffer size less set header lengths */
>> - if (m->ol_flags & (RTE_MBUF_F_TX_TCP_SEG | RTE_MBUF_F_TX_UDP_SEG)) {
>> - if (m->ol_flags & RTE_MBUF_F_TX_TUNNEL_MASK)
>> - hdrlen += m->outer_l3_len;
>> + if ((m->ol_flags & RTE_MBUF_F_TX_TUNNEL_MASK) &&
>> + (m->ol_flags & (RTE_MBUF_F_TX_TCP_SEG |
>> + RTE_MBUF_F_TX_UDP_SEG))) {
>> + hdrlen += m->outer_l3_len;
>> if (m->ol_flags & RTE_MBUF_F_TX_L4_MASK)
>> hdrlen += m->l3_len + m->l4_len;
>> else
>
On 2/15/2022 10:06 AM, Ferruh Yigit wrote:
> On 2/10/2022 1:09 PM, Radu Nicolau wrote:
>> This reverts commit ff8b8bcd2ebe, which resulted in incorrect buffer
>> size
>> being computed for TSO packets.
>>
>> Fixes: ff8b8bcd2ebe ("net/iavf: fix segmentation offload condition")
>>
>
> Commit 'ff8b8bcd2ebe' was already fixing segmentation offload,
> are we having the initial issue back when this patch reverted?
> Is there a fix for that initial issue?
The initial issue was around a very specific usecase - IPsec transport
mode TSO and it is very likely back with this revert. But it's a much
less severe impact than general traffic TSO.
On 2/15/2022 10:47 AM, Nicolau, Radu wrote:
>
> On 2/15/2022 10:06 AM, Ferruh Yigit wrote:
>> On 2/10/2022 1:09 PM, Radu Nicolau wrote:
>>> This reverts commit ff8b8bcd2ebe, which resulted in incorrect buffer size
>>> being computed for TSO packets.
>>>
>>> Fixes: ff8b8bcd2ebe ("net/iavf: fix segmentation offload condition")
>>>
>>
>> Commit 'ff8b8bcd2ebe' was already fixing segmentation offload,
>> are we having the initial issue back when this patch reverted?
>> Is there a fix for that initial issue?
> The initial issue was around a very specific usecase - IPsec transport mode TSO and it is very likely back with this revert. But it's a much less severe impact than general traffic TSO.
Got it, so this revert brings back an issue, should
we document this in the commit log of this patch?
Plus should we create a Bugzilla etc to record the
introduced issue?
On 2/15/2022 10:46 AM, Kevin Traynor wrote:
> On 15/02/2022 10:06, Ferruh Yigit wrote:
>> On 2/10/2022 1:09 PM, Radu Nicolau wrote:
>>> This reverts commit ff8b8bcd2ebe, which resulted in incorrect buffer size
>>> being computed for TSO packets.
>>>
>>> Fixes: ff8b8bcd2ebe ("net/iavf: fix segmentation offload condition")
>>>
>>
>> Commit 'ff8b8bcd2ebe' was already fixing segmentation offload,
>> are we having the initial issue back when this patch reverted?
>> Is there a fix for that initial issue?
>>
>> +Kevin, Luca,
>> Since this patch reverts a fix done after 21.11, is there a way
>> to stop that fix to be merged for 21.11.x?
>>
>
> This revert patch would show up for us as a relevant one to backport, so in the worst case where initial fix was already pushed to dpdk.org, the revert would be taken too and the net result would be ok by release time.
>
> In this case, as the initial fix is not pushed to dpdk.org stable branches yet and as you have let us know, we can just make a note to skip it, or remove from a personal staging repo if already backported there.
>
ack
> I'll add an email filter for 'reverts' to catch this so you won't have to ping manually, but feel free to do that as I suspect (hope :-)) it's only a handful of patches per release.
>
Ack.
I was asking for a method, you adding a filter is a way,
but if there is another defined method we (maintainers) can
do it to help LTS maintainers.
Like replying to a patch in stable list with a keyword, like
'do not apply this' to let your scripts to detect it ...
> Thanks for highlighting, Kevin.
>
>>> Signed-off-by: Radu Nicolau <radu.nicolau@intel.com>
>>> ---
>>> drivers/net/iavf/iavf_rxtx.c | 7 ++++---
>>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/net/iavf/iavf_rxtx.c b/drivers/net/iavf/iavf_rxtx.c
>>> index b0fed1b992..ba272bb211 100644
>>> --- a/drivers/net/iavf/iavf_rxtx.c
>>> +++ b/drivers/net/iavf/iavf_rxtx.c
>>> @@ -2464,9 +2464,10 @@ iavf_fill_data_desc(volatile struct iavf_tx_desc *desc,
>>> desc->buffer_addr = rte_mbuf_data_iova(m);
>>> /* calculate data buffer size less set header lengths */
>>> - if (m->ol_flags & (RTE_MBUF_F_TX_TCP_SEG | RTE_MBUF_F_TX_UDP_SEG)) {
>>> - if (m->ol_flags & RTE_MBUF_F_TX_TUNNEL_MASK)
>>> - hdrlen += m->outer_l3_len;
>>> + if ((m->ol_flags & RTE_MBUF_F_TX_TUNNEL_MASK) &&
>>> + (m->ol_flags & (RTE_MBUF_F_TX_TCP_SEG |
>>> + RTE_MBUF_F_TX_UDP_SEG))) {
>>> + hdrlen += m->outer_l3_len;
>>> if (m->ol_flags & RTE_MBUF_F_TX_L4_MASK)
>>> hdrlen += m->l3_len + m->l4_len;
>>> else
>>
>
On 2/15/2022 11:19 AM, Ferruh Yigit wrote:
> On 2/15/2022 10:47 AM, Nicolau, Radu wrote:
>>
>> On 2/15/2022 10:06 AM, Ferruh Yigit wrote:
>>> On 2/10/2022 1:09 PM, Radu Nicolau wrote:
>>>> This reverts commit ff8b8bcd2ebe, which resulted in incorrect
>>>> buffer size
>>>> being computed for TSO packets.
>>>>
>>>> Fixes: ff8b8bcd2ebe ("net/iavf: fix segmentation offload condition")
>>>>
>>>
>>> Commit 'ff8b8bcd2ebe' was already fixing segmentation offload,
>>> are we having the initial issue back when this patch reverted?
>>> Is there a fix for that initial issue?
>> The initial issue was around a very specific usecase - IPsec
>> transport mode TSO and it is very likely back with this revert. But
>> it's a much less severe impact than general traffic TSO.
>
> Got it, so this revert brings back an issue, should
> we document this in the commit log of this patch?
> Plus should we create a Bugzilla etc to record the
> introduced issue?
I plan to follow up with a fix shortly.
As for the commit message, since this was not merged to the LTS and
main, do we really need it?
On 2/15/2022 12:30 PM, Nicolau, Radu wrote:
>
> On 2/15/2022 11:19 AM, Ferruh Yigit wrote:
>> On 2/15/2022 10:47 AM, Nicolau, Radu wrote:
>>>
>>> On 2/15/2022 10:06 AM, Ferruh Yigit wrote:
>>>> On 2/10/2022 1:09 PM, Radu Nicolau wrote:
>>>>> This reverts commit ff8b8bcd2ebe, which resulted in incorrect buffer size
>>>>> being computed for TSO packets.
>>>>>
>>>>> Fixes: ff8b8bcd2ebe ("net/iavf: fix segmentation offload condition")
>>>>>
>>>>
>>>> Commit 'ff8b8bcd2ebe' was already fixing segmentation offload,
>>>> are we having the initial issue back when this patch reverted?
>>>> Is there a fix for that initial issue?
>>> The initial issue was around a very specific usecase - IPsec transport mode TSO and it is very likely back with this revert. But it's a much less severe impact than general traffic TSO.
>>
>> Got it, so this revert brings back an issue, should
>> we document this in the commit log of this patch?
>> Plus should we create a Bugzilla etc to record the
>> introduced issue?
>
> I plan to follow up with a fix shortly.
>
> As for the commit message, since this was not merged to the LTS and main, do we really need it?
>
Not for the LTS but for main repo. We know merging this patch
will introduce an previous issue back but that is not obvious
from the commit log.
I think it helps to document, in commit log, what issue this
commit brings.
On 2/15/2022 12:44 PM, Ferruh Yigit wrote:
> On 2/15/2022 12:30 PM, Nicolau, Radu wrote:
>>
>> On 2/15/2022 11:19 AM, Ferruh Yigit wrote:
>>> On 2/15/2022 10:47 AM, Nicolau, Radu wrote:
>>>>
>>>> On 2/15/2022 10:06 AM, Ferruh Yigit wrote:
>>>>> On 2/10/2022 1:09 PM, Radu Nicolau wrote:
>>>>>> This reverts commit ff8b8bcd2ebe, which resulted in incorrect buffer size
>>>>>> being computed for TSO packets.
>>>>>>
>>>>>> Fixes: ff8b8bcd2ebe ("net/iavf: fix segmentation offload condition")
>>>>>>
>>>>>
>>>>> Commit 'ff8b8bcd2ebe' was already fixing segmentation offload,
>>>>> are we having the initial issue back when this patch reverted?
>>>>> Is there a fix for that initial issue?
>>>> The initial issue was around a very specific usecase - IPsec transport mode TSO and it is very likely back with this revert. But it's a much less severe impact than general traffic TSO.
>>>
>>> Got it, so this revert brings back an issue, should
>>> we document this in the commit log of this patch?
>>> Plus should we create a Bugzilla etc to record the
>>> introduced issue?
>>
>> I plan to follow up with a fix shortly.
>>
Or does it make sense to combine that fix with this patch?
>> As for the commit message, since this was not merged to the LTS and main, do we really need it?
>>
>
> Not for the LTS but for main repo. We know merging this patch
> will introduce an previous issue back but that is not obvious
> from the commit log.
>
> I think it helps to document, in commit log, what issue this
> commit brings.
On 2/15/2022 12:48 PM, Ferruh Yigit wrote:
> On 2/15/2022 12:44 PM, Ferruh Yigit wrote:
>> On 2/15/2022 12:30 PM, Nicolau, Radu wrote:
>>>
>>> On 2/15/2022 11:19 AM, Ferruh Yigit wrote:
>>>> On 2/15/2022 10:47 AM, Nicolau, Radu wrote:
>>>>>
>>>>> On 2/15/2022 10:06 AM, Ferruh Yigit wrote:
>>>>>> On 2/10/2022 1:09 PM, Radu Nicolau wrote:
>>>>>>> This reverts commit ff8b8bcd2ebe, which resulted in incorrect
>>>>>>> buffer size
>>>>>>> being computed for TSO packets.
>>>>>>>
>>>>>>> Fixes: ff8b8bcd2ebe ("net/iavf: fix segmentation offload
>>>>>>> condition")
>>>>>>>
>>>>>>
>>>>>> Commit 'ff8b8bcd2ebe' was already fixing segmentation offload,
>>>>>> are we having the initial issue back when this patch reverted?
>>>>>> Is there a fix for that initial issue?
>>>>> The initial issue was around a very specific usecase - IPsec
>>>>> transport mode TSO and it is very likely back with this revert.
>>>>> But it's a much less severe impact than general traffic TSO.
>>>>
>>>> Got it, so this revert brings back an issue, should
>>>> we document this in the commit log of this patch?
>>>> Plus should we create a Bugzilla etc to record the
>>>> introduced issue?
>>>
>>> I plan to follow up with a fix shortly.
>>>
>
> Or does it make sense to combine that fix with this patch?
>
I sent a v2 that does this. Sorry all for the mess :(
@@ -2464,9 +2464,10 @@ iavf_fill_data_desc(volatile struct iavf_tx_desc *desc,
desc->buffer_addr = rte_mbuf_data_iova(m);
/* calculate data buffer size less set header lengths */
- if (m->ol_flags & (RTE_MBUF_F_TX_TCP_SEG | RTE_MBUF_F_TX_UDP_SEG)) {
- if (m->ol_flags & RTE_MBUF_F_TX_TUNNEL_MASK)
- hdrlen += m->outer_l3_len;
+ if ((m->ol_flags & RTE_MBUF_F_TX_TUNNEL_MASK) &&
+ (m->ol_flags & (RTE_MBUF_F_TX_TCP_SEG |
+ RTE_MBUF_F_TX_UDP_SEG))) {
+ hdrlen += m->outer_l3_len;
if (m->ol_flags & RTE_MBUF_F_TX_L4_MASK)
hdrlen += m->l3_len + m->l4_len;
else