On Fri, 2016-01-22 at 10:54 -0800, Alexander Duyck wrote:
> On Fri, Jan 22, 2016 at 10:04 AM, Edward Cree <ec...@solarflare.com> wrote:
[...]
> > +/**
> > + * struct ethtool_usrip6_spec - general flow specification for IPv6
> > + * @ip6src: Source host
> > + * @ip6dst: Destination host
> > + * @l4_4_bytes: First 4 bytes of transport (layer 4) header
> > + * @tos: Type-of-service
> > + * @proto: Transport protocol number (nexthdr after any Extension Headers)
> > + */
> > +struct ethtool_usrip6_spec {
> > + __be32 ip6src[4];
> > + __be32 ip6dst[4];
> > + __be32 l4_4_bytes;
> > + __u8 tos;
> > + __u8 proto;
> > +};
> > +
>
> It might be better to refer to this as l4_proto so that it is clear
> that this is specifying the protocol of the l4 header that the
> l4_4_bytes will be pulled from.
The comment seems to make it fairly clear.
> It still might even be useful to add a nexthdr field since it is
> possible that there may be NICs out there that don't support parsing
> the extension headers. In such a case they could block setting
> protocol and use nexthdr instead. It provides an indirect way of
> communicating if the NIC supports parsing extension headers or not as
> the NIC can block adding a filter on one mask being set or the other.
I don't think a NIC can do any useful flow steering for IPv6 without
being able to parse and skip over the extension headers. It would be
like trying to match flows by looking at IPv4 header options.
Ben.
--
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy others.
signature.asc
Description: This is a digitally signed message part
