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,
On 09.02.2021 19:35, 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, empower
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
> 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 g
> 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
> 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' p
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
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
On Tue, 09 Feb 2021 12:56:55 +0100 Tobias Waldekranz wrote:
> > I ask myself that question pretty much every day. Sadly I have no clear
> > answer.
>
> Thank you for your candid answer, really appreciate it. I do not envy
> you one bit, making those decisions must be extremely hard.
>
> > Silic
On Tue, 9 Feb 2021 14:58:26 +0100 Andrew Lunn wrote:
> > At the same time some FW is necessary. Certain chip functions, are
> > best driven by a micro-controller running a tight control loop.
>
> For a smart NIC, i could agree. But a switch? The data path is in
> hardware. The driver is all ab
> At the same time some FW is necessary. Certain chip functions, are
> best driven by a micro-controller running a tight control loop.
For a smart NIC, i could agree. But a switch? The data path is in
hardware. The driver is all about configuring this hardware, and then
it is idle. Polls the PHY
On Mon, Feb 08, 2021 at 23:30, Andrew Lunn wrote:
>> > I took a quick look at it, and what I found left me very puzzled. I hope
>> > you do not mind me asking a generic question about the policy around
>> > switchdev drivers. If someone published a driver using something similar
>> > to the follow
On Mon, Feb 08, 2021 at 13:05, Jakub Kicinski wrote:
> On Mon, 08 Feb 2021 20:54:29 +0100 Tobias Waldekranz wrote:
>> On Thu, Feb 04, 2021 at 21:16, Jakub Kicinski wrote:
>> > On Wed, 3 Feb 2021 18:54:56 +0200 Vadym Kochan wrote:
>> >> From: Serhiy Boiko
>> >>
>> >> The following features ar
> > I took a quick look at it, and what I found left me very puzzled. I hope
> > you do not mind me asking a generic question about the policy around
> > switchdev drivers. If someone published a driver using something similar
> > to the following configuration flow:
> >
> > iproute2 daemon(SDK)
On Mon, 08 Feb 2021 20:54:29 +0100 Tobias Waldekranz wrote:
> On Thu, Feb 04, 2021 at 21:16, Jakub Kicinski wrote:
> > On Wed, 3 Feb 2021 18:54:56 +0200 Vadym Kochan wrote:
> >> From: Serhiy Boiko
> >>
> >> The following features are supported:
> >>
> >> - LAG basic operations
> >>
On Thu, Feb 04, 2021 at 21:16, Jakub Kicinski wrote:
> On Wed, 3 Feb 2021 18:54:56 +0200 Vadym Kochan wrote:
>> From: Serhiy Boiko
>>
>> The following features are supported:
>>
>> - LAG basic operations
>> - create/delete LAG
>> - add/remove a member to LAG
>> - en
On Wed, Feb 03, 2021 at 06:54:56PM +0200, Vadym Kochan wrote:
> +static struct prestera_lag *prestera_lag_by_dev(struct prestera_switch *sw,
> + struct net_device *dev)
> +{
> + struct prestera_lag *lag;
> + u16 id;
> +
> + for (id = 0; id < s
On Wed, 3 Feb 2021 18:54:56 +0200 Vadym Kochan wrote:
> From: Serhiy Boiko
>
> The following features are supported:
>
> - LAG basic operations
> - create/delete LAG
> - add/remove a member to LAG
> - enable/disable member in LAG
> - LAG Bridge support
> - LA
From: Serhiy Boiko
The following features are supported:
- LAG basic operations
- create/delete LAG
- add/remove a member to LAG
- enable/disable member in LAG
- LAG Bridge support
- LAG VLAN support
- LAG FDB support
Limitations:
- Only HASH lag tx
19 matches
Mail list logo
