On Wed, 2010-12-01 at 11:35 -0700, Jason Gunthorpe wrote: > > I agree, but this is a bit out of scope for the current patches and I > > think this kind of change should be given some thought. > > I'd view it as a pre-condition, actually. >
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. > I'm happy to see things done later, if we can agree on what everything > should look like later so the pieces we have now fit. Maybe you can > outline the sort of schema you are thinking of as I did? > > Having a framework where ib_core generates the QP message and calls > out to RDMA_CM, IB_CM, driver, uverbs, etc to fill in attributes seems > best to me for the QP table. 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. > 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. > > Jason The thing is, there's no easy and clean way to retrieve the export when using dump_start. The locking problem could be solved using GFP_ATOMIC when using malloc. This will prevent possible long locking periods. Nir -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
