Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

2016-07-08 Thread Roland Dreier
On Fri, Jul 8, 2016 at 9:51 AM, Jason Gunthorpe 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

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

2016-07-08 Thread Jason Gunthorpe
On Fri, Jul 08, 2016 at 07:18:11AM -0700, Roland Dreier wrote: > On Thu, Jul 7, 2016 at 4:14 PM, Jason Gunthorpe > wrote: > > We have neighbour_priv, and ndo_neigh_construct/destruct now .. > > > > A first blush that would seem to be enough to let ipoib store the

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

2016-07-08 Thread Roland Dreier
On Thu, Jul 7, 2016 at 4:14 PM, Jason Gunthorpe wrote: > We have neighbour_priv, and ndo_neigh_construct/destruct now .. > > A first blush that would seem to be enough to let ipoib store the AH > and other path information in the neigh and avoid the cb? At least

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

2016-07-07 Thread Jason Gunthorpe
On Thu, Jul 07, 2016 at 03:01:40PM -0700, Roland Dreier wrote: > The reason we moved to the cb storage is that in the past, trying to > hide some data in the actual skb buffer that we don't actually send We have neighbour_priv, and ndo_neigh_construct/destruct now .. A first blush that would

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

2016-07-07 Thread Alexander Duyck
On Thu, Jul 7, 2016 at 3:01 PM, Roland Dreier wrote: >>> struct skb_gso_cb { >>> int mac_offset; >>> int encap_level; >>> __u16 csum_start; >>> }; > >> This is based on an out-dated version of this struct. The 4.7 RC >> kernel has a few

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

2016-07-07 Thread Roland Dreier
>> struct skb_gso_cb { >> int mac_offset; >> int encap_level; >> __u16 csum_start; >> }; > This is based on an out-dated version of this struct. The 4.7 RC > kernel has a few more fields that were added to support local checksum > offload for encapsulated

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

2016-07-07 Thread Alexander Duyck
On Wed, Jul 6, 2016 at 11:25 PM, Roland Dreier wrote: > On Thu, Jan 7, 2016 at 3:00 AM, Konstantin Khlebnikov > wrote: >> Or just shift GSO CB and add couple checks like >> BUILD_BUG_ON(sizeof(SKB_GSO_CB(skb)->room) < sizeof(*IPCB(skb))); > >

Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

2016-07-07 Thread Roland Dreier
On Thu, Jan 7, 2016 at 3:00 AM, Konstantin Khlebnikov wrote: > Or just shift GSO CB and add couple checks like > BUILD_BUG_ON(sizeof(SKB_GSO_CB(skb)->room) < sizeof(*IPCB(skb))); Resurrecting this old thread, because the patch that ultimately went upstream (commit 9207f9d45b0a