netdev - Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver

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]

Date:   Thu, 09 Nov 2017 19:21:46 +0200
From:   Roman Yeryomin <roman@...em.lv>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        Vivien Didelot <vivien.didelot@...oirfairelinux.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        netdev@...r.kernel.org,
        Antti Seppälä 
        <a.seppala@...il.com>,
        Colin Leitner <colin.leitner@...glemail.com>,
        Gabor Juhos <juhosg@...nwrt.org>
Subject: Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver

On 2017-11-09 17:38, Andrew Lunn wrote:
>> >>Unless switchdev could be expanded to support other functions beyond
>> >>VLAN,
>> >>like port rate control, ACL, HW NAT (no switchdev L3 offload doesn't fit
>> >>this), etc.
>> >
>> >Switchdev allows offloading of TC. So port rate control would be
>> >implemented via TC.
>> 
>> That's interesting. Are there any examples implemented?
> 
> Mellonex have a few for there TOR switches.
> 
> The SF2 has TC mirred implemented. I could also implement this for
> Marvell without too much effort.  No DSA switch yet implements port
> rate control via TC. But TC would be the correct interface to use.
> 
>> >By ACL do you mean filtering MAC addresses?
>> 
>> Not only. Usually ACL means defining action with rules matching MAC/IP
>> address, physical or TCP/IP port, VID, Ethertype or even custom bytes.
>> And actions could be drop, assign rate, change VID/priority, force L3
>> offload or mirroring, redirect/copy to CPU port.
> 
> So this means mapping iptable rules to the switches TCAM. Pablo has
> said he is working on this, but there has not been any code posted
> yet.
> 
>> But the question how exactly it will be done?
> 
> The whole idea with switchdev is that your switch interfaces look like
> a bunch of linux interfaces, and you configure them just as normal
> Linux interface. You setup NAT as you would normally setup NAT. It
> then gets pushed down to the hardware. You setup TC rules or ip table
> rules on the interface, and they get pushed down to the hardware.
> 
> It is just Linux networking as normal. Think of the switch as an
> accelerator for what Linux networking can already do.

Yes, this is exactly how I think of it.
But there are many nuances for every switch/vendor.
The registers writing code is where? switchdev driver?
All I care about is that all the switch specific code should be in one 
place.
If switchdev can provide such place then everything else is a matter of 
time and will, like you said.

Regards,
Roman