If we have a dedicated ABI call for this mapping, then it seems reasonable to have it device independent. However, this mapping is really only used when creating address handles.
So, we can base the mapping on the (device specific) create_ah() flow, but provide generic mapping functions for all devices to use (this is kind of what happens now). Also, using create_ah() doesn't introduce an ABI call that is specific to ib-->eth mappings. This is similar to how device-specific ib_reg_user_mr() functions call the generic ib_umem_get()... -----Original Message----- From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma-ow...@vger.kernel.org] On Behalf Of Roland Dreier Sent: Thursday, May 13, 2010 10:18 PM To: Sean Hefty Cc: 'Eli Cohen'; Eli Cohen; Linux RDMA list; ewg Subject: Re: [PATCHv8 07/11] ib_core: Add API to support IBoE from userspace > Basically, what I want to understand is why does this change make sense? > > @@ -1139,6 +1139,10 @@ struct ib_device { > struct ib_grh *in_grh, > struct ib_mad *in_mad, > struct ib_mad *out_mad); > + int (*get_eth_l2_addr)(struct ib_device *device, > u8 port, > + union ib_gid *dgid, int > sgid_idx, > + u8 *mac, u16 *vlan_id, u8 > *tagged); > + Yes, that was pretty much my original question. Why do we have a verb for userspace to call a device-specific method to do the mapping? The layering seems wrong somewhere if we have a generic verb to do this mapping, but then put the mapping in device-specific code. - R. -- Roland Dreier <rola...@cisco.com> || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
