Re: [PATCH v3] IB/ipoib: move back IB LL address into the hard header
From: Paolo Abeni
Date: Thu, 13 Oct 2016 18:26:56 +0200
> After the commit 9207f9d45b0a ("net: preserve IP control block
> during GSO segmentation"), the GSO CB and the IPoIB CB conflict.
> That destroy the IPoIB address information cached there,
> causing a severe performance regression, as better described here:
>
> http://marc.info/?l=linux-kernel&m=146787279825501&w=2
>
> This change moves the data cached by the IPoIB driver from the
> skb control lock into the IPoIB hard header, as done before
> the commit 936d7de3d736 ("IPoIB: Stop lying about hard_header_len
> and use skb->cb to stash LL addresses").
> In order to avoid GRO issue, on packet reception, the IPoIB driver
> stash into the skb a dummy pseudo header, so that the received
> packets have actually a hard header matching the declared length.
> To avoid changing the connected mode maximum mtu, the allocated
> head buffer size is increased by the pseudo header length.
>
> After this commit, IPoIB performances are back to pre-regression
> value.
>
> v2 -> v3: rebased
> v1 -> v2: avoid changing the max mtu, increasing the head buf size
>
> Fixes: 9207f9d45b0a ("net: preserve IP control block during GSO segmentation")
> Signed-off-by: Paolo Abeni
Applied and queued up for -stable, thanks.
Re: [PATCH v3] IB/ipoib: move back IB LL address into the hard header
On Fri, 2016-10-14 at 13:23 +0300, Or Gerlitz wrote: > > Paolo, > > Is this fix backportable to any kernel since the breakage? yes, AFAIK this is beck-portable. > AFAIR, > Roland mentioned > that a 2nd change introduced in 4.7-rc1 changed things a bit more such > that the fix > he had in his head didn't apply any more. If you refer to shrinking both IPoIB and gso control buffer, as proposed by Roland in: http://marc.info/?l=linux-kernel&m=146787279825501&w=2 that will not work, since the gso control buffer is grown a bit since the first time the bug was detected. This patch does not have that sort of issue. > I am still travelling after netdev and would like to put an eye on the > patch and also see that @mellanox.com someone Not sure if that helps, but a 3rd party has already confirmed privately that this patch fixes the bug for them. Paolo
Re: [PATCH v3] IB/ipoib: move back IB LL address into the hard header
On Thu, Oct 13, 2016 at 7:26 PM, Paolo Abeni wrote:
> After the commit 9207f9d45b0a ("net: preserve IP control block
> during GSO segmentation"), the GSO CB and the IPoIB CB conflict.
the commit --> commit (remove the word "the" to make the sentence a
bit more clear)
> That destroy the IPoIB address information cached there,
> causing a severe performance regression, as better described here:
> http://marc.info/?l=linux-kernel&m=146787279825501&w=2
I don't think that links into this archive last for long.. try to find
something better
best if you can provide quick wording telling what is broken (e.g HW LSO)
> This change moves the data cached by the IPoIB driver from the
> skb control lock into the IPoIB hard header, as done before
lock --> block ?
> the commit 936d7de3d736 ("IPoIB: Stop lying about hard_header_len
the commit --> commit
> and use skb->cb to stash LL addresses").
> In order to avoid GRO issue, on packet reception, the IPoIB driver
> stash into the skb a dummy pseudo header, so that the received
> packets have actually a hard header matching the declared length.
> To avoid changing the connected mode maximum mtu, the allocated
> head buffer size is increased by the pseudo header length.
> After this commit, IPoIB performances are back to pre-regression
> value.
>
> v2 -> v3: rebased
> v1 -> v2: avoid changing the max mtu, increasing the head buf size
> Fixes: 9207f9d45b0a ("net: preserve IP control block during GSO segmentation")
> Signed-off-by: Paolo Abeni
Paolo,
Is this fix backportable to any kernel since the breakage? AFAIR,
Roland mentioned
that a 2nd change introduced in 4.7-rc1 changed things a bit more such
that the fix
he had in his head didn't apply any more.
Dave, Doug
I am still travelling after netdev and would like to put an eye on the
patch and also see that @mellanox.com someone
provides a tested-by ack. Considering the fact that the bug is soon
to (de-)celebrate it's 1st anniversary and as we're still not in rc1,
the patch has enough time to get into 4.9... can you let it be here
for another week or so?
Or
