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 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? 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 > 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. -Ed
