From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Steve Wise" Subject: RE: [PATCH V1 for-next 1/2] IB/core: Report LSO capabilities when querying device Date: Tue, 10 May 2016 10:03:48 -0500 Message-ID: <0c0801d1aacd$280e52e0$782af8a0$@opengridcomputing.com> References: <20160502190619.GB32613@obsidianresearch.com> <1828884A29C6694DAF28B7E6B8A82373AB048E47@ORSMSX109.amr.corp.intel.com> <20160504181135.GA15355@obsidianresearch.com> <21d9307f-766e-9aaa-54d3-207a4a4d5d8c@mellanox.com> <20160505181423.GB5957@obsidianresearch.com> <20160506225523.GA21309@obsidianresearch.com> <20160509163537.GA15479@obsidianresearch.com> <1828884A29C6694DAF28B7E6B8A82373AB04A390@ORSMSX109.amr.corp.intel.com> <20160509200507.GA23911@obsidianresearch.com> <1828884A29C6694DAF28B7E6B8A82373AB04A40A@ORSMSX109.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1828884A29C6694DAF28B7E6B8A82373AB04A40A-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org> Content-Language: en-us Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: "'Hefty, Sean'" , 'Jason Gunthorpe' Cc: 'Christoph Lameter' , 'Matan Barak' , 'Doug Ledford' , linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, 'Majd Dibbiny' , 'Bodong Wang' List-Id: linux-rdma@vger.kernel.org > > > We need to decide as a community what we want to do here, because this > > uncertain process is getting tiring for everyone. > > Agree greatly > > > The Collab Summit discussions ended with a general consensus that some > > things would go to the driver-specific channel, while hardware > > behavior related to the common uAPI would go through at least a > > multi-vendor sign off process - like IBTA. > > I agree with this approach. > > > We didn't talk about how to expose them to apps in userspace once they > > were exposed through the kernel. > > I think this will end up being vendor specific, and I'm not sure each vendor knows > what they want to do. > > > It is pretty obvious the current 'process' isn't working. This new > > idea that the common uAPI should just be a union of every vendor's > > unique hardware ideas has not resulted in patches being merged any > > faster; and I think the quality of the API is not as good now.. > > IMO, crafting a common API means a higher level of abstraction. The lower the > API, the more it needs to be driver specific. I prefer a method that: allows vendors > to stay out of each other's way, and quickly allows vendors to export their features > to user space. Either of these options can work for that. I don't see that a low- > level, common API is suitable. Hey all, I've been trying to follow this thread, and there has been comments that other device owners should speak up. But I'm not sure what LSO would do for an iWARP RC QP connection. Can someone give me a quick summary? Because as it stands now, a ~4GB send can be posted in 1 work request, and FW/HW (in the iWARP DDP layer) deals with segmenting it based on the MTU for the interface, and then assembling it to deliver as a single RECV completion at the peer. What would LSO do beyond this? Sorry for the dumb question. Steve -- 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