From: Or Gerlitz <ogerlitz-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
To: Yann Droneaud <ydroneaud-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org>,
Matan Barak <matanb-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Cc: Roland Dreier <roland-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH for-next V1 0/8] uverbs extensions fixes
Date: Tue, 5 Nov 2013 15:23:15 +0200 [thread overview]
Message-ID: <5278F143.5070001@mellanox.com> (raw)
In-Reply-To: <1383642320.18301.46.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
On 05/11/2013 11:05, Yann Droneaud wrote:
> 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 ?
good! lets do that asap, please make sure to mark the series as V2 and
list the changes from V1 in the cover-letter
> 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.
Well, we do want the solution to use the uverbs framework and not
involve another paradigm for user/kernel verbs interaction. With this in
mind && as Matan and Tzahi wrote you earlier on the list, we do think
the current proposal is good enough to carry on with.
> 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.
makes sense.
Matan and Or.
--
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
next prev parent reply other threads:[~2013-11-05 13:23 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-30 9:52 [PATCH for-next V1 0/8] uverbs extensions fixes Matan Barak
[not found] ` <1383126771-7658-1-git-send-email-matanb-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2013-10-30 9:52 ` [PATCH for-next V1 1/8] IB/core: re-enable create_flow/destroy_flow uverbs Matan Barak
2013-10-30 9:52 ` [PATCH for-next V1 2/8] IB/core: clarify overflow/underflow checks on ib_create/destroy_flow Matan Barak
2013-10-30 9:52 ` [PATCH for-next V1 3/8] IB/core: Rename 'flow' structs to match other uverbs structs Matan Barak
2013-10-30 9:52 ` [PATCH for-next V1 4/8] IB/core: Makes uverbs flow structure using names more similar to verbs ones Matan Barak
2013-10-30 9:52 ` [PATCH for-next V1 5/8] IB/core: Uses a common header for uverbs flow_specs Matan Barak
2013-10-30 9:52 ` [PATCH for-next V1 6/8] IB/core: Remove ib_uverbs_flow_spec structure from userspace Matan Barak
2013-10-30 9:52 ` [PATCH for-next V1 7/8] IB/core: extended command: an improved infrastructure for uverbs commands Matan Barak
2013-10-30 9:52 ` [PATCH for-next V1 8/8] IB/core: extended command: move comp_mask to the extended header Matan Barak
[not found] ` <1383126771-7658-9-git-send-email-matanb-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2013-11-05 9:20 ` Yann Droneaud
2013-11-05 9:05 ` [PATCH for-next V1 0/8] uverbs extensions fixes Yann Droneaud
[not found] ` <1383642320.18301.46.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2013-11-05 13:23 ` Or Gerlitz [this message]
[not found] ` <5278F143.5070001-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2013-11-06 15:02 ` Or Gerlitz
[not found] ` <527A5A20.5050907-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2013-11-06 16:51 ` Yann Droneaud
[not found] ` <2f2cc2c0237e938586f475c2fae187cd-zgzEX58YAwA@public.gmane.org>
2013-11-06 20:41 ` Or Gerlitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5278F143.5070001@mellanox.com \
--to=ogerlitz-vpraknaxozvwk0htik3j/w@public.gmane.org \
--cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=matanb-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org \
--cc=roland-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=ydroneaud-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox