Thread (72 messages) 72 messages, 7 authors, 2021-01-29

Re: [patch net-next RFC 00/10] introduce line card support for modular switch

From: Jiri Pirko <jiri@resnulli.us>
Date: 2021-01-18 13:09:45

Fri, Jan 15, 2021 at 08:26:17PM CET, kuba@kernel.org wrote:
On Fri, 15 Jan 2021 15:39:06 +0100 Jiri Pirko wrote:
quoted
quoted
I'm not a SFP experts so maybe someone will correct me but AFAIU
the QSFP (for optics) is the same regardless of breakout. It's the
passive optical strands that are either bundled or not. So there is 
no way for the system to detect the cable type (AFAIK).  
For SFP module, you are able to detect those.
Not sure you understand what I'm saying. Maybe you're thinking about
DACs? This is a optical cable for breakout:

https://www.fs.com/products/68048.html

There is no electronics in it to "detect" things AFAIU. Same QSFP can
be used with this cable or a non-breakout.
Ah, got you.

quoted
quoted
Or to put it differently IMO the netdev should be provisioned if the
system has a port into which user can plug in a cable. When there is   
Not really. For slit cables, the ports are provisioned not matter which
cable is connected, slitter 1->2/1->4 or 1->1 cable.

quoted
a line card-sized hole in the chassis, I'd be surprised to see ports.

That said I never worked with real world routers so maybe that's what
they do. Maybe some with a Cisco router in the basement can tell us? :)  
The need for provision/pre-configure splitter/linecard is that the
ports/netdevices do not disapper/reappear when you replace
splitter/linecard. Consider a faulty linecard with one port burned. You
just want to replace it with new one. And in that case, you really don't
want kernel to remove netdevices and possibly mess up routing for
example.
Having a single burned port sounds like a relatively rare scenario.
Hmm, rare in scale is common...

Reconfiguring routing is not the end of the world.
Well, yes, but you don't really want netdevices to come and go then you
plug in/out cables/modules. That's why we have split implemented as we
do. I don't understand why do you think linecards are different.

Plus, I'm not really sure that our hw can report the type, will check.
One way or another, I think that both configuration flows have valid
usecase. Some user may want pre-configuration, some user may want auto.
Btw, it is possible to implement splitter cable in auto mode as well.

quoted
quoted
If the device really needs this configuration / can't detect things
automatically, then we gotta do something like what you have.
The only question is do we still want to call it a line card.
Sounds more like a front panel module. At Netronome we called 
those phymods.  
Sure, the name is up to the discussion. We call it "linecard"
internally. I don't care about the name.
Yeah, let's call it something more appropriate to indicate its
breakout/retimer/gearbox nature, and we'll be good :)
Well, it can contain much more. It can contain a smartnic/fpga/whatever
for example. Not sure we can find something that fits to all cases.
I was thinking about it in the past, I think that the linecard is quite
appropriate. It connects with lines/lanes, and it does something,
either phy/gearbox, or just interconnects the lanes using smartnic/fpga
for example.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help