On Wed, May 12, 2010 at 12:56:58PM -0700, Roland Dreier wrote:
> > @@ -1017,9 +1020,12 @@ static void ib_sa_add_one(struct ib_device *device)
> >sa_dev->end_port = e;
> >
> >for (i = 0; i <= e - s; ++i) {
> > + spin_lock_init(&sa_dev->port[i].ah_lock);
> > + if (
>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'
> 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 wa
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 thi
Sean Hefty wrote:
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 addre
>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_fami
> +u8 mac_0_1[2];
> +u8 mac_2_5[4];
This looks a bit odd. Any reason why you don't just have "u8 mac[6];"
in this structure?
--
Roland Dreier || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--
To un
> +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?
> Add ib_uverbs_get_eth_l2_addr() to allow ibv_create_ah() to resolve dgid> to 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-l
> 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.
> 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).
--
Roland Dreier || For corporate legal information go to:
http://www.cisco.
> +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
> 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 A
Roland Dreier 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
> @@ -1017,9 +1020,12 @@ static void ib_sa_add_one(struct ib_device *device)
> sa_dev->end_port = e;
>
> for (i = 0; i <= e - s; ++i) {
> +spin_lock_init(&sa_dev->port[i].ah_lock);
> +if (rdma_port_link_layer(device, i + 1) !=
> IB_LINK_LAYER_INFINIBAND
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 thi
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 interfa
> * 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 /pr
> 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 Carpe
19 matches
Mail list logo
