Messages in this thread | | | Date | Mon, 2 Sep 2019 20:45:57 +0200 | From | Jiri Pirko <> | Subject | Re: [PATCH v3 1/2] net: core: Notify on changes to dev->promiscuity. |
| |
Mon, Sep 02, 2019 at 08:05:20PM CEST, allan.nielsen@microchip.com wrote: >The 09/02/2019 19:51, Jiri Pirko wrote: >> External E-Mail >> >> >> Mon, Sep 02, 2019 at 07:42:31PM CEST, allan.nielsen@microchip.com wrote: >> >Hi Jiri, >> > >> >Sorry for joining the discussion this late, but I have been without mail access >> >for the last few days. >> > >> > >> >The 08/30/2019 08:36, Jiri Pirko wrote: >> >> Fri, Aug 30, 2019 at 08:02:33AM CEST, davem@davemloft.net wrote: >> >> >From: Jiri Pirko <jiri@resnulli.us> >> >> >Date: Fri, 30 Aug 2019 07:39:40 +0200 >> >> > >> >> >> Because the "promisc mode" would gain another meaning. Now how the >> >> >> driver should guess which meaning the user ment when he setted it? >> >> >> filter or trap? >> >> >> >> >> >> That is very confusing. If the flag is the way to do this, let's >> >> >> introduce another flag, like IFF_TRAPPING indicating that user wants >> >> >> exactly this. >> >> > >> >> >I don't understand how the meaning of promiscuous mode for a >> >> >networking device has suddenly become ambiguous, when did this start >> >> >happening? >> >> >> >> The promiscuity is a way to setup the rx filter. So promics == rx filter >> >> off. For normal nics, where there is no hw fwd datapath, >> >> this coincidentally means all received packets go to cpu. >> >> But if there is hw fwd datapath, rx filter is still off, all rxed packets >> >> are processed. But that does not mean they should be trapped to cpu. >> >> >> >> Simple example: >> >> I need to see slowpath packets, for example arps/stp/bgp/... that >> >> are going to cpu, I do: >> >> tcpdump -i swp1 >> > >> >How is this different from "tcpdump -p -i swp1" >> > >> >> I don't want to get all the traffic running over hw running this cmd. >> >> This is a valid usecase. >> >> >> >> To cope with hw fwd datapath devices, I believe that tcpdump has to have >> >> notion of that. Something like: >> >> >> >> tcpdump -i swp1 --hw-trapping-mode >> >> >> >> The logic can be inverse: >> >> tcpdump -i swp1 >> >> tcpdump -i swp1 --no-hw-trapping-mode >> >> >> >> However, that would provide inconsistent behaviour between existing and >> >> patched tcpdump/kernel. >> >> >> >> All I'm trying to say, there are 2 flags >> >> needed (if we don't use tc trap). >> > >> >I have been reading through this thread several times and I still do not get it. >> > >> >As far as I understand you are arguing that we need 3 modes: >> > >> >- tcpdump -i swp1 >> >> Depends on default. Promisc is on. >> >> >> >- tcpdump -p -i swp1 >> >> All traffic that is trapped to the cpu by default, not promisc means >> only mac of the interface (if bridge for example haven't set promisc >> already) and special macs. So host traffic (ip of host), bgp, arp, nsnd, >> etc. > >In the case where the interface is enslaved to a bridge, it is put into promisc >mode, which means that "tcpdump -i swp1" and "tcpdump -p -i swp1" give the same >result, right? > >Is this desirable?
Yes, that is correct and expected. It it might not be bridged, depends on a usecase.
> >> >- tcpdump -i swp1 --hw-trapping-mode >> >> Promisc is on, all traffic received on the port and pushed to cpu. User >> has to be careful because in case of mlxsw this can lead to couple >> hundred gigabit traffic going over limited pci bandwidth (gigabits). >> >> >> > >> >Would you mind provide an example of the traffic you want to see in the 3 cases >> >(or the traffic which you do not want to see). >> > >> >/Allan >> > >> > >-- >/Allan
| |