On Tue, Apr 10, 2018 at 09:06:03PM +0300, Mark Bloch wrote: > 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 suspect that also. > > 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. Yes, but the problem is to define a way to ask if the driver supports this 'common approach' or not. So, we need something. What is the least ugly solution? Flags, something like mask, or something else? Can't just ignore it. > > 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. We should not be so quick to reach for DV - in a case like this it seems to signal that the proposed API is not general enough. I like the mask idea, it is pretty simple and I think it would actually be easy enough for the user.... 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
