From: Paolo Abeni <redacted>
Date: Tue, 11 Oct 2016 19:15:44 +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.
Also the connected mode maximum mtu is reduced by 16 bytes to
cope with the increased hard header len.
After this commit, IPoIB performances are back to pre-regression
value.
Fixes: 9207f9d45b0a ("net: preserve IP control block during GSO segmentation")
Signed-off-by: Paolo Abeni <redacted>
Not providing an accurate hard_header_len causes many problems.
In fact we recently fixed the mlxsw driver to stop doing this.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2016-10-13 at 10:24 -0400, David Miller wrote:
From: Paolo Abeni <pabeni@redhat.com>
Date: Tue, 11 Oct 2016 19:15:44 +0200
quoted
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.
Also the connected mode maximum mtu is reduced by 16 bytes to
cope with the increased hard header len.
After this commit, IPoIB performances are back to pre-regression
value.
Fixes: 9207f9d45b0a ("net: preserve IP control block during GSO segmentation")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Not providing an accurate hard_header_len causes many problems.
In fact we recently fixed the mlxsw driver to stop doing this.
AFAICS the mlxsw did a different thing, adding an additional header in
the xmit function and pushing packets in the network stack with a mac
length different from the declared hard header length
The hard header specified by the IPoIB driver is build in the create()
header_ops and its length matches the mac header length of the packets
pushed into the network stack by such driver. GRO works correctly on top
of that. From the networking stack PoV the hard_header_len should be
'accurate'.
Can you please give more details on the problem that may arise from
this ?
thank you,
Paolo