Hi Roger / Andrew,
On 08/09/23 13:47, MD Danish Anwar wrote:
> On 08/09/23 13:16, Roger Quadros wrote:
>>
>>
>> On 05/09/2023 11:43, MD Danish Anwar wrote:
>>> On 04/09/23 19:38, Andrew Lunn wrote:
>>>>> Switch mode requires loading of new firmware into ICSSG cores. This
>>>>> means interfaces have to taken down and then reconfigured to switch mode
>>>>> using devlink.
>>>>
>>>> Can you always run it in switch mode, just not have the ports in a
>>>> bridge?
>>>>
>>>> Andrew
>>>
>>> No, we can't always run it in switch mode. Switch mode requires loading
>>> of different firmware. The switch firmware only supports switch
>>> operations. If the ports are not in a bridge in switch mode, the normal
>>> functionalities will not work. We will not be able to send / receive /
>>> forward packets in switch mode without bridge.
>>>
>>> When device is booted up, the dual EMAC firmware is loaded and ICSSG
>>> works in dual EMAC mode with both ports doing independent TX / RX.
>>>
>>> When switch mode is enabled, dual EMAC firmware is unloaded and switch
>>> firmware is loaded. The ports become part of the bridge and the two port
>>> together acts as a switch.
>>>
>>
>> Since we are loading the switch firmware and the switch logic is in firmware,
>> it means we don't really need Linux help to do basic switching on the external
>> ports.
>>
>> I suppose Andrews question was, can it work as a switch after switching
>> from dual-emac to switch mode and not setting up the Linux bridge.
>>
>
> I did some further testing on switch mode. The basic functionality would
> work without a bridge as well. This will need one modification in driver
> but even without bridge switching will work.
>
> When enabling switch mode the driver sets the HOST_MAC_ADDR to the
> bridge's addr. If bridge is not there, this will result in KERNEL NULL
> POINTER crash.
>
> icssg_class_set_host_mac_addr(prueth->miig_rt,
> prueth->hw_bridge_dev->dev_addr);
>
> However if we change this to only set when bridge is there, it works
>
> if (prueth->hw_bridge_dev)
> icssg_class_set_host_mac_addr(prueth->miig_rt,
> prueth->hw_bridge_dev->dev_addr);
>
> With this change forwarding works in switch mode without setting up the
> bridge. Just loading the switch firmware is enough.
>
>
>> e.g. Looking at your command list
>>
>>> Switch to ICSSG Switch mode:
>>> ip link set dev eth1 down
>>> ip link set dev eth2 down
>>> devlink dev param set platform/icssg2-eth name \
>>> switch_mode value 1 cmode runtime
>>
>> At this point, can it work as a switch. If not, why?>
>
> To summarize, yes it can work at this point.
>
As discussed on this thread, switching operation can work with the ICSSG
switch firmware, without creating bridge. However without bridge only
forwarding works. If we want the switch to consume packets bridge is
required.
ICSSG switch firmware without bridge
- Forwarding works but packets can not be consumed by switch.
ICSSG switch firmware without bridge
- Forwarding works and packets can be consumed by switch.
In order to consume the packets, creating a bridge is required.
I will keep the commands in commit message as it is. Please let me know
if this is OK to you or if any change is required.
>>> ip link add name br0 type bridge
>>> ip link set dev eth1 master br0
>>> ip link set dev eth2 master br0
>>> ip link set dev br0 up
>>> ip link set dev eth1 up
>>> ip link set dev eth2 up
>>> bridge vlan add dev br0 vid 1 pvid untagged self
>>
>
--
Thanks and Regards,
Danish
> As discussed on this thread, switching operation can work with the ICSSG
> switch firmware, without creating bridge. However without bridge only
> forwarding works. If we want the switch to consume packets bridge is
> required.
What packets will the switch consume? The only packets i can think of
are pause frames. Everything else get passed to the CPU.
You also need to think of what happens when a single switch port is
added to the bridge, and an external port, like a tun/tap device for a
VPN is added to the bridge.
For most switches, a port not being a member of a switch means the
port is pretty dumb and every frame is forwarded to the CPU. There are
however some switches which perform address learning as usual,
learning if an address is on the port, or on the CPU. Maybe you can
see if that is possible.
It might be you need your firmware people involved to produce a new
firmware version which combines both firmwares in one.
Andrew
Hi Andrew,
On 13/09/23 17:49, Andrew Lunn wrote:
>> As discussed on this thread, switching operation can work with the ICSSG
>> switch firmware, without creating bridge. However without bridge only
>> forwarding works. If we want the switch to consume packets bridge is
>> required.
>
> What packets will the switch consume? The only packets i can think of
> are pause frames. Everything else get passed to the CPU.
>
> You also need to think of what happens when a single switch port is
> added to the bridge, and an external port, like a tun/tap device for a
> VPN is added to the bridge.
>
> For most switches, a port not being a member of a switch means the
> port is pretty dumb and every frame is forwarded to the CPU. There are
> however some switches which perform address learning as usual,
> learning if an address is on the port, or on the CPU. Maybe you can
> see if that is possible.
>
> It might be you need your firmware people involved to produce a new
> firmware version which combines both firmwares in one.
>
Thanks for the offline discussion and explanations. As discussed, we can
not have one combined firmware to do both switch operations and dual
emac operations. It is required to have two different firmwares.
Currently which firmware to load is decided by flag 'is_switch_mode'
which is set / unset by devlink. I will not use devlink here as asked by
you. Instead, I'll use the approach suggested by you.
ndo_open() will load the dual mac firmware. I'll swap to switch firmware
when the second port is added to the same bridge as the first port.
I will re-work the changes and post v2 soon.
> Andrew
--
Thanks and Regards,
Danish