Re: [PATCH v3 1/2] net: core: Notify on changes to dev->promiscuity.

From: Ivan Vecera
Date: Fri Aug 30 2019 - 03:26:43 EST


On Fri, 30 Aug 2019 08:13:27 +0200
Jiri Pirko <jiri@xxxxxxxxxxx> wrote:

> Thu, Aug 29, 2019 at 04:37:32PM CEST, andrew@xxxxxxx wrote:
> >> Wait, I believe there has been some misundestanding. Promisc mode
> >> is NOT about getting packets to the cpu. It's about setting hw
> >> filters in a way that no rx packet is dropped.
> >>
> >> If you want to get packets from the hw forwarding dataplane to
> >> cpu, you should not use promisc mode for that. That would be
> >> incorrect.
> >
> >Hi Jiri
> >
> >I'm not sure a wireshark/tcpdump/pcap user would agree with you. They
> >want to see packets on an interface, so they use these tools. The
> >fact that the interface is a switch interface should not matter. The
> >switchdev model is that we try to hide away the interface happens to
> >be on a switch, you can just use it as normal. So why should promisc
> >mode not work as normal?
>
> It does, disables the rx filter. Why do you think it means the same
> thing as "trap all to cpu"? Hw datapath was never considered by
> wireshark.
>
> In fact, I have usecase where I need to see only slow-path traffic by
> wireshark, not all packets going through hw. So apparently, there is a
> need of another wireshark option and perhaps another flag
> IFF_HW_TRAPPING?.

Agree with Jiri but understand both perspectives. We can treat
IFF_PROMISC as:

1) "I want to _SEE_ all Rx traffic on specified interface"
that means for switchdev driver that it has to trap all traffic to CPU
implicitly. And in this case we need another flag that will say "I
don't want to see offloaded traffic".

2) "I want to ensure that nothing is dropped on specified interface" so
IFF_PROMISC is treated as filtering option only. To see offloaded
traffic you need to setup TC rule with trap action or another flag like
IFF_TRAPPING.

IMO IFF_PROMISC should be considered to be a filtering option and
should not imply trapping of offloaded traffic.

Thanks,
Ivan