[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAL1RGDWw95yvRykA6gfSnq6nGLcRLy+4aXu78j4u8H=Qw5B40g@mail.gmail.com>
Date: Fri, 8 Jul 2016 14:17:31 -0700
From: Roland Dreier <roland@...estorage.com>
To: Jason Gunthorpe <jgunthorpe@...idianresearch.com>
Cc: Alexander Duyck <alexander.duyck@...il.com>,
Konstantin Khlebnikov <koct9i@...il.com>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
Florian Westphal <fw@...len.de>,
Thadeu Lima de Souza Cascardo <cascardo@...hat.com>,
Cong Wang <xiyou.wangcong@...il.com>,
Linux Kernel Network Developers <netdev@...r.kernel.org>,
David Miller <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Resurrecting due to huge ipoib perf regression - [BUG] skb
corruption and kernel panic at forwarding with fragmentation
On Fri, Jul 8, 2016 at 9:51 AM, Jason Gunthorpe
<jgunthorpe@...idianresearch.com> wrote:
> So, it appears, the dst and neigh can be used for all performances cases.
>
> For the non performance dst == null case, can we just burn cycles and
> stuff the daddr in front of the packet at hardheader time, even if we
> have to copy?
OK, sounds interesting.
Unfortunately the scope of this work has gotten to the point where I
can't take it on right now. My system is running 4.4.y for now
(before struct skb_gso_cb grew) so I think shrinking struct skb_gso_cb
to 8 bytes plus changing SKB_SGO_CB_OFFSET to 20 will work for now.
Hope someone is able to come up with a real fix before I need to
upgrade to 4.10.y...
- R.
Powered by blists - more mailing lists