On 10/04/2018 17:44, Jason Gunthorpe wrote:
> On Tue, Apr 10, 2018 at 05:31:06PM +0300, Alex Rosenbaum wrote:
>>> Well.. that is a big issue and needs careful explanation.
>>>
>>> How is the user space to know if the driver supports the 'special'
>>> transformations ?
>>>
>>> Seems like a pretty big gap.
>>>
>>
>> yes, HW capabilities is missing.
>> I suggest we replace the 'enum type' with 'int flags'.
>> enum ibv_flow_action_encap_flags {
>> IBV_ENCAP_FLAGS_CSUM = 1 << 0, /* HW offload to calc outer and
>> inner CSUM for IP and TCP headers */
>> IBV_ENCAP_FLAGS_VXLAN_SPORT_ENTROPY = 1 << 1, /* HW offload calc
>> of UDP src port entropy value based on inner packet headers */
>> };
>
> I wonder if this is general enough
I think once we go down this road, we will end up with more flags than
there are stars in the sky, and the ability to mix and match flags
will be a nightmare to understand/handle.
>
> I would suggest something more like a header set and then a mask, like
> we use for the flow matching. Except instead of matching the mask
> indicates what bytes the HW is expected to fill in.
>
> The driver scans the header and mask and figures out if it knows how
> to fill in the mask'd values, or it fails to create it.
>
> Not sure if a mask or an offset table & type is a better choice though..
>
I think it makes the implementation/user experience kind of ugly, for example
when talking about vxlan encap in the kernel, it's pretty clear what
should happen (checksum, length adjustment etc), and using udp sport as a way to
provide entropy is standard stuff there. The common use case is well defined
if we assume it's derived from how the networking stack does things and the API
should be simple enough to be used.
Now if a vendor wants to provide extra customization, that's what DV is for.
>> The providers might want to walk the users header to check what user
>> is trying to do and match these with the flags provided.
>
> I think this is essential, but the trick is that some times you may
> want the HW to fill and sometimes not. Entropy is a good example of
> this. Maybe an app wants fixed entropy for an entire flow
Not flow, but encap ID, as it can be attached to multiple flows, and
if a provider support this stuff, it should expose a DV for that.
I agree we might want to have specific types that are well defined
which have the same outcome across vendors, but that should be defined
on per type basis and not pilling flags one on top of each other.
>
> Jason
>
Mark
--
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
