On Wed, Nov 1, 2017 at 11:16 PM, Jason Gunthorpe <jgg@xxxxxxxx> wrote:
> On Wed, Nov 1, 2017 at 1:46 PM, Alex Rosenbaum <rosenbaumalex@xxxxxxxxx> wrote:
>>> Then I think my proposed API makes the most sense overall since it
>>> captures this use model as well, even if mlx currently does not support
>>> this use model for flow counters.
>
>> it will force the kernel syscall on each modify, which is something
>> that will limit the usage at scale.
>
> No, it doesn't force that. As we've talked about the driver should
> book-keep in user space as required.
>
>> doing the bookkeeping in user space will require a trigger to commit
>> this to kernel/HW, which can be the modify() or an additional API.
>
> The trigger to push things to the kernel is something like creating a
> flow steering object.
I'm referring to reducing the kernel calls when supporting the on the
fly modification for counter and QP pair updates.
if user wants to add/remove a sampling point on an already operational
QP of flow, calling ibv_add_sampling_point_qp will have to go to
kernel each time, unless we allow multiple add_sampling_point followed
by a ibv_modify_qp(qp, {attr{counter}}) or add some 'flush' flag/API,
or 'more to come' flag until final add_sampling_poing_qp call.
> The driver can bundle the create of the counter object, and the send
> of the counters to add, in with the syscall for creating the flow
> steering object.
>
> Same argument for QP, similar argument for attaching to an existing
> QP.
totally agree about the atomic create of counter with verbs object.
this is well defined with the ibv_create_flow/qp()
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
