On Tue, Sep 03, 2019 at 10:14:12AM +0200, Allan W. Nielsen wrote:
> The 09/03/2019 09:13, Ido Schimmel wrote:
> > On Mon, Sep 02, 2019 at 07:42:31PM +0200, Allan W. Nielsen wrote:
> > With these patches applied I assume I will see the following traffic
> > when running tcpdump on one of the
Hi Ido,
The 09/03/2019 09:13, Ido Schimmel wrote:
> On Mon, Sep 02, 2019 at 07:42:31PM +0200, Allan W. Nielsen wrote:
> > I have been reading through this thread several times and I still do not
> > get it.
> I kept thinking about this and I want to make sure that I correctly
> understand the
On Mon, Sep 02, 2019 at 07:42:31PM +0200, Allan W. Nielsen wrote:
> I have been reading through this thread several times and I still do not get
> it.
Allan,
I kept thinking about this and I want to make sure that I correctly
understand the end result.
With these patches applied I assume I
Mon, Sep 02, 2019 at 08:05:20PM CEST, allan.niel...@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.niel...@microchip.com wrote:
>> >Hi Jiri,
>> >
>> >Sorry for joining the discussion this late, but I have been
The 09/02/2019 19:51, Jiri Pirko wrote:
> External E-Mail
>
>
> Mon, Sep 02, 2019 at 07:42:31PM CEST, allan.niel...@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
The 09/01/2019 20:48, Andrew Lunn wrote:
> > Look, this again boils down to what promisc mode means with regards to
> > hardware offload. You want it to mean punt all traffic to the CPU? Fine.
> > Does not seem like anyone will be switching sides anyway, so lets move
> > forward. But the current
Mon, Sep 02, 2019 at 07:42:31PM CEST, allan.niel...@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, da...@davemloft.net
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, da...@davemloft.net wrote:
> >From: Jiri Pirko
> >Date: Fri, 30 Aug 2019 07:39:40 +0200
> >
> >>
On Sat, Aug 31, 2019 at 11:47:05PM +0300, Ido Schimmel wrote:
> On Sat, Aug 31, 2019 at 09:35:56PM +0200, Andrew Lunn wrote:
> > > Also, what happens when I'm running these application without putting
> > > the interface in promisc mode? On an offloaded interface I would not be
> > > able to even
Sat, Aug 31, 2019 at 09:35:56PM CEST, and...@lunn.ch wrote:
>> Also, what happens when I'm running these application without putting
>> the interface in promisc mode? On an offloaded interface I would not be
>> able to even capture packets addressed to my interface's MAC address.
>
>Sorry for
On Sat, Aug 31, 2019 at 09:35:56PM +0200, Andrew Lunn wrote:
> > Also, what happens when I'm running these application without putting
> > the interface in promisc mode? On an offloaded interface I would not be
> > able to even capture packets addressed to my interface's MAC address.
>
> Sorry
> Also, what happens when I'm running these application without putting
> the interface in promisc mode? On an offloaded interface I would not be
> able to even capture packets addressed to my interface's MAC address.
Sorry for rejoining the discussion late. I've been travelling and i'm
now 3/4
On Thu, Aug 29, 2019 at 03:12:01PM -0700, David Miller wrote:
> From: Ido Schimmel
> Date: Thu, 29 Aug 2019 22:36:13 +0300
>
> > I fully agree that we should make it easy for users to capture offloaded
> > traffic, which is why I suggested patching libpcap. Add a flag to
> > capable netdevs that
Fri, Aug 30, 2019 at 09:32:25AM CEST, da...@davemloft.net wrote:
>From: Jiri Pirko
>Date: Fri, 30 Aug 2019 09:21:33 +0200
>
>> Fri, Aug 30, 2019 at 09:12:23AM CEST, da...@davemloft.net wrote:
>>>From: Jiri Pirko
>>>Date: Fri, 30 Aug 2019 08:36:24 +0200
>>>
The promiscuity is a way to setup
From: Jiri Pirko
Date: Fri, 30 Aug 2019 09:21:33 +0200
> Fri, Aug 30, 2019 at 09:12:23AM CEST, da...@davemloft.net wrote:
>>From: Jiri Pirko
>>Date: Fri, 30 Aug 2019 08:36:24 +0200
>>
>>> The promiscuity is a way to setup the rx filter. So promics == rx filter
>>> off. For normal nics, where
On Fri, 30 Aug 2019 08:13:27 +0200
Jiri Pirko wrote:
> Thu, Aug 29, 2019 at 04:37:32PM CEST, and...@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
Fri, Aug 30, 2019 at 09:12:23AM CEST, da...@davemloft.net wrote:
>From: Jiri Pirko
>Date: Fri, 30 Aug 2019 08:36:24 +0200
>
>> 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
From: Ivan Vecera
Date: Fri, 30 Aug 2019 08:54:45 +0200
> Promisc is Rx filtering option and should not imply that offloaded
> traffic is trapped to CPU.
Hardware is offloaded based upon an rx filter.
Stop this nonsense.
From: Jiri Pirko
Date: Fri, 30 Aug 2019 08:36:24 +0200
> 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.
You cannot convince me that the HW datapath
On Fri, 30 Aug 2019 08:36:24 +0200
Jiri Pirko wrote:
> Fri, Aug 30, 2019 at 08:02:33AM CEST, da...@davemloft.net wrote:
> >From: Jiri Pirko
> >Date: Fri, 30 Aug 2019 07:39:40 +0200
> >
> >> Because the "promisc mode" would gain another meaning. Now how the
> >> driver should guess which
Fri, Aug 30, 2019 at 08:02:33AM CEST, da...@davemloft.net wrote:
>From: Jiri Pirko
>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
From: Jiri Pirko
Date: Fri, 30 Aug 2019 08:13:27 +0200
> In fact, I have usecase where I need to see only slow-path traffic by
> wireshark, not all packets going through hw.
This could be an attribute in the descriptor entries for the packets
provided to userspace, and BPF filters could act on
Thu, Aug 29, 2019 at 04:37:32PM CEST, and...@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
From: Jiri Pirko
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
Fri, Aug 30, 2019 at 12:12:01AM CEST, da...@davemloft.net wrote:
>From: Ido Schimmel
>Date: Thu, 29 Aug 2019 22:36:13 +0300
>
>> I fully agree that we should make it easy for users to capture offloaded
>> traffic, which is why I suggested patching libpcap. Add a flag to
>> capable netdevs that
From: Ido Schimmel
Date: Thu, 29 Aug 2019 22:36:13 +0300
> I fully agree that we should make it easy for users to capture offloaded
> traffic, which is why I suggested patching libpcap. Add a flag to
> capable netdevs that tells libpcap that in order to capture all the
> traffic from this
From: Andrew Lunn
Date: Thu, 29 Aug 2019 20:29:57 +0200
> We should also think about the different classes of users. Somebody
> using a TOR switch with a NOS is very different to a user of a SOHO
> switch in their WiFi access point. The first probably knows tc very
> well, the second has
From: Ido Schimmel
Date: Thu, 29 Aug 2019 20:57:59 +0300
> On a software switch, when you run tcpdump without '-p', do you incur
> major packet loss? No. Will this happen when you punt several Tbps to
> your CPU on the hardware switch? Yes.
>
> Extending the definition of promiscuous mode to
On Thu, Aug 29, 2019 at 08:29:57PM +0200, Andrew Lunn wrote:
> > Hi Andrew,
> >
> > What happens when you run tcpdump on a routed interface without putting
> > it in promiscuous mode ('-p')? If it is a pure software switch, then you
> > see all unicast packets addressed to your interface's MAC
> Hi Andrew,
>
> What happens when you run tcpdump on a routed interface without putting
> it in promiscuous mode ('-p')? If it is a pure software switch, then you
> see all unicast packets addressed to your interface's MAC address. What
> happens when the same is done on a hardware switch? With
On Thu, Aug 29, 2019 at 04:37:32PM +0200, Andrew Lunn 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
> 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.
Thu, Aug 29, 2019 at 03:26:11PM CEST, and...@lunn.ch wrote:
>> NACK
>>
>> This is invalid usecase for switchdev infra. Switchdev is there for
>> bridge offload purposes only.
>
>Hi Jiri
>
>I would argue this is for bridge offload. In another email, you say
>promisc is promisc. Does that mean the
On Thu, 29 Aug 2019 15:15:43 +0200
Andrew Lunn wrote:
> The problem with this is, the driver only gets called when promisc
> goes from 0 to !0. So, the port is added to the bridge. Promisc goes
> 0->1, and the driver gets called. We can evaluate as you said above,
> and leave the port filtering
> NACK
>
> This is invalid usecase for switchdev infra. Switchdev is there for
> bridge offload purposes only.
Hi Jiri
I would argue this is for bridge offload. In another email, you say
promisc is promisc. Does that mean the Mellonox hardware forwards
every frame ingressing a port to the CPU
The 08/29/2019 14:55, Ivan Vecera wrote:
> External E-Mail
>
>
> On Thu, 29 Aug 2019 14:44:14 +0200
> Horatiu Vultur wrote:
>
> > When a port is added to a bridge, then the port gets in promisc mode.
> > But in our case the HW has bridge capabilities so it is not required
> > to set the port
On Thu, Aug 29, 2019 at 02:55:18PM +0200, Ivan Vecera wrote:
> On Thu, 29 Aug 2019 14:44:14 +0200
> Horatiu Vultur wrote:
>
> > When a port is added to a bridge, then the port gets in promisc mode.
> > But in our case the HW has bridge capabilities so it is not required
> > to set the port in
On Thu, 29 Aug 2019 14:44:14 +0200
Horatiu Vultur wrote:
> When a port is added to a bridge, then the port gets in promisc mode.
> But in our case the HW has bridge capabilities so it is not required
> to set the port in promisc mode.
> But if someone else requires the port to be in promisc mode
The 08/29/2019 14:18, Jiri Pirko wrote:
> External E-Mail
>
>
> Thu, Aug 29, 2019 at 12:56:54PM CEST, horatiu.vul...@microchip.com wrote:
> >The 08/29/2019 11:51, Jiri Pirko wrote:
> >> External E-Mail
> >>
> >>
> >> Thu, Aug 29, 2019 at 11:22:28AM CEST, horatiu.vul...@microchip.com wrote:
>
Thu, Aug 29, 2019 at 12:56:54PM CEST, horatiu.vul...@microchip.com wrote:
>The 08/29/2019 11:51, Jiri Pirko wrote:
>> External E-Mail
>>
>>
>> Thu, Aug 29, 2019 at 11:22:28AM CEST, horatiu.vul...@microchip.com wrote:
>> >Add the SWITCHDEV_ATTR_ID_PORT_PROMISCUITY switchdev notification type,
>>
The 08/29/2019 11:51, Jiri Pirko wrote:
> External E-Mail
>
>
> Thu, Aug 29, 2019 at 11:22:28AM CEST, horatiu.vul...@microchip.com wrote:
> >Add the SWITCHDEV_ATTR_ID_PORT_PROMISCUITY switchdev notification type,
> >used to indicate whenever the dev promiscuity counter is changed.
> >
> >The
Thu, Aug 29, 2019 at 11:22:28AM CEST, horatiu.vul...@microchip.com wrote:
>Add the SWITCHDEV_ATTR_ID_PORT_PROMISCUITY switchdev notification type,
>used to indicate whenever the dev promiscuity counter is changed.
>
>The notification doesn't use any switchdev_attr attribute because in the
Add the SWITCHDEV_ATTR_ID_PORT_PROMISCUITY switchdev notification type,
used to indicate whenever the dev promiscuity counter is changed.
The notification doesn't use any switchdev_attr attribute because in the
notifier callbacks is it possible to get the dev and read directly
the promiscuity
43 matches
Mail list logo
