On Sat, 2016-08-20 at 18:56 -0700, Alexander Duyck wrote: > > On Sat, Aug 20, 2016 at 5:21 PM, Ben Hutchings <b...@decadent.org.uk> wrote: > > > > On Fri, 2016-08-19 at 14:32 -0700, Alexander Duyck wrote: > > > > > > The i40e hardware has support for SCTP filtering via Rx NFC however the > > > default configuration expects us to include the verification tag as a part > > > of the filter. In order to support that I need to be able to transfer > > > that > > > data through the ethtool interface via a new structure. > > > > > > This patch adds a new structure to allow us to pass the verification tag > > > for IPv4 or IPv6 SCTP traffic. > > [...] > > > > This looks like an incompatible ABI change. I suppose it could be OK > > if no drivers implemented flow steering for SCTP using the previously > > specified structure, but have you checked that that is the case? > > > > Ben. > > Well the structure itself matches the TCP flow spec for the TCP flow > sized portion. All I am doing with this patch is adding an extension > to that which is still confined to the 52 byte limit of the flow > > union.
But that extension will be ignored by any drivers that implemented the API as previously defined. (If there aren't any, as I said, this doesn't really matter.) With previous extensions (everything in struct ethtool_flow_ext) we've introduced new type flags to ensure that they won't be silently ignored. You could add a new extended-SCTP type value for the same reason. [...] > One thing I could do if you would like would be to spin up another > patch to force the kernel to return -EINVAL if we are masking in > fields that are out of bounds for the flow specification. That way we > can handle this a bit more concisely in the future should we end up > > having to extend any other flow specifications. It's too late to do that now. Ben. -- Ben Hutchings Quantity is no substitute for quality, but it's the only one we've got.
signature.asc
Description: This is a digitally signed message part
