Date:   Mon, 30 Apr 2018 18:36:58 +0530
From:   "sk.syed2" <sk.syed2@...il.com>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     netdev@...r.kernel.org, jayaram@...inx.com, syeds@...inx.com,
        andrew@...n.ch, vivien.didelot@...oirfairelinux.com
Subject: Re: Representing cpu-port of a switch

> Again, pretty standard. What you probably meant is that for host destined or initiated traffic you must use that internal port to egress/ingress frames towards the other external ports.
>
Yes.

>
>>Without tagging, we cant really use DSA, and hide the cpu/dsa port. So
>>if we expose this cpu port as a interface with fixed-phy
>>infrastructure does it create any problems?
>
> Well the fact that you don't have a tagging protocol does not really mean you cannot use DSA. You could create your own tagging format which in your case could be as simple as keeping the prepended DMA packet descriptor and have the parsing of that descriptor be done in a DSA tagger driver.
This would need HW change wont it?

 Not that I would necessarily recommend that though, see below.
>

>  DSA documentation says one
>>cannot open a socket on cpu/dsa port and send/receive traffic. Is it
>>fairly common to use internal/cpu port as a network interface- i.e,
>>creating a socket and send/receive traffic?
>
> In the context of DSA, all external ports are represented by a network device. This means that the CPU/management port is only used to ingress/egress frames that include the tag which either the switch hardware inserts on its way to the host or conversely that the host must insert to have the switch do the appropriate switching operation. If you do not use tags and you still have a way to target specific external ports the same representation should happen and you do not want to expose the internal port because it will only be used to send/receive traffic from the external ports and it will not be used to send or receive traffic to itself (so to speak).
Just like with DSA you should have the ability to create network
devices that are per-port and you can use the HW provided information
to deliver packets to the appropriate destination port, conversely
send from the appropriate source port.
>
>
The switch HW doesn't have any provision to target specific external
port. I think I didnt make this clear. We would like to integrate a
switch along with an endpoint into a single HW. Meaning we would like
to use internal cpu port as any normal network port to send and
receive traffic. The external network ports will not be used to
send/receive normal traffic(except for control/mgmt frames). So, the
two external front panel ports tied to phys are lets say eth1, eth2.
The cpu port tied to DMAs is represented using fixed-link/always_on
interface say ep0(endpoint). Now applications can open a socket and
send/receive traffic from ep0. The switch does forwarding based on
programmed CAM. Do you see any problem with this approach?



>>One problem is how to report back when network errors(like if both
>>front panel ports are disconnected, the expectation is to bring this
>>cpu port down?).
>
> The CPU port should be considered always UP and the external ports must have proper link notifications in place through PHYLIB/PHYLINK preferably. With link management in place the carrier state is properly managed and the network stack won't send traffic from a port that is not UP.
>
>>We also need to offload all the switch configuration to switch-dev. So
>>the question is using switch-dev without DSA and representing a cpu
>>port as a normal network interface would be ok?
>
> Using switchdev without DSA is absolutely okay, see rocker and mlxsw, but neither of those do represent their CPU/management port for the reasons outlined above that it is only used to convey traffic to/from other ports that have a proper network device representation.
>
May be this is something elementary, but what do you mean by proper
network device representation that cpu port lacks?

Powered by blists - more mailing lists