Netdev List
 help / color / mirror / Atom feed
From: Jiri Pirko <jiri@resnulli.us>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Horatiu Vultur <horatiu.vultur@microchip.com>,
	alexandre.belloni@bootlin.com, UNGLinuxDriver@microchip.com,
	davem@davemloft.net, allan.nielsen@microchip.com,
	ivecera@redhat.com, f.fainelli@gmail.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/2] net: core: Notify on changes to dev->promiscuity.
Date: Fri, 30 Aug 2019 08:13:27 +0200	[thread overview]
Message-ID: <20190830061327.GM2312@nanopsycho> (raw)
In-Reply-To: <20190829143732.GB17864@lunn.ch>

Thu, Aug 29, 2019 at 04:37:32PM CEST, andrew@lunn.ch 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?.

tcpdump -i eth0
tcpdump -i eth0 --no-promiscuous-mode
tcpdump -i eth0 --hw-trapping-mode


> 
>> If you want to get packets from the hw forwarding dataplane to cpu, you
>> should use tc trap action. It is there exactly for this purpose.
>
>Do you really think a wireshark/tcpdump/pcap user should need to use
>tc trap for the special case the interface is a switch port? Doesn't that
>break the switchdev model?
>
>tc trap is more about fine grained selection of packets. Also, it
>seems like trapped packets are not forwarded, which is not what you
>would expect from wireshark/tcpdump/pcap.
>
>      Andrew

  parent reply	other threads:[~2019-08-30  6:13 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-29  9:22 [PATCH v3 0/2] net: core: Notify on changes to dev->promiscuity Horatiu Vultur
2019-08-29  9:22 ` [PATCH v3 1/2] " Horatiu Vultur
2019-08-29  9:51   ` Jiri Pirko
2019-08-29 10:56     ` Horatiu Vultur
2019-08-29 12:18       ` Jiri Pirko
2019-08-29 12:44         ` Horatiu Vultur
2019-08-29 12:55           ` Ivan Vecera
2019-08-29 13:15             ` Horatiu Vultur
2019-08-29 13:15             ` Andrew Lunn
2019-08-29 13:39               ` Ivan Vecera
2019-08-29 13:26     ` Andrew Lunn
2019-08-29 13:49       ` Jiri Pirko
2019-08-29 14:37         ` Andrew Lunn
2019-08-29 17:57           ` Ido Schimmel
2019-08-29 18:29             ` Andrew Lunn
2019-08-29 19:36               ` Ido Schimmel
2019-08-29 22:12                 ` David Miller
2019-08-30  5:39                   ` Jiri Pirko
2019-08-30  6:02                     ` David Miller
2019-08-30  6:36                       ` Jiri Pirko
2019-08-30  6:54                         ` Ivan Vecera
2019-08-30  7:13                           ` David Miller
2019-08-30  7:12                         ` David Miller
2019-08-30  7:21                           ` Jiri Pirko
2019-08-30  7:32                             ` David Miller
2019-08-30  8:01                               ` Jiri Pirko
2019-09-02 17:42                         ` Allan W. Nielsen
2019-09-02 17:51                           ` Jiri Pirko
2019-09-02 18:05                             ` Allan W. Nielsen
2019-09-02 18:45                               ` Jiri Pirko
2019-09-03  6:13                           ` Ido Schimmel
2019-09-03  8:14                             ` Allan W. Nielsen
2019-09-08 10:15                               ` Ido Schimmel
2019-08-30  9:43                   ` Ido Schimmel
2019-08-31 19:35                     ` Andrew Lunn
2019-08-31 20:47                       ` Ido Schimmel
2019-09-01 18:48                         ` Andrew Lunn
2019-09-02 17:55                           ` Allan W. Nielsen
2019-09-01  6:54                       ` Jiri Pirko
2019-08-29 22:10               ` David Miller
2019-08-29 22:08             ` David Miller
2019-08-30  6:13           ` Jiri Pirko [this message]
2019-08-30  6:18             ` David Miller
2019-08-30  7:26             ` Ivan Vecera
2019-08-29  9:22 ` [PATCH v3 2/2] net: mscc: Implement promisc mode Horatiu Vultur

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190830061327.GM2312@nanopsycho \
    --to=jiri@resnulli.us \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=allan.nielsen@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=horatiu.vultur@microchip.com \
    --cc=ivecera@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox