RE: [EXT] Re: [PATCH net-next 5/7] net: marvell: prestera: add LAG support
On Wed, Feb 10, 2021 at 10:41, Mickey Rachamim wrote: >> Until that day arrives, are there any chances of Marvell opening up CPSS in >> the same way DSDT was re-licensed some years back? > The CPSS code is available to everyone on Marvell Extranet (Requires simple > registration process) Right, but "available" is not the same as "open" unfortunately. Being able to study the source is better than nothing, but it is a far cry from having the ability to modify it and, most importantly, publish those changes. So, to restate my question more precisely: Can we expect that Marvell will provide CPSS under a license that is compatible with the Linux kernel? If that is not possible, will Marvell at least commit to allow the publishing of drivers developed from functional specifications and other chip documentation? > Anyway, as the transition process will progress - it will be less required. Yes, but it makes it hard for smaller players to get on the ride early. >> Being able to clone github.com/Marvell-switching/prestera-firmware (or >> whatever) and build the firmware from source would go a long way to >> alleviate my fears at least. > I understand your concerns but at this stage - we also concerned about others > that might build not reliable FW images. Totally fair. That problem should be solvable by some kind of taint concept though. Presumably you have this problem already with the existing SDK model? Customers can build things on top of CPSS that are broken in a million ways. > I also agree that at some point we should ensure most of the concerns are > being addressed. > > Mickey.
Re: [EXT] Re: [PATCH net-next 5/7] net: marvell: prestera: add LAG support
On Tue, 9 Feb 2021 20:31:32 + Mickey Rachamim wrote: > On Tuesday, February 9, 2021 7:35 PM Jakub Kicinski wrote: > > Sounds like we have 3 people who don't like FW-heavy designs dominating the > > kernel - this conversation can only go one way. > > Marvell, Plvision anything to share? AFAIU the values of Linux kernel are > > open source, healthy community, empowering users. With the SDK on the > > embedded CPU your driver does not seem to tick any of these boxes. > > I'll try to share Marvell's insight and plans regarding our Prestera drivers; > > We do understand the importance and the vision behind the open-source > community - while being committed to quality, functionality and the > developers/end-users. > > We started working on the Prestera driver in Q2 2019. it took us more > than a year to get the first approved driver into 5.10, and we just > started. Right at the beginning - we implemented PP function into the > Kernel driver like the SDMA operation (This is the RX/TX DMA engine). > Yet, the FW itself - is an SW package that supports many Marvell > Prestera Switching families of devices - this is a significant SW > package that will take many working years to adapt to the Kernel > environment. We do plan to port more and more PP functions as Kernel > drivers along the way. Okay, so it sounds like there are no technical reason for you to keep the SDK. My guess is also that you have a large customer who is expecting you to provide upstream integration, hence the contractors and taking the easiest way out. > We also are working with the community to extend Kernel functionality > with a new feature beneficial to all Kernel users (e.g. Devlink > changes) and we will continue to do it. Ah, devlink, every vendor's favorite interface. I keep my fingers crossed that you're not just talking about exposing a bunch of implementation-specific params, traps etc. > By extending the Prestera driver to in-kernel implementation with > more PP features - we will simplify the FW logic and enables > cost-effective solutions to the market/developers.
RE: [EXT] Re: [PATCH net-next 5/7] net: marvell: prestera: add LAG support
> It will be interesting to see how well you manage to handle the 'split brain' > problem. Right this is the challenge per each feature to ensure no "register" corruption. The PP itself provides us the right facilities and by driver-wise - we refactoring the driver almost from scratch. > I guess stats would be a good place to start... Right, mostly the MAC MIB counters. Mickey
RE: [EXT] Re: [PATCH net-next 5/7] net: marvell: prestera: add LAG support
> Until that day arrives, are there any chances of Marvell opening up CPSS in > the same way DSDT was re-licensed some years back? The CPSS code is available to everyone on Marvell Extranet (Requires simple registration process) Anyway, as the transition process will progress - it will be less required. > Being able to clone github.com/Marvell-switching/prestera-firmware (or > whatever) and build the firmware from source would go a long way to alleviate > my fears at least. I understand your concerns but at this stage - we also concerned about others that might build not reliable FW images. I also agree that at some point we should ensure most of the concerns are being addressed. Mickey.
Re: [EXT] Re: [PATCH net-next 5/7] net: marvell: prestera: add LAG support
> Right at the beginning - we implemented PP function into the Kernel > driver like the SDMA operation (This is the RX/TX DMA engine). > We do plan to port more and more PP functions as Kernel drivers > along the way. It will be interesting to see how well you manage to handle the 'split brain' problem. DMA packets to/from the host is pretty isolated from the rest of the driver. Look at DSA, it has completely separate drivers. But when you start having parts of the control plain in the driver poking switch registers, and parts of the control plane in the SDK poking registers, you have an interesting synchronisation problem. I guess stats would be a good place to start. Throw away the current code making an RPC into the SDK, and just directly get the values from the registers. No real synchronisation problems there. In fact, most of the ethtool get API calls should be reasonably easy to do via direct hardware access, rather than using the SDK RPC. Getting values like that should be easy to synchronise. Andrew
RE: [EXT] Re: [PATCH net-next 5/7] net: marvell: prestera: add LAG support
On Tue, Feb 09, 2021 at 20:31, Mickey Rachamim wrote: > Hi Andrew, Jakub, Tobias, > > On Tuesday, February 9, 2021 7:35 PM Jakub Kicinski wrote: >> Sounds like we have 3 people who don't like FW-heavy designs dominating the >> kernel - this conversation can only go one way. >> Marvell, Plvision anything to share? AFAIU the values of Linux kernel are >> open source, healthy community, empowering users. With the SDK on the >> embedded CPU your driver does not seem to tick any of these boxes. > > I'll try to share Marvell's insight and plans regarding our Prestera drivers; > > We do understand the importance and the vision behind the open-source > community - while being committed to quality, functionality and the > developers/end-users. > > We started working on the Prestera driver in Q2 2019. it took us more than a > year to get the first approved driver into 5.10, and we just started. > Right at the beginning - we implemented PP function into the Kernel driver > like the SDMA operation (This is the RX/TX DMA engine). > Yet, the FW itself - is an SW package that supports many Marvell Prestera > Switching families of devices - this is a significant SW package that will > take many working years to adapt to the Kernel environment. > We do plan to port more and more PP functions as Kernel drivers along the way. This is very encouraging to hear. I understand that it is a massive undertaking. > We also are working with the community to extend Kernel functionality with a > new feature beneficial to all Kernel users (e.g. Devlink changes) and we will > continue to do it. > By extending the Prestera driver to in-kernel implementation with more PP > features - we will simplify the FW logic and enables cost-effective solutions > to the market/developers. Until that day arrives, are there any chances of Marvell opening up CPSS in the same way DSDT was re-licensed some years back? Being able to clone github.com/Marvell-switching/prestera-firmware (or whatever) and build the firmware from source would go a long way to alleviate my fears at least. In such a world, I at least have a chance of debugging any issue all the way to the bottom of the stack. It would also make it possible for the community to help out with the porting effort. > Regards, > Mickey.
RE: [EXT] Re: [PATCH net-next 5/7] net: marvell: prestera: add LAG support
Hi Andrew, Jakub, Tobias, On Tuesday, February 9, 2021 7:35 PM Jakub Kicinski wrote: > Sounds like we have 3 people who don't like FW-heavy designs dominating the > kernel - this conversation can only go one way. > Marvell, Plvision anything to share? AFAIU the values of Linux kernel are > open source, healthy community, empowering users. With the SDK on the > embedded CPU your driver does not seem to tick any of these boxes. I'll try to share Marvell's insight and plans regarding our Prestera drivers; We do understand the importance and the vision behind the open-source community - while being committed to quality, functionality and the developers/end-users. We started working on the Prestera driver in Q2 2019. it took us more than a year to get the first approved driver into 5.10, and we just started. Right at the beginning - we implemented PP function into the Kernel driver like the SDMA operation (This is the RX/TX DMA engine). Yet, the FW itself - is an SW package that supports many Marvell Prestera Switching families of devices - this is a significant SW package that will take many working years to adapt to the Kernel environment. We do plan to port more and more PP functions as Kernel drivers along the way. We also are working with the community to extend Kernel functionality with a new feature beneficial to all Kernel users (e.g. Devlink changes) and we will continue to do it. By extending the Prestera driver to in-kernel implementation with more PP features - we will simplify the FW logic and enables cost-effective solutions to the market/developers. Regards, Mickey.
