Re: [PATCH 3/3] ib/iser: enhance disconnection logic for multi-pathing
Hi Roland, as we're @ -rc7 now, I wanted to check with you if there's any issue merging this patch series for 2.6.35. If you have any question or anything need to be addressed/fixed, I'd like to do that sooner rather then later. No, just needed to get to it. I have these 3 + Dan Carpenter's fix applied now. -- 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
Re: [RFC] libibverbs: ibv_fork_init() and libhugetlbfs
* added get_huge_page_size() to read the huge page size from /proc/meminfo. This is done at ibv_fork_init() time. That doesn't work on systems that have multiple huge page sizes (eg powerpc). You can compare the code to get the size in libhugetlbfs. Also I think the munging through /proc/pid/maps doesn't really work. First of all, essentially grepping for libhugetlbfs is not robust as I mentioned -- this will break in the same way for apps using huge pages directly. And while it is nice to be able to tell if a range came from libhugetlbfs, I think there may be some bad performance impact from reading /proc/pid/maps line-by-line. (And by the way, as a trivial optimization, it would make sense to me to check the address of each map before doing the strstr). - 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
Re: [PATCH v3 18/52] IB/qib: Add qib_iba7322.c (serdes parameters)
On Tue, 11 May 2010, Roland Dreier wrote: | Sorry for exposing all the ugliness. If you see it as a serious issue, | we can try to accelerate the cleanup effort. | | OK. Yes, I do see this as a serious issue -- getting rid of the bogus | interface which is exposed as a user-visible interface is very painful | once we've merged it. So I would really really prefer to just have the | good interface upstream. | | We're probably ~1 week away from 2.6.34 final, and the merge window will | be two weeks after that. So if you could get some form of this finished | in the next 3 weeks, that would be the best way to merge qib. OK. I'll be working on the redone version, and at this point, expect to have it ready by this Friday, so either Ralph or I will send it at that time. Dave Olson dave.ol...@qlogic.com -- 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
Re: [PATCH] RDMA/ucma: Copy iWARP route information.
Sean Hefty wrote: I'll have to ponder this. In the past, we've been using the gid.raw areas to hold these mac addresses... There's not too many options with the existing ABI, but the newer query interfaces will give us more flexibility, like variable length addresses, which may make this cleaner. Maybe we can return the L2 address through an AF_UNSPEC sockaddr? What does AF_UNSPEC imply about the format of the sockaddr? -- 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
Re: [PATCH 3/3] ib/iser: enhance disconnection logic for multi-pathing
Roland Dreier rdre...@cisco.com wrote: I have these 3 + Dan Carpenter's fix applied now. cool Or. -- 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
Re: [PATCHv8 04/11] ib_core: IBoE CMA device binding
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? -- 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
Re: [PATCHv8 04/11] ib_core: IBoE CMA device binding
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? 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). - 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
Re: [PATCHv8 08/11] mlx4: Allow interfaces to correspond to each other
+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()?
--
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
RE: [PATCH] RDMA/ucma: Copy iWARP route information.
What does AF_UNSPEC imply about the format of the sockaddr? That it depends on the usage..? I came up with this based on using ioctl to manipulate the ARP cache: SIOCSARP - Add a new entry to the ARP cache or modify an existing entry ... arp_ha is a generic socket address structure with sa_family set to AF_UNSPEC and sa_data containing the hardware address (e.g. the 6-byte Ethernet address). The librdmacm should have enough context to interpret the meaning of the query_gid response. - Sean -- 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
RE: [PATCH v2] libibverbs: add path record definitions to sa.h
Roland, I'd like to release a new version of librdmacm that can support the user space SA query feature in 2.6.33, which will also be part of OFED 1.5.2. Currently, there's a dependency on the path record definition being part of libibverbs. Do you have any opinions on the best way to handle this? I guess, ideally, I'd like to see a released version of libibverbs include this, but I can think of ways around this. - Sean -- 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
Re: [PATCH v2] libibverbs: add path record definitions to sa.h
I'd like to release a new version of librdmacm that can support the user space SA query feature in 2.6.33, which will also be part of OFED 1.5.2. Currently, there's a dependency on the path record definition being part of libibverbs. Do you have any opinions on the best way to handle this? I guess, ideally, I'd like to see a released version of libibverbs include this, but I can think of ways around this. I can release an updated version of libibverbs (I have enough stuff pending that this is probably a good idea anyway). However could you do some autoconf stuff so librdmacm works against older libibverbs (but doesn't enable the stuff that can't be done without the missing stuff)? Or maybe it's not worth it. -- 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
RE: [PATCH v2] libibverbs: add path record definitions to sa.h
I can release an updated version of libibverbs (I have enough stuff pending that this is probably a good idea anyway). However could you do some autoconf stuff so librdmacm works against older libibverbs (but doesn't enable the stuff that can't be done without the missing stuff)? Or maybe it's not worth it. I'll see if I can figure out how to update the autoconf stuff correctly. Thanks. -- 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
