On Fri, 2 Mar 2018 15:24:29 +0000, Edward Cree wrote:
> On Tue, Feb 27, 2018 at 3:47 PM, Jakub Kicinski <kubak...@wp.pl> wrote:
>
> > Please, let's stop extending ethtool_rx_flow APIs. I bit my tongue
> > when Intel was adding their "redirection to VF" based on ethtool ntuples
> > and look now they're adding the same functionality with flower :| And
> > wonder how to handle two interfaces doing the same thing.
> Since sfc only supports ethtool NFC interfaces (we have no flower support,
> and I also wonder how one is to support both of those interfaces without
> producing an ugly mess), I'd much rather put this in ethtool than have to
> implement all of flower just so we can have this extension.
"Just this one extension" is exactly the attitude that can lead to
messy APIs :(
> I guess part of the question is, which other drivers besides us would want
> to implement something like this, and what are their requirements?
I think every vendor is trying to come up with ways to make their HW
work with containers better these days.
> > On the use case itself, I wonder how much sense that makes. Can your
> > hardware not tag the packet as well so you could then mux it to
> > something like macvlan offload?
> In practice the only way our hardware can "tag the packet" is by the
> selection of RX queue. So you could for instance give a container its
> own RX queues (rather than just using the existing RX queues on the
> appropriate CPUs), and maybe in future hook those queues up to l2fwd
> offload somehow.
> But that seems like a separate job (offloading the macvlan switching) to
> what this series is about (making the RX processing happen on the right
> CPUs). Is software macvlan switching really noticeably slow, anyway?
OK, thanks for clarifying.
> Besides, more powerful filtering than just MAC addr might be needed, if,
> for instance, the container network is encapsulated. In that case
> something like a UDP 4-tuple filter might be necessary (or, indeed, a
> filter looking at the VNID (VxLAN TNI) - which our hardware can do but
> ethtool doesn't currently have a way to specify). AFAICT l2-fwd-offload
> can only be used for straight MAC addr, not for overlay networks like
> VxLAN or FOU? At least, existing ndo_dfwd_add_station() implementations
> don't seem to check that dev is a macvlan... Does it even support
> VLAN filters? fm10k implementation doesn't seem to.
Exactly! One can come up with many protocol combinations which flower
already has APIs for... ethtool is not the place for it.
> Anyway, like I say, filtering traffic onto its own queues seems to be
> orthogonal, or at least separate, to binding those queues into an
> upperdev for demux offload.
It is, I was just trying to broaden the scope to more capable HW so we
design APIs that would serve all.
> On 28/02/18 01:24, Alexander Duyck wrote:
>
> > We did something like this for i40e. Basically we required creating
> > the queue groups using mqprio to keep them symmetric on Tx and Rx, and
> > then allowed for TC ingress filters to redirect traffic to those queue
> > groups.
> >
> > - Alex
> If we're not doing macvlan offload, I'm not sure what, if anything, the
> TX side would buy us. So for now it seems to make sense for TX just to
> use the TXQ associated with the CPU from which the TX originates, which
> I believe already happens automatically.
I don't think that's what Alex was referring to. Please see
commit e284fc280473 ("i40e: Add and delete cloud filter") for
instance :)
