netdev - Re: [PATCH 0/4] RFC CPSW switchdev mode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4908e5f8-7533-6fa5-866f-1fb32fd13857@ti.com>
Date:   Tue, 5 Jun 2018 18:23:45 -0500
From:   Grygorii Strashko <grygorii.strashko@...com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     Ilias Apalodimas <ilias.apalodimas@...aro.org>,
        Ivan Vecera <ivecera@...hat.com>,
        Jiri Pirko <jiri@...nulli.us>, <netdev@...r.kernel.org>,
        <ivan.khoronzhuk@...aro.org>, <nsekhar@...com>,
        <francois.ozog@...aro.org>, <yogeshs@...com>, <spatton@...com>
Subject: Re: [PATCH 0/4] RFC CPSW switchdev mode



On 06/02/2018 07:26 PM, Andrew Lunn wrote:
>> *After this patch set*: goal keep things working the same as max as
>> possible and get rid of TI custom tool.
> 
> We are happy to keep things the same, if they fit with the switchdev
> model. Anything in your customer TI tool/model which does not fit the
> switchdev model you won't be able to keep, except if we agree to
> extend the model.

Right. That's the main goal of RFC to identify those gaps.

> 
> I can say now, sw0p0 is going to cause problems. I really do suggest
> you drop it for the moment in order to get a minimal driver
> accepted. sw0p0 does not fit the switchdev model.

Honestly, this is not the first patchset and we started without sw0p0,
but then.... (with current LKML)
- default vlan offloading breaks traffic reception to P0
 (Ilias saying it's fixed in next - good)
- adding vlan to P1/P2 works, but not for P0 (again as per Ilias -fixed)
- mcast - no way to manually add static record and include or exclude P0.


:( above are basic functionality required.

> 
>> Below I've described some tested use cases (not include full static configuration),
>> but regarding sw0p0 - there is work done by Ivan Khoronzhuk [1] which enables
>> adds MQPRIO and CBS Qdisc and targets AVB network features. It required to
>> offload MQPRIO and CBS parameters on all ports including P0. In case of P0,
>> CPDMA TX channels shapers need to be configured, and in case
>> of sw0p1/sw0p2 internal FIFOS.
>> sw0p0 also expected to be used to configure CPDMA interface in general -
>> number of tx/rx channels, rates, ring sizes.
> 
> Can this be derives from the configuration on sw0p1 and sw0p2?
> sw0p1 has 1 tx channel, sw0p2 has 2 tx channels, so give p0 3 tx
> channels?

This not exactly what is required, sry I probably will need just repeat what Ivan 
described in https://lkml.org/lkml/2018/5/18/1135. I'd try to provide this info tomorrow.

Unfortunately, I'm not sure if all this reworking and switchdev conversation would make sense
if we will not be able to fit Ivan's work in new CPSW driver model ;..(
and do AVB bridge.

> 
>> In addition there is set of global CPSW parameters (not related to P1/P2, like
>> MAC Authorization Mode, OUI Deny Mode, crc ) which I've
>> thought can be added to sw0p0 (using ethtool -priv-flags).
> 
> You should describe these features, and then we can figure out how
> best to model them. devlink might be an option if they are switch
> global.

Ok. that can be postponed.

-- 
regards,
-grygorii