On Thu, Nov 09, 2017 at 10:13:15PM +0100, Andrew Lunn wrote:
> On Thu, Nov 09, 2017 at 12:35:32PM -0800, Florian Fainelli wrote:
> > +Ido, Jiri,
> >
> > On 11/09/2017 12:21 PM, Andrew Lunn wrote:
> > > On Thu, Nov 09, 2017 at 11:38:26AM -0800, Florian Fainelli wrote:
> > >> On 11/09/2017 11:30 AM,
On Thu, Nov 09, 2017 at 12:35:32PM -0800, Florian Fainelli wrote:
> +Ido, Jiri,
>
> On 11/09/2017 12:21 PM, Andrew Lunn wrote:
> > On Thu, Nov 09, 2017 at 11:38:26AM -0800, Florian Fainelli wrote:
> >> On 11/09/2017 11:30 AM, Andrew Lunn wrote:
> This means that switchdev drivers won't ever h
+Ido, Jiri,
On 11/09/2017 12:21 PM, Andrew Lunn wrote:
> On Thu, Nov 09, 2017 at 11:38:26AM -0800, Florian Fainelli wrote:
>> On 11/09/2017 11:30 AM, Andrew Lunn wrote:
This means that switchdev drivers won't ever have to treat a HOST_MDB
notification any differently than a PORT_MDB noti
On Thu, Nov 09, 2017 at 11:38:26AM -0800, Florian Fainelli wrote:
> On 11/09/2017 11:30 AM, Andrew Lunn wrote:
> >> This means that switchdev drivers won't ever have to treat a HOST_MDB
> >> notification any differently than a PORT_MDB notification
> >
> > No, they need to treat it very differentl
On 11/09/2017 11:30 AM, Andrew Lunn wrote:
>> This means that switchdev drivers won't ever have to treat a HOST_MDB
>> notification any differently than a PORT_MDB notification
>
> No, they need to treat it very differently.
Allow me to rephrase, switchdev drivers will ignore HOST_MDB
notificati
> This means that switchdev drivers won't ever have to treat a HOST_MDB
> notification any differently than a PORT_MDB notification
No, they need to treat it very differently.
A PORT_MDB says that frames for a group should be sent out that port.
So it probably needs to iterate all the ports in t
On 11/07/2017 04:41 PM, Florian Fainelli wrote:
> On 11/07/2017 03:17 PM, Andrew Lunn wrote:
>> On Tue, Nov 07, 2017 at 05:37:32PM -0500, Vivien Didelot wrote:
>>> Hi Andrew,
>>>
>>> Andrew Lunn writes:
>>>
> In a switch case, they all translate to programming a MDB entry for
> a given swi
Hi David,
David Miller writes:
> From: David Miller
> Date: Thu, 09 Nov 2017 11:30:32 +0900 (KST)
>
>> Series applied, with the spurious whitespace change removed from patch
>> #5.
>
> Actually I had to revert, this doesn't build:
>
> net/dsa/slave.c: In function ‘dsa_slave_port_obj_add’:
> net
From: David Miller
Date: Thu, 09 Nov 2017 11:30:32 +0900 (KST)
> Series applied, with the spurious whitespace change removed from patch
> #5.
Actually I had to revert, this doesn't build:
net/dsa/slave.c: In function ‘dsa_slave_port_obj_add’:
net/dsa/slave.c:311:26: warning: passing argument 1
From: Andrew Lunn
Date: Tue, 7 Nov 2017 00:26:53 +0100
> The linux bridge supports IGMP snooping. It will listen to IGMP
> reports on bridge ports and keep track of which groups have been
> joined on an interface. It will then forward multicast based on this
> group membership.
>
> When the bri
Hi Egil,
Egil Hjelmeland writes:
> But _all_ .port_mdb_add are repeated twice as well. This is more
> interesting. I suspect that there is a missing "return 0;" in
> dsa_switch_mdb_add(), at the end of the "if
> (switchdev_trans_ph_prepare(trans)) {". Dating back to
> a1a6b7ea7f2de270a51360cc
On Wed, Nov 08, 2017 at 04:11:12PM +0100, Egil Hjelmeland wrote:
> On 07. nov. 2017 18:58, Andrew Lunn wrote:
> >>Hi Andrew!
> >>
> >>When local application join multicast; the driver get 2 X .port_mdb_prepare
> >>+ 4 x .port_mdb_add for the address.
> >
> >Humm, i would expect equal numbers of tho
On 07. nov. 2017 18:58, Andrew Lunn wrote:
Hi Andrew!
When local application join multicast; the driver get 2 X .port_mdb_prepare
+ 4 x .port_mdb_add for the address.
Humm, i would expect equal numbers of those.
To be precise: it is (1 .port_mdb_prepare + 2 x .port_mdb_add), two times.
I s
On 11/07/2017 03:17 PM, Andrew Lunn wrote:
> On Tue, Nov 07, 2017 at 05:37:32PM -0500, Vivien Didelot wrote:
>> Hi Andrew,
>>
>> Andrew Lunn writes:
>>
In a switch case, they all translate to programming a MDB entry for
a given switch port, right?
>>>
>>> No, in fact it is the exact oppo
On Tue, Nov 07, 2017 at 05:37:32PM -0500, Vivien Didelot wrote:
> Hi Andrew,
>
> Andrew Lunn writes:
>
> >> In a switch case, they all translate to programming a MDB entry for
> >> a given switch port, right?
> >
> > No, in fact it is the exact opposite.
>
> Yes, they do. The proof is you call
Hi Andrew,
Andrew Lunn writes:
>> In a switch case, they all translate to programming a MDB entry for
>> a given switch port, right?
>
> No, in fact it is the exact opposite.
Yes, they do. The proof is you call dsa_port_mdb_add.
> A normal switchdev MDB says send traffic for a group OUT this p
> In a switch case, they all translate to programming a MDB entry for
> a given switch port, right?
No, in fact it is the exact opposite.
A normal switchdev MDB says send traffic for a group OUT this port.
A host switchdev MDB says send traffic coming IN from a port to the
CPU.
This is why i th
On 11/07/2017 01:01 PM, Andrew Lunn wrote:
>>> It is not quite as simple as that. Image:
>>>
>>> brctl addbr br0
>>> brctl addif br0 eth2
>>> brctl addif br0 lan0
>
> Hi Vivien
>
> I will reply to your other points later. But another scenario to think
> about.
>
> Take the above configuration.
>
> > It is not quite as simple as that. Image:
> >
> > brctl addbr br0
> > brctl addif br0 eth2
> > brctl addif br0 lan0
Hi Vivien
I will reply to your other points later. But another scenario to think
about.
Take the above configuration.
A join is received on eth2. The bridge makes switchdev ca
Hi Andrew,
Andrew Lunn writes:
>> > Then starts the work passing down to the hardware that the host has
>> > joined/left a group. The existing switchdev mdb object cannot be used,
>> > since the semantics are different. The existing
>> > SWITCHDEV_OBJ_ID_PORT_MDB is used to indicate a specific m
Hi Andrew,
On 11/07/2017 09:42 AM, Andrew Lunn wrote:
> On Tue, Nov 07, 2017 at 12:03:54PM -0500, Vivien Didelot wrote:
>> Hi Andrew,
>>
>> Andrew Lunn writes:
>>
>>> Then starts the work passing down to the hardware that the host has
>>> joined/left a group. The existing switchdev mdb object can
> Hi Andrew!
>
> I tested this series today on my board with lan9303, and it does seem to
> work. But no extensive testing though.
Cool, thanks. I've only been able to test on Marvell hardware.
> Some observations, not meant to delay the series:
>
> When local application join multicast; the dr
On Tue, Nov 07, 2017 at 12:03:54PM -0500, Vivien Didelot wrote:
> Hi Andrew,
>
> Andrew Lunn writes:
>
> > Then starts the work passing down to the hardware that the host has
> > joined/left a group. The existing switchdev mdb object cannot be used,
> > since the semantics are different. The exi
On 07. nov. 2017 00:26, Andrew Lunn wrote:
The linux bridge supports IGMP snooping. It will listen to IGMP
reports on bridge ports and keep track of which groups have been
joined on an interface. It will then forward multicast based on this
group membership.
When the bridge adds or removed group
Hi Andrew,
Andrew Lunn writes:
> Then starts the work passing down to the hardware that the host has
> joined/left a group. The existing switchdev mdb object cannot be used,
> since the semantics are different. The existing
> SWITCHDEV_OBJ_ID_PORT_MDB is used to indicate a specific multicast
> g
On Tue, 7 Nov 2017 00:26:53 +0100
Andrew Lunn wrote:
> The linux bridge supports IGMP snooping. It will listen to IGMP
> reports on bridge ports and keep track of which groups have been
> joined on an interface. It will then forward multicast based on this
> group membership.
>
> When the bridg
The linux bridge supports IGMP snooping. It will listen to IGMP
reports on bridge ports and keep track of which groups have been
joined on an interface. It will then forward multicast based on this
group membership.
When the bridge adds or removed groups from an interface, it uses
switchdev to req
27 matches
Mail list logo
