Re: [PATCH V2 5/5] RDMA CM: Netlink Client

[Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]

On Tue, Dec 07, 2010 at 05:40:27PM +0200, Nir Muchtar wrote:

> I understand. still, I prefer staying focused on the primary goal and
> complete the patches before looking into this, So the solution for now
> is to just skip on device name and obtain them from userspace using the
> net devices and /sys/class. I might return to this once the first
> patches are accepted.

This doesn't really work if the IB netdevice is part of a bond, and it
won't work at all once Sean is done adding AF_GID.

Churning the userspace ABI is a really bad idea, if something is hard
to do, then fine. But this isn't..

> What I mean is that I will supply the maximum flexibility by supporting
> arbitrary netlink messages and attributes. This will support your
> suggested schema as well as any changes we'll agree upon. My current
> plans are for RDMA CM exports and not QP table exports but this should
> be next in line.

Do you have an idea what this will look like?

> > You shouldn't be attempting to dump the structure in one go while
> > holding a lock, you need to try best-efforts to dump it by keeping
> > some kind of current position value.
> > 
> > inet_diag seems to use a pretty simple scheme where it just records
> > the hash bucket and count into the chain. Not sure what happens if
> > things are erased - looks like you'll get duplicates/misses? You could
> > do the same by keeping track of the offset into the linked list.
> 
> The thing is, there's no easy and clean way to retrieve the export when
> using dump_start.

I don't follow this comment, can you elaborate?

This really needs to use the dump api, and I can't see any reason why
it can't.

Jason
--
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