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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 1 Sep 2022 14:39:12 +0300 From: Vladimir Oltean <olteanv@...il.com> To: Kurt Kanzenbach <kurt@...utronix.de> Cc: "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Andrew Lunn <andrew@...n.ch>, Vivien Didelot <vivien.didelot@...il.com>, Florian Fainelli <f.fainelli@...il.com>, netdev@...r.kernel.org Subject: Re: [PATCH net-next] net: dsa: hellcreek: Print warning only once On Thu, Sep 01, 2022 at 08:21:33AM +0200, Kurt Kanzenbach wrote: > > So from Florian's comment above, he was under case (b), different than yours. > > I don't understand why you say that when ACS is set, "the STP frames are > > truncated and the trailer tag is gone". Simply altering the ACS bit > > isn't going to change the determination made by stmmac_rx(). My guess > > based on the current input I have is that it would work fine for you > > (but possibly not for Florian). > > I thought so too. However, altering the ACS Bit didn't help at all. This is curious. Could you dump the Length/Type Field (LT bits 18:16) from the RDES3 for these packets? If ACS does not take effect, it would mean the DWMAC doesn't think they're Length packets I guess? Also, does the Error Summary say anything? In principle, the length of this packet is greater than the EtherType/Length would say, by the size of the tail tag. Not sure how that affects the RX parser. > We could do some measurements e.g., with perf to determine whether > removing the FCS logic has positive or negative effects? Yes, some IP forwarding of 60 byte frames at line rate gigabit or higher should do the trick. Testing with MTU sized packets is probably not going to show much of a difference. > > How large can you configure the hellcreek switch to send packets towards > > the DSA master? Could you force a packet size (including hellcreek tail tag) > > comparable to dma_conf->dma_buf_sz? > > I don't think so. > > > Or if not, perhaps you could hack the way in which stmmac_set_bfsize() > > works, or one of the constants? > > I'm not sure if i follow you here. I mean if you can't bring the MTU of the switch closer to the buffer size of the DSA master, at least bring the buffer size closer to the MTU of the switch. If this means, idk, hacking the DEFAULT_BUFSIZE macro to a lower value such as to force splitting some otherwise "normal" packet sizes into 2 buffers, fine. Then, the next step would be to force this splitting to occur exactly where the FCS lies in the buffers. Then I should be able to hear the kaboom from over here.
Powered by blists - more mailing lists