From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sagi Grimberg Subject: Re: [PATCH RFC v1 00/10] Introduce Signature feature Date: Thu, 31 Oct 2013 11:29:54 +0200 Message-ID: <52722312.3040907@mellanox.com> References: <1382970376-13776-1-git-send-email-sagig@mellanox.com> <5270DF90.8000802@mellanox.com> <1828884A29C6694DAF28B7E6B8A8237388CF28A5@ORSMSX109.amr.corp.intel.com> <52712BE4.3060103@mellanox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <52712BE4.3060103-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Or Gerlitz , "Hefty, Sean" , Roland Dreier Cc: "linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Oren Duer , tzahio-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org List-Id: linux-rdma@vger.kernel.org On 10/30/2013 5:55 PM, Or Gerlitz wrote: > On 30/10/2013 17:20, Hefty, Sean wrote: >>> The team here enhanced krping to fully cover (and test...) the proposed >>> >API and driver implementation, its (free) under >>> >git://beany.openfabrics.org/~sgrimberg/krping.git >>> > >>> >We'd like to see this landing in 3.13 such that the development of the >>> >upper layers can run for 3.14 and and later kernels. Sagi will postV2 >>> >with the two minor changes that came up in Sean's review of V1, >>> thoughts? >> If the upper layers won't be ready until 3.14, why can't these >> changes go in then? > > I explained, we want to see this landing in sooner rather than later > to avoid triple/quadruple way merge, e.g merge > of code from multiple kernel sub-components in one kernel cycle which > is complex. > >> My biggest issue is that the kernel verbs API is becoming more and >> more unwieldy, and I have heard requests that even the kernel >> interfaces need to be easier to use. The main work request structure >> used to send a message is around 84 bytes long. This patch bumps >> that up another 24 bytes or so. That's over 100 bytes of control >> data just to send a message! >> Hey Sean, You are raising a good point, I noticed that too. I can modify the sig_handover wr extension not to increase structure size. I'll use ib_sges instead of {mr, va, len}. data ib_sge will be passed in the existing wr->sg_list, and the protection ib_sge will be passed in sig_handover extension. I'll fix & send v2 today. >> Maybe we should rethink the approach of exposing low-level hardware >> constructs to every distinct feature of every vendor's latest >> hardware directly to the kernel ULPs. > > T10 DIF is industry standard, and it used in advanced commercial > production storage systems, the feature here is T10 DIF acceleration > for layers (e.g iser/srp/fcoe initiator/targets) that use RDMA. This > feature is supported by some FC cards too, so we want RDMA to be > competitive. We made great effort to expose API which is not tied to > specific HW/Firmware API. > > Or. > -- 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