> -----Original Message----- > From: Jason Gunthorpe [mailto:jgg@xxxxxxxx] > Sent: Wednesday, April 11, 2018 1:29 AM > To: Mark Bloch <markb@xxxxxxxxxxxx> > Cc: Alex Rosenbaum <rosenbaumalex@xxxxxxxxx>; linux- > rdma@xxxxxxxxxxxxxxx; Yishai Hadas <yishaih@xxxxxxxxxxxx>; Leon > Romanovsky <leonro@xxxxxxxxxxxx>; Alex Rosenbaum > <alexr@xxxxxxxxxxxx> > Subject: Re: [PATCH RFC] New verbs API for flow action: ENCAP > > 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 can't think of more to add besides the: CSUM, UDP_SPORT_ENTORPY At this rate I don't think we'll ever reach 32 flags. > > > 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.... few concerns regarding the buffer mask idea: 1. HW might have more than one way to modify some fields, bit mask blocks this approach. Like UDP entropy based different tuple parts L3 vs L3+L4 2. HW might allow to modify fields in the 'inner' packet. the mask covers only the ENCAL header part [I'm not sure if this is a real use-case] 3. the mask forces the driver implementation to scan the ENCAP header and the matching mask buffer, compared to only checking for support flags for the common case 4. seems harder to explain, compared to flags On the pro side: this will not require future enum flags updates, just application to set more bits 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
