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 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..
> 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.
Jason
--
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
