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 netdevs
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 end
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 will
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 08:36
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 ap
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 wro
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
> >
> >> Becaus
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 c
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 rejoi
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 for
> 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 of
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 t
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 the
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 recei
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 isn
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 meanin
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 t
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 forwardi
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 anot
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 tel
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 interfa
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 probably
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 mea
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 add
> 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 t
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 fo
> 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 M
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 f
> 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 by
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 in
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 pro
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 noti
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
>notifier
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 valu
43 matches
Mail list logo
