Re: [RFC for accelerated IPoIB 00/27] Enhanced mode for IPoIB driver

ira.weiny
2017-03-02T20:30:00Z

On Wed, Mar 01, 2017 at 11:28:33AM -0700, Jason Gunthorpe wrote:
> On Wed, Mar 01, 2017 at 04:02:08PM +0200, Erez Shitrit wrote:
> > However, New features are exisiting in common network interfaces that
> > are very hard to implement in IPoIB interfaces while it uses the RDMA
> > layer, examples include TSS and RSS, tunneling offloads, and XDP.
> > Rather than continuously porting IP network interface developments into
> > the RDMA stack, we propose adding an abstract network data-path interfaces
> > to RDMA devices.
>
> I should also say that we have discussed this for a while and I am
> broadly in favor of this approach of delegating IPoIB skb transmit
> directly to the low level driver.

I agree.

>
> There are too many optimizations that do not fit sanely into verbs,
> and the entire overhead of building a verbs wr and posting it then
> translating that to a driver wr is unnecessary layering.

Yes, Niranjana has more details but the idea with the new rdma_netdev is that
the type defines what skbs the driver can expect and the low level driver does
the correct optimizations if the rdma_netdev is used.

I assume none of this applies to Connected Mode?

>
> Longer term, it might be quite nice if the part verbs specific part of
> ipoib was cleanly split out into the 'default' implementation of your
> get_ipoib_accel_ops.

This seems reasonable,
Ira

>
> Jason
> --
> 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