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 :)

Reply via email to