netdev - Re: [PATCH 3/5] net: dsa: ksz: Factor out common tag code

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: <4ece2103-a624-44d5-ecf7-d5423275f5af@denx.de>
Date:   Mon, 10 Dec 2018 22:58:26 +0100
From:   Marek Vasut <marex@...x.de>
To:     Tristram.Ha@...rochip.com, andrew@...n.ch
Cc:     netdev@...r.kernel.org, f.fainelli@...il.com,
        vivien.didelot@...oirfairelinux.com, Woojung.Huh@...rochip.com,
        UNGLinuxDriver@...rochip.com, davem@...emloft.net
Subject: Re: [PATCH 3/5] net: dsa: ksz: Factor out common tag code

On 12/10/2018 09:32 PM, Tristram.Ha@...rochip.com wrote:
>> On Fri, Dec 07, 2018 at 07:18:43PM +0100, Marek Vasut wrote:
>>> From: Tristram Ha <Tristram.Ha@...rochip.com>
>>>
>>> Factor out common code from the tag_ksz , so that the code can be used
>>> with other KSZ family switches which use differenly sized tags.
>>
>> I prefer this implementation over what Tristram recently submitted. It
>> is also what we suggested a while back. However, since then we have
>> had Spectra/meltdown, and we now know a function call through a
>> pointer is expensive. This is the hot path, every frame comes through
>> here, so it is worth taking the time to optimize this. Could you try
>> to remove the ksz_tag_ops structure. xmit looks simple, since it is a
>> tail call, so you can do that in ksz9477_xmit. Receive looks a bit
>> more complex.
>>
>> I also think for the moment we need it ignore PTP until we have the
>> big picture sorted out. If need be, the code can be refactored yet
>> again. But i don't want PTP holding up getting more switches
>> supported.
> 
> Yes, as you may already know, what Marek submitted was my previous
> attempt to support different switches in tag_ksz.c.

I adjusted the code quite a bit, please look again.

> So this ksz_tag_ops is still not acceptable?  As I understand the kernel is
> using this mechanism all over the places.
> 
> What is left is a direct copying of the transmit and receive functions for each
> new switch tail tag format.

Maybe a macro would work ? Or some code runtime-patching ?

-- 
Best regards,
Marek Vasut