Hi, Le mercredi 30 octobre 2013 à 11:52 +0200, Matan Barak a écrit : > This series is a continuous improvement for the uverbs extension mechanism > that was introduced as an experimental feature for v3.12. > > Yann Droneaud suggested and implemented the following improvements: > - structure renaming to match others uverbs public structs; > - changes usage of the flow_attr.size to not count the > "extended command header" but to describe only the size > of the flow specs following flow_attr; > - removed unneeded flow_spec structure that don't need to be > exposed to userspace. > - ensure 64bits alignment > > This series is actually Yann's series with a bug fix. > > Changes from Yann's series > (V0 http://marc.info/?l=linux-rdma&m=138151196022025): > 1. Re-enable flow steering verbs and the extension verbs mechanism. > 2. Squashed patches 1 and 2 from the original series > 3. ib_uverbs_write should return the number of bytes including the > header's size (Patch 7). >
Thanks Matan for carrying on the patchset. I've quite the same patchset, but the other way around, eg. enabling the flow steering verbs after cleanup on the new ABI. I thought it would make more sense this way. Would you like me to send the patchset this way, with my others patches to rename the function, which was dropped from my latest attempt in order to squeeze the patchset to bare minimal ? Regarding the extensible framework, I haven't found time to design a new proposal for the interface. I keep in my mind that something built around writev(2) (struct iovec) and/or cmsg(3) / netlink(3) would be preferable to ease sending multipart command to uverbs subsystem. BTW, I think we should drop the patch that adds the comp_mask in the header. As you wrote in a previous mail, a comp_mask could be present in the "provider" part of the command. This make handling of comp_mask from header very different, very specific, while it's not, since there could be more "comp_mask": one in command, one in provider, one in response and one in the provider response parts. So I would prefer not have the command comp_mask being treated differently than the other. Regards. -- Yann Droneaud OPTEYA -- 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
