On Tue, Jun 05, 2018 at 06:23:45PM -0500, Grygorii Strashko wrote:
On 06/02/2018 07:26 PM, Andrew Lunn wrote:
*After this patch set*: goal keep things working the same as max as
possible and get rid of TI custom tool.
We are happy to keep things the same, if they fit with the switchdev
model
Hi Andrew,
>On Wed, Jun 06, 2018 at 01:53:56AM +0200, Andrew Lunn wrote:
> > And I just have to look a little bit in the future as selected approach
> > expected to be extended on future SoC (and other parts of existing SoCs -
> > ICSS-G SW switch)
> > where we going to have more features, like T
> And I just have to look a little bit in the future as selected approach
> expected to be extended on future SoC (and other parts of existing SoCs -
> ICSS-G SW switch)
> where we going to have more features, like TSN, EST and packet Policing and
> Classification.
You should probably took a clo
On Tue, Jun 05, 2018 at 06:23:45PM -0500, Grygorii Strashko wrote:
>
>
> On 06/02/2018 07:26 PM, Andrew Lunn wrote:
> >> *After this patch set*: goal keep things working the same as max as
> >> possible and get rid of TI custom tool.
> >
> > We are happy to keep things the same, if they fit with
> So, my understanding for (1) "blocked FDB entry support" is reasonable
> extension for bridge/switchdev ("green").
You might have to justify it, but yes.
> > Does the network stack need for forward specific multicast MAC
> > addresses between bridge ports independent of the state? If there is
>
On 06/02/2018 07:26 PM, Andrew Lunn wrote:
>> *After this patch set*: goal keep things working the same as max as
>> possible and get rid of TI custom tool.
>
> We are happy to keep things the same, if they fit with the switchdev
> model. Anything in your customer TI tool/model which does not f
On 06/02/2018 09:08 AM, Andrew Lunn wrote:
> On Fri, Jun 01, 2018 at 04:29:08PM -0500, Grygorii Strashko wrote:
>> Hi Ilias,
>
>
>> Second, Thanks a lot for your great work. I'm still testing it with different
>> use cases and trying to consolidate my reply for all questions.
>>
>> All, than
Hi Andrew,
Thanks a lot for you comments.
On 06/02/2018 07:49 PM, Andrew Lunn wrote:
> Hi Grygorii
>
>> Don't know howto:
>> 1) add FDB entry with "blocked" flag - ALE can discard all packets with
>> SRC/DST
>> address = blocked MAC
>> 2) add multicast MAC address with Supervisory Packet flag s
> PHC only one, but hw timestamping blocks are per port.
Yes, same as the Marvell. Per port, there are two receive time stamps
and one transmit time stamp.
Andrew
On 06/05/2018 04:28 PM, Andrew Lunn wrote:
I hope you are right - question is always in number of available options
and which one to select - and, most important, explain it to the end user :(
The end customer being ptp4linux? At least for Marvell switches, it is
happy about everything excep
> Right, thanky for the info, but still (sry, to be annoying) why default vlan
> is added by bridge
> when vlan_filtering == 0?
I have no idea!
I just made sure the Marvell driver works with this.
You might want to do a git blame and find out who added it, and it
might say why.
Andrew
On 06/02/2018 07:37 PM, Andrew Lunn wrote:
>> 1) boot, ping no vlan
>>
>> # ip link add name br0 type bridge
>> # echo 0 > /sys/class/net/br0/bridge/default_pvid
>> # ip link set dev eth2 master br0
>> # ip link set dev eth0 master br0
>> # ip link set dev eth1 master br0
>> # ifconfig br0 192.1
> I hope you are right - question is always in number of available options
> and which one to select - and, most important, explain it to the end user :(
The end customer being ptp4linux? At least for Marvell switches, it is
happy about everything except that the switch is a bit slow, so we
need
On 06/02/2018 07:08 PM, Andrew Lunn wrote:
> On Sat, Jun 02, 2018 at 06:28:22PM -0500, Grygorii Strashko wrote:
>
> Hi Grygorii
>
> I'm just picking out one thing here... there is lots more good stuff here.
>
>> Additional headache is PTP: we have on PHC, but both external interfaces
>> P1/P
Hi Grygorii
> Don't know howto:
> 1) add FDB entry with "blocked" flag - ALE can discard all packets with
> SRC/DST
> address = blocked MAC
> 2) add multicast MAC address with Supervisory Packet flag set.
> Such packets will bypass most of checks inside ALE and will be forwarded in
> all port's
> 1) boot, ping no vlan
>
> # ip link add name br0 type bridge
> # echo 0 > /sys/class/net/br0/bridge/default_pvid
> # ip link set dev eth2 master br0
> # ip link set dev eth0 master br0
> # ip link set dev eth1 master br0
> # ifconfig br0 192.168.1.2
>
> *Note*: I've had to disable default_pvid
> *After this patch set*: goal keep things working the same as max as
> possible and get rid of TI custom tool.
We are happy to keep things the same, if they fit with the switchdev
model. Anything in your customer TI tool/model which does not fit the
switchdev model you won't be able to keep, exce
On Sat, Jun 02, 2018 at 06:28:22PM -0500, Grygorii Strashko wrote:
Hi Grygorii
I'm just picking out one thing here... there is lots more good stuff here.
> Additional headache is PTP: we have on PHC, but both external interfaces P1/P2
> can timestamp packets.
This should not be a problem. The
Hi All,
Sry, for delayed reply.
On 05/24/2018 09:08 AM, Ilias Apalodimas wrote:
> On Thu, May 24, 2018 at 03:44:54PM +0200, Ivan Vecera wrote:
>> On 24.5.2018 14:54, Andrew Lunn wrote:
>>> On Thu, May 24, 2018 at 11:48:31AM +0300, Ilias Apalodimas wrote:
On Thu, May 24, 2018 at 10:05:28AM +0
On Fri, Jun 01, 2018 at 04:29:08PM -0500, Grygorii Strashko wrote:
> Hi Ilias,
> Second, Thanks a lot for your great work. I'm still testing it with different
> use cases and trying to consolidate my reply for all questions.
>
> All, thanks for your comments.
Hi Grygorii
Something i've said t
Hi Ilias,
On 05/24/2018 01:56 AM, Ilias Apalodimas wrote:
> Hello,
>
> This is adding a new mode on the cpsw driver based around switchdev.
> In order to enable this you need to enable CONFIG_NET_SWITCHDEV,
> CONFIG_BRIDGE_VLAN_FILTERING, CONFIG_TI_CPSW_SWITCHDEV
> and add to udev config:
>
> SU
Sorry for the late response i had some time to take another look and do some
extra testing
> switchdev is about offloading what Linux can do to hardware to
> accelerate it. The switch is a block of accelerator hardware, like a
> GPU is for accelerating graphics. Linux can render OpenGL, but it is
> Understood, if we missed back anything on handling multicast for
> the cpu port we'll go back and fix it (i am assuming snooping is the answer
> here).
It is part of the answer. You should also look at .ndo_set_rx_mode.
When the switch ports are not in a bridge, this call i used to pass a
list o
> So it's only static FBDs left.
Please describe the use case. Why would i want to put static FDB
addresses on a CPU port? What in the linux network stack needs this?
Andrew
On Fri, May 25, 2018 at 09:29:02AM +0300, Ilias Apalodimas wrote:
> On Thu, May 24, 2018 at 06:33:10PM +0200, Andrew Lunn wrote:
> > On Thu, May 24, 2018 at 07:02:54PM +0300, Ilias Apalodimas wrote:
> > > On Thu, May 24, 2018 at 05:25:59PM +0200, Andrew Lunn wrote:
> > > > O.K, back to the basic id
On Thu, May 24, 2018 at 06:33:10PM +0200, Andrew Lunn wrote:
> On Thu, May 24, 2018 at 07:02:54PM +0300, Ilias Apalodimas wrote:
> > On Thu, May 24, 2018 at 05:25:59PM +0200, Andrew Lunn wrote:
> > > O.K, back to the basic idea. Switch ports are just normal Linux
> > > interfaces.
> > >
> > > How
On Thu, May 24, 2018 at 07:02:54PM +0300, Ilias Apalodimas wrote:
> On Thu, May 24, 2018 at 05:25:59PM +0200, Andrew Lunn wrote:
> > O.K, back to the basic idea. Switch ports are just normal Linux
> > interfaces.
> >
> > How would you configure this with two e1000e put in a bridge? I want
> > mult
On Thu, May 24, 2018 at 05:25:59PM +0200, Andrew Lunn wrote:
> O.K, back to the basic idea. Switch ports are just normal Linux
> interfaces.
>
> How would you configure this with two e1000e put in a bridge? I want
> multicast to be bridged between the two e1000e, but the host stack
> should not se
> > That i can understand. And it should actually work now with
> > switchdev. It performs IGMP snooping, and if there is nothing joining
> > the group on the CPU, it won't add an MDB entry to forward traffic to
> > the CPU.
> Yes, but this should be configurable (i.e the customer can deny adding
On Thu, May 24, 2018 at 04:54:41PM +0200, Andrew Lunn wrote:
> If you cannot get an IP address, it is plain broken. The whole idea is
> that switch port interfaces are just linux interfaces. A linux
> interface which cannot get an IP address is broken.
The switch interfaces can get ip addresses jus
> There's configuration needs from customers adding or not adding a VLAN to the
> CPU port. In my configuration examples for instance, if the cpu port is not
> added to the bridge, you cannot get an ip address on it.
If you cannot get an IP address, it is plain broken. The whole idea is
that swit
On Thu, May 24, 2018 at 03:44:54PM +0200, Ivan Vecera wrote:
> On 24.5.2018 14:54, Andrew Lunn wrote:
> > On Thu, May 24, 2018 at 11:48:31AM +0300, Ilias Apalodimas wrote:
> >> On Thu, May 24, 2018 at 10:05:28AM +0200, Jiri Pirko wrote:
> >>> Thu, May 24, 2018 at 08:56:20AM CEST, ilias.apalodi...@l
On 24.5.2018 14:54, Andrew Lunn wrote:
> On Thu, May 24, 2018 at 11:48:31AM +0300, Ilias Apalodimas wrote:
>> On Thu, May 24, 2018 at 10:05:28AM +0200, Jiri Pirko wrote:
>>> Thu, May 24, 2018 at 08:56:20AM CEST, ilias.apalodi...@linaro.org wrote:
>>> Any reason you need cpu port? We don't need it i
On Thu, May 24, 2018 at 11:48:31AM +0300, Ilias Apalodimas wrote:
> On Thu, May 24, 2018 at 10:05:28AM +0200, Jiri Pirko wrote:
> > Thu, May 24, 2018 at 08:56:20AM CEST, ilias.apalodi...@linaro.org wrote:
> > Any reason you need cpu port? We don't need it in mlxsw and also in dsa.
> Yes i've seen t
On Thu, May 24, 2018 at 10:05:28AM +0200, Jiri Pirko wrote:
> Thu, May 24, 2018 at 08:56:20AM CEST, ilias.apalodi...@linaro.org wrote:
> Any reason you need cpu port? We don't need it in mlxsw and also in dsa.
Yes i've seen that on mlxsw/rocker drivers and i was reluctant adding one here.
The reas
Thu, May 24, 2018 at 08:56:20AM CEST, ilias.apalodi...@linaro.org wrote:
>Hello,
>
>This is adding a new mode on the cpsw driver based around switchdev.
>In order to enable this you need to enable CONFIG_NET_SWITCHDEV,
>CONFIG_BRIDGE_VLAN_FILTERING, CONFIG_TI_CPSW_SWITCHDEV
>and add to udev confi
Hello,
This is adding a new mode on the cpsw driver based around switchdev.
In order to enable this you need to enable CONFIG_NET_SWITCHDEV,
CONFIG_BRIDGE_VLAN_FILTERING, CONFIG_TI_CPSW_SWITCHDEV
and add to udev config:
SUBSYSTEM=="net", ACTION=="add", ATTR{phys_switch_id}=="0f011900", \
37 matches
Mail list logo
