From mboxrd@z Thu Jan 1 00:00:00 1970 From: Or Gerlitz Subject: Re: When IBoE will be merged to upstream? Date: Wed, 07 Jul 2010 09:00:26 +0300 Message-ID: <4C3417FA.7000600@Voltaire.com> References: <20100624203701.GA4630@obsidianresearch.com> <20100625155755.GC4630@obsidianresearch.com> <4C32D0BD.3030902@Voltaire.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Liran Liss Cc: Roland Dreier , Jason Gunthorpe , "Hefty, Sean" , Aleksey Senin , linux-rdma , "monis-smomgflXvOZWk0Htik3J/w@public.gmane.org" , "alekseys-smomgflXvOZWk0Htik3J/w@public.gmane.org" , "yiftahs-smomgflXvOZWk0Htik3J/w@public.gmane.org" , Tziporet Koren , "alexr-smomgflXvOZWk0Htik3J/w@public.gmane.org" List-Id: linux-rdma@vger.kernel.org Liran Liss wrote: > but keeping ib_create_ah() callable from any context is not a goal by itself. going with your approach, if your proposed design is accepted, I believe that you probably need to patch all the code-chains that makes calls under the current assumption > I am looking for constructive ideas for supporting iboe without breaking > Verbs/CQE/CM syntax. I don't agree that exposing the Ethernet L2 related information to the caller is breaking something, the converse, it is a required enhancement. I think we need to let resolve through the rdma-cm && get to know at the consumer level, what are the source / destination macs, vlan id and vlan priority used by an IBoE QP, in the exact manner all the IB equivalents (src/dst lid, pkey, sl) are resolved by the rdma-cm and exposed to the consmer app for IB QP. 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