Re: [ewg] [PATCHv8 04/11] ib_core: IBoE CMA device binding
On Wed, May 12, 2010 at 01:03:42PM -0700, Roland Dreier wrote: int ib_init_ah_from_path(struct ib_device *device, u8 port_num, - struct ib_sa_path_rec *rec, struct ib_ah_attr *ah_attr) + struct ib_sa_path_rec *rec, struct ib_ah_attr *ah_attr, + int force_grh) Rather than this change in API, could we just have this function look at the link layer, and if it's ethernet, then always set the GRH flag? Seems simpler than requiring the upper layers to do this and then pass the result in? I guess that would keep the function more versatile but changing the implenetation to check the port's link layer seems OK to me. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCHv8 04/11] ib_core: IBoE CMA device binding
On Wed, May 12, 2010 at 01:05:06PM -0700, Roland Dreier wrote:
+static void iboe_mcast_work_handler(struct work_struct *work)
+{
+ struct iboe_mcast_work *mw = container_of(work, struct iboe_mcast_work,
work);
+ struct cma_multicast *mc = mw-mc;
+ struct ib_sa_multicast *m = mc-multicast.ib;
+
+ mc-multicast.ib-context = mc;
+ cma_ib_mc_handler(0, m);
+ kref_put(mc-mcref, release_mc);
+ kfree(mw);
+}
I'm having a hard time working out why the iboe case needs to schedule
to a work queue here since its already in process context, right? It
seems it would be really preferable to avoid all the extra pointer
munging and reference counting, and just call things directly.
I assume that the caller might attempt to acquire the same lock when
calling join and in the callback. Specifically, ucma_join_multicast()
calls rdma_join_multicast() with file-mut acquired and
ucma_event_handler() does the same.
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCHv8 05/11] ib_core: IBoE UD packet packing support
On Wed, May 12, 2010 at 01:06:36PM -0700, Roland Dreier wrote: 2. Fix wrong implementation of ib_ud_header_init(). A different patch was sent to Roland. This patch no longer applies, I guess because you already sent me this fix (which is now upstream since 2.6.34-rc1). Right, it's already applied. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] mlx4_en: ping does not resume after failover
Or Gerlitz wrote: Vladimir Sokolovsky wrote: It was fixed in the OFED-1.5.1-rc4, by the following commit: Author: Yevgeny Petrilin yevge...@mellanox.co.il Date: Wed Mar 10 18:46:55 2010 +0200 mlx4_en: reconfigure mac address Hi Yevgeny, I don't see this commit in Linus tree, does this means that the upstream mlx4_en bits would not work well or even not at all under bonding? can this fix be pushed? Hi Yevgeny, I don't see this in Linus tree and as such believe this still isn't pushed upstream, correct? Assuming this is the case, I'd hate to think that I can't use mlx4_en / bonding e.g for KVM based environments which are all based on recent kernels, can you push that for 2.6.35, please? Or ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] mlx4_en: ping does not resume after failover
Yevgeny Petrilin wrote: Sure, I am preparing the patches cool. Is there anything else in that or close importance level mlx4_en wise which is in ofed and from some reason wasn't push upstream? e.g I see a patch subject (0119) saying Fix a crash with prioritiesed vlan packets this sounds bad... am I expected to hit this or other problems fixed by patches from the below list if upstream is used? Or. mlx4_en_0010_remove_redundant_variable.patch mlx4_en_0020_fix_partial_rings.patch mlx4_en_0030_rx_flow_changes.patch mlx4_en_0040_interface_name_in_messages.patch mlx4_en_0050_renaming_en_params_to_en_ethtool.patch mlx4_en_0060_multiqueue_support.patch mlx4_en_0080_driver_version.patch mlx4_en_0090_linear_rx_dropped_counter.patch mlx4_en_0100_dropped_tx_packets.patch mlx4_en_0101_tx_optimizations.patch mlx4_en_0102_remove_ring_refill.patch mlx4_en_0104_not_using_srqs.patch mlx4_en_0105_dma_mapping_fixes.patch mlx4_en_0106_setting_dev_for_inline_rx.patch mlx4_en_0107_add_vlan_features.patch mlx4_en_0108_set_actual_ring_size.patch mlx4_en_0109_set_correct_size_mask.patch mlx4_en_0110_selftest.patch mlx4_en_0111_perm_addr_field.patch mlx4_en_0112_CLOSE_PORT_at_end_of_teardown.patch mlx4_en_0113_Setting-the-correct-value-to-MAX_TX_RINGS.patch mlx4_en_0114_latency_mod_for_small_packets.patch mlx4_en_0115_less_resources.patch mlx4_en_0116_link_state_report.patch mlx4_en_0117_port_up_in_transmit.patch mlx4_en_0119_tagged_packets_crash_fix.patch mlx4_en_0120_device_ids_table.patch mlx4_en_0130_Allow-interfaces-to-correspond-to-each-other.patch mlx4_en_0140_extend-cap-flags-to-64-bit.patch mlx4_en_0150_offloads_for_vlan_interfaces.patch mlx4_en_0160_UDP_rss.patch mlx4_en_0170__ip_summed_NONE_fix.patch mlx4_en_0180_reporting_transceiver_type.patch mlx4_en_0190_get_set_ringsize_use_actual_size.patch mlx4_en_0200_mlx4_en_destroy_allocator_only_when_using_frags.patch mlx4_en_0210_multicast_promisc_cap.patch mlx4_en_0220_reconfigure_mac_address.patch ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] ofa_1_5_kernel 20100513-0200 daily build status
This email was generated automatically, please do not reply git_url: git://git.openfabrics.org/ofed_1_5/linux-2.6.git git_branch: ofed_kernel_1_5 Common build parameters: Passed: Passed on i686 with linux-2.6.18 Passed on i686 with linux-2.6.19 Passed on i686 with linux-2.6.21.1 Passed on i686 with linux-2.6.26 Passed on i686 with linux-2.6.24 Passed on i686 with linux-2.6.22 Passed on i686 with linux-2.6.27 Passed on x86_64 with linux-2.6.16.60-0.54.5-smp Passed on x86_64 with linux-2.6.16.60-0.21-smp Passed on x86_64 with linux-2.6.18 Passed on x86_64 with linux-2.6.18-128.el5 Passed on x86_64 with linux-2.6.18-186.el5 Passed on x86_64 with linux-2.6.18-164.el5 Passed on x86_64 with linux-2.6.18-93.el5 Passed on x86_64 with linux-2.6.19 Passed on x86_64 with linux-2.6.21.1 Passed on x86_64 with linux-2.6.20 Passed on x86_64 with linux-2.6.24 Passed on x86_64 with linux-2.6.22 Passed on x86_64 with linux-2.6.25 Passed on x86_64 with linux-2.6.26 Passed on x86_64 with linux-2.6.27 Passed on x86_64 with linux-2.6.27.19-5-smp Passed on x86_64 with linux-2.6.9-67.ELsmp Passed on x86_64 with linux-2.6.9-89.ELsmp Passed on x86_64 with linux-2.6.9-78.ELsmp Passed on ia64 with linux-2.6.18 Passed on ia64 with linux-2.6.19 Passed on ia64 with linux-2.6.21.1 Passed on ia64 with linux-2.6.22 Passed on ia64 with linux-2.6.23 Passed on ia64 with linux-2.6.24 Passed on ia64 with linux-2.6.25 Passed on ia64 with linux-2.6.26 Passed on ppc64 with linux-2.6.19 Passed on ppc64 with linux-2.6.18 Failed: ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCHv8 08/11] mlx4: Allow interfaces to correspond to each other
On Wed, May 12, 2010 at 01:30:22PM -0700, Roland Dreier wrote:
+void *mlx4_get_prot_dev(struct mlx4_dev *dev, enum mlx4_prot proto, int
port)
+{
+ return mlx4_find_get_prot_dev(dev, proto, port);
+}
+EXPORT_SYMBOL(mlx4_get_prot_dev);
Not sure I understand why you have a wrapper to call another function
with exactly the same parameters? Can't we get rid of this and just
rename mlx4_find_get_prot_dev() to mlx4_get_prot_dev()?
Sure, let's change that.
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [Bug 1965] mlx4_en: ping does not resume after failover
I installed today OFED-1.5.2-beta1 on the host with ConnectX dual port card and found the fail-over doesn't work. On Sun, 2010-03-28 at 10:58 +0300, Vladimir Sokolovsky wrote: Or Gerlitz wrote: Hi Vlad, Yevgeny Is there a way to get this fix? AFAIK, this bugzilla system isn't there for monitoring the Mellanox ofed flavor, isn't it? Or. bugzilla-dae...@lists.openfabrics.org wrote: https://bugs.openfabrics.org/show_bug.cgi?id=1965 vent...@mellanox.co.il changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #13 from vent...@mellanox.co.il 2010-03-24 08:49 --- Fix had been verified in MLNX_OFED-1.5.1 RC5. Closing Or, It was fixed in the OFED-1.5.1-rc4, by the following commit: Author: Yevgeny Petrilin yevge...@mellanox.co.il Date: Wed Mar 10 18:46:55 2010 +0200 mlx4_en: reconfigure mac address When the other port removes a mac address that is the same that the current port has, the table should be reconfigured. fixes bugzilla #1965 Signed-off-by: Yevgeny Petrilin yevge...@mellanox.co.il Regards, Vladimir ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [Bug 1965] mlx4_en: ping does not resume after failover
On Thu, 2010-05-13 at 15:34 +0300, Yevgeny Petrilin wrote: Can you please give more details? What is the setup? What do you mean by doesn't work? Yevgeny Petrilin Mellanox Technologies Phone: +972-4-9097200 (ext. 7677) mailto: yevge...@mellanox.co.il -Original Message- From: Aleksey Senin [mailto:aleks...@voltaire.com] Sent: Thursday, May 13, 2010 3:30 PM To: Vladimir Sokolovsky Cc: Or Gerlitz; ewg@lists.openfabrics.org; Yevgeny Petrilin Subject: Re: [ewg] [Bug 1965] mlx4_en: ping does not resume after failover I installed today OFED-1.5.2-beta1 on the host with ConnectX dual port card and found the fail-over doesn't work. On Sun, 2010-03-28 at 10:58 +0300, Vladimir Sokolovsky wrote: Or Gerlitz wrote: Hi Vlad, Yevgeny Is there a way to get this fix? AFAIK, this bugzilla system isn't there for monitoring the Mellanox ofed flavor, isn't it? Or. bugzilla-dae...@lists.openfabrics.org wrote: https://bugs.openfabrics.org/show_bug.cgi?id=1965 vent...@mellanox.co.il changed: What|Removed |Added -- -- Status|RESOLVED|CLOSED --- Comment #13 from vent...@mellanox.co.il 2010-03-24 08:49 --- Fix had been verified in MLNX_OFED-1.5.1 RC5. Closing Or, It was fixed in the OFED-1.5.1-rc4, by the following commit: Author: Yevgeny Petrilin yevge...@mellanox.co.il Date: Wed Mar 10 18:46:55 2010 +0200 mlx4_en: reconfigure mac address When the other port removes a mac address that is the same that the current port has, the table should be reconfigured. fixes bugzilla #1965 Signed-off-by: Yevgeny Petrilin yevge...@mellanox.co.il Regards, Vladimir ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg I reopened bug in bugzilla and added more details. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCHv8 04/11] ib_core: IBoE CMA device binding
On Wed, May 12, 2010 at 01:14:33PM -0700, Roland Dreier wrote: Multicast GIDs are always mapped to multicast MACs as is done in IPv6. Some helper functions are added to ib_addr.h. IPv4 multicast is enabled by translating IPv4 multicast addresses to IPv6 multicast as described in http://www.mail-archive.com/i...@sunroof.eng.sun.com/msg02134.html. I guess it's a bit unfortunate that the RoCE annex completely ignored how to map multicast GIDs to ethernet addresses (I suppose as part of the larger decision to ignore address resolution entirely). Anyway, looking at the email message you reference, it seems to be someone asking what the right way to map IPv4 multicast addresses to IPv6 addresses is. Is there a more definitive document you can point to? I am not aware of any definitive document that addresses this issue. It seems that unfortunately the way the layering of addresses is done, there's no way to just use the standard mapping of IPv4 multicast addresses to Ethernet addresses (since IBoE is does addressing via the CMA mapping to GIDs followed by an unspecified mapping from GIDs to Ethernet addresses). It is natural to treat gids as IPv6 addresses, so using the standard mapping from IPv6 multicast addresses to mac addresses seems reasonable. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCHv8 07/11] ib_core: Add API to support IBoE from userspace
On Wed, May 12, 2010 at 01:28:31PM -0700, Roland Dreier wrote:
Add ib_uverbs_get_eth_l2_addr() to allow ibv_create_ah() to resolve sgid,
dgid to vlan, dmac for any gid type. Although user-space might bypass
this
call for link-local gids, it is better not to replicate the kernel
resolution
policy. Port link layer is also returned by ibv_query_port().
A high-level comment/question, followed by some notes about the specific
patch.
At the highest level, is having this very low-level command exposed as
part of the kernel uverbs - userspace API the right place to split
things? Making the Ethernet address resolution part of the low-level
driver implies that it's not really a generic part of the verbs interface.
Correct - Ethernet address resolution really isn't part of the verbs
interface accoring to the RoCE specification; it should happen below
the verbs.
Maybe it is generic, and we should have a generic function instead of
calling into the low-level driver. I see the argument that we should
keep the policy in the kernel, although I'm not sure how strong that
argument is -- once we start shipping a kernel with a certain policy
(and I guess OFED has in effect already done that), how could we ever
change that policy? We'll have interoperability issues anyway, so it
seems having userspace and kernel use different policies doesn't cause
much further problems anyway.
Address mapping policies depend on the address type. This patch only
defines a policy for mapping link-local addresses, and we should
indeed take care not to change it (if possible).
Later on, we can add more policies for other address types (e.g.,
normal IPv6 addresses, mapped IPv4 addresses, etc.)
Or maybe it is device-specific, and we could wrap it up into the create
AH uverbs call we already have?
Interesting idea. Not sure what is better here: a seperate ABI
call or some additional 'u8 ctx[32]' field in struct
ib_uverbs_create_ah_resp that will be interpreted by the hw-specific
user-space driver.
Low-level comments:
+ssize_t ib_uverbs_get_eth_l2_addr(struct ib_uverbs_file *file, const char
__user *buf,
+int in_len, int out_len)
+{
+ struct ib_uverbs_get_eth_l2_addr cmd;
+ struct ib_uverbs_get_eth_l2_addr_resp resp;
+ int ret;
+ struct ib_pd*pd;
+
+ if (out_len sizeof resp)
+ return -ENOSPC;
+
+ if (copy_from_user(cmd, buf, sizeof cmd))
+ return -EFAULT;
+
+ pd = idr_read_pd(cmd.pd_handle, file-ucontext);
+ if (!pd)
+ return -EINVAL;
+
+ ret = ib_get_eth_l2_addr(pd-device, cmd.port, (union ib_gid *)cmd.gid,
+ cmd.sgid_idx, resp.mac, resp.vlan_id,
resp.tagged);
+ put_pd_read(pd);
+ if (!ret) {
+ if (copy_to_user((void __user *) (unsigned long) cmd.response,
+ resp, sizeof resp))
+ return -EFAULT;
This leaks kernel memory contents to userspace since the stack variable
resp is never cleared. Also will cause problems if we ever need to use
the reserved fields for anything.
I see, I missed that subtle detail.
Also I'm not sure I understand why you pass the PD into this method? It
seems you just use it to get a pointer to the device, but you already
have that from the uverbs_file structure that's passed into all commands.
True, missed that too.
+int ib_get_eth_l2_addr(struct ib_device *device, u8 port, union ib_gid
*gid,
+ int sgid_idx, u8 *mac, __u16 *vlan_id, u8 *tagged)
+{
+ if (!device-get_eth_l2_addr)
+ return -ENOSYS;
+
+ return device-get_eth_l2_addr(device, port, gid, sgid_idx, mac,
vlan_id, tagged);
+}
+EXPORT_SYMBOL(ib_get_eth_l2_addr);
I don't think we need this wrapper, since uverbs can just call the
get_eth_l2_addr method directly (we already do that for quite a few
other methods, eg alloc_ucontext is a uverbs-only method that has no
in-kernel wrapper). Also the -ENOSYS test isn't necessary, since a
device-driver shouldn't allow this method unless it actually implements
it.
I agree.
By the way, do you prefer that I re-create the patch with the fixes or
would you make the necessary changes.
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Has anyone tried the ISC DHCP patches for Infiniband with ISC DHCP 4.1.x?
On 05/12/2010 01:25 AM, sebastien dugue wrote: Hi Justin, I've been trying to do just that for the past few days. Right now I managed to have the client working over IB, but it's a gross hack which will need to be cleaned up. Tomorrow I'll check with the server part and will keep you and the list posted. Hey Sebastien, How's this going? :) Regards and best wishes, Justin Clift Sebastien. -- Salasaga - Open Source eLearning IDE http://www.salasaga.org ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] mlx4_en: ping does not resume after failover
Also keep in mind that mlx4_en patches typically go through Davem and netdev, not my tree. -- Roland Dreier rola...@cisco.com || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCHv8 02/11] ib_core: IBoE support only QP1
Also I'm wondering why you did the count stuff to ignore IBoE-only devices in multicast.c but not sa_query.c? It seems to me the right place to put this logic as the mutlicast code registers as an IB client and the add_one implemntation is multicast.c. Right, I'm not saying it shouldn't be in multicast.c. I'm just wondering why you don't have the same thing for sa_query.c. - R. -- Roland Dreier rola...@cisco.com || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCHv8 07/11] ib_core: Add API to support IBoE from userspace
Address mapping policies depend on the address type. This patch only defines a policy for mapping link-local addresses, and we should indeed take care not to change it (if possible). Later on, we can add more policies for other address types (e.g., normal IPv6 addresses, mapped IPv4 addresses, etc.) Or maybe it is device-specific, and we could wrap it up into the create AH uverbs call we already have? Interesting idea. Not sure what is better here: a seperate ABI call or some additional 'u8 ctx[32]' field in struct ib_uverbs_create_ah_resp that will be interpreted by the hw-specific user-space driver. I don't understand why mapping remote addresses should be driver specific. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCHv8 02/11] ib_core: IBoE support only QP1
On Thu, May 13, 2010 at 08:48:06AM -0700, Roland Dreier wrote: Right, I'm not saying it shouldn't be in multicast.c. I'm just wondering why you don't have the same thing for sa_query.c. One reason is that get_src_path_mask() may access ah_lock. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCHv8 07/11] ib_core: Add API to support IBoE from userspace
On Thu, May 13, 2010 at 08:55:13AM -0700, Sean Hefty wrote: Interesting idea. Not sure what is better here: a seperate ABI call or some additional 'u8 ctx[32]' field in struct ib_uverbs_create_ah_resp that will be interpreted by the hw-specific user-space driver. I don't understand why mapping remote addresses should be driver specific. In this case it will not be just mapping remote addresses but creating the required AH information which is unique to each device. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCHv8 02/11] ib_core: IBoE support only QP1
One reason is that get_src_path_mask() may access ah_lock.
I don't see that:
static u8 get_src_path_mask(struct ib_device *device, u8 port_num)
{
struct ib_sa_device *sa_dev;
struct ib_sa_port *port;
unsigned long flags;
u8 src_path_mask;
sa_dev = ib_get_client_data(device, sa_client);
if (!sa_dev)
return 0x7f;
so if we never add the sa_client structure it just returns.
- R.
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCHv8 05/11] ib_core: IBoE UD packet packing support
Right, it's already applied. Doesn't seem to be all there... eg there is nothing for ethernet headers. -- Roland Dreier rola...@cisco.com || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCHv8 07/11] ib_core: Add API to support IBoE from userspace
In this case it will not be just mapping remote addresses but creating
the required AH information which is unique to each device.
I understand that the AH is per device. What I don't get is why we would want
each device to perform the mapping. We don't expect the device to map GIDs to
LIDs when creating an AH. The user must have done the mapping beforehand. The
mapping does not depend on which device I'm using, it should be the same.
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);
+
- Sean
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [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
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
