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.
I guess part of the question is, which other drivers besides us would want
to implement something like this, and what are their requirements?
> 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
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?
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.
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.
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
> - 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.