Re: [PATCH for-next V1 0/8] uverbs extensions fixes

[Yann Droneaud <ydroneaud-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org>]

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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html