Thread (125 messages) 125 messages, 14 authors, 2014-04-02

Re: [patch net-next RFC 0/4] introduce infrastructure for support of switch chip datapath

From: Jiri Pirko <jiri@resnulli.us>
Date: 2014-03-26 13:17:51

Wed, Mar 26, 2014 at 12:00:53PM CET, jhs@mojatatu.com wrote:
On 03/26/14 03:21, Jiri Pirko wrote:
quoted
Creating bonding of the switch ports does not fit into the picture at
all. These port netdevices are just a representation of a port. Not
actual netdevice where the data goes through.

Please consider the case I gave already to this thread:

        switch chip
   ------------------------
    |  |  |  |  |  |   |               CPU
   p1 p2 ...pn px py  MNGMNT       -----------
                |  |   |              pcie
                |  |   |         ---------------
                |  |   |          |  NIC0 NIC1
                |  |   ---pcie-----   |   |
                |  ------someMII-------   |
                ---------someMII-----------

        NIC0 and NIC1 are ordinary NICs like 8139too for example with no
        notion they are connected to a switch. They as completely
        independent on the mngmnt iface.

There, actual data is coming through NIC0 and NIC1 which is
completely separated
from the p1...pn,px.px port representations.

And if you understand it this way, it makes perfect sense to have a
master device
for these port representations.
I think you may be looking at some specific board design which has those
two NICs; there are typically many variations of such boards and they
have to be each dealt with slightly differently by whoever is
porting. Important detail is:
It is just an example, nothing more.


we  already know how to deal with NICs - remove them from the diagram
and then the discussion is about the switch chip. I am assuming
the MNGMT interface is where the control is going to be. i.e
* I just tried to emphasize where the actual network traffic in between
  switch chip and CPU flows. That is important to realize I believe.

I can send table updates there, control the different port
charasterstics etc.
So Neil's option #1 is to have a driver controlling that interface
(->priv).
There's probably some DMA engine's for the datapath for one or more
of the ports this driver exposes...
See *.
Replace PCIE with DSA, a simulation chip, whatever the gazillion
crazy interfaces the openwrt guys have to deal with and we have
ourselves a consistent interface.

quoted
Btw note this model fits into existing DSA as well I believe. The actual DSA
devices whould act as NIC0, NIC1 and what would be added is the switch
representation (couple of more netdevices to represent actual HW ports and
their master)
Refer to my comments above.


cheers,
jamal
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help