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
| ||
|
Date: Thu, 1 Dec 2016 21:46:58 +0900 From: Toshiaki Makita <makita.toshiaki@....ntt.co.jp> To: Nikita Yushchenko <nikita.yoush@...entembedded.com>, Andy Duan <fugang.duan@....com>, "David S. Miller" <davem@...emloft.net>, Troy Kisky <troy.kisky@...ndarydevices.com>, Andrew Lunn <andrew@...n.ch>, Eric Nelson <eric@...int.com>, Philippe Reynes <tremyfr@...il.com>, Johannes Berg <johannes@...solutions.net>, "netdev@...r.kernel.org" <netdev@...r.kernel.org> Cc: Chris Healy <cphealy@...il.com>, Fabio Estevam <fabio.estevam@....com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Vivien Didelot <vivien.didelot@...oirfairelinux.com>, lorian Fainelli <f.fainelli@...il.com> Subject: Re: DSA vs envelope frames On 2016/11/30 23:58, Nikita Yushchenko wrote: >>> (1) When DSA is in use, frames processed by FEC chip contain DSA tag and >>> thus can be larger than hardcoded limit of 1522. This issue is not >>> FEC-specific, any driver that hardcodes maximum frame size to 1522 (many >>> do) will have this issue if used with DSA. >> >> BTW I'm trying to introduce envelope frames to solve this kind of problems. >> http://marc.info/?t=147496691500005&r=1&w=2 >> http://marc.info/?t=147496691500003&r=1&w=2 >> http://marc.info/?t=147496691500002&r=1&w=2 >> http://marc.info/?t=147496691500004&r=1&w=2 >> http://marc.info/?t=147496691500001&r=1&w=2 >> >> It needs jumbo frame support of NICs though. > > Thanks for pointing to this. > > Indeed frame with DSA tag conceptually is an envelope frame. > > ndev->env_hdr_len introduced by your patches, actually is explicitly > handled difference between (MTU + 18) and frame that HW should allow. > If this is known, hardware can be configured to work with DSA. At least > FEC hardware that can send and receive "slightly larger" frames after > simple register configuration. > > Furthermore, since DSA configuration is known statically (it comes from > device tree), ndo_set_env_hdr_len method could be automatically called > at init, making setup working by default if driver supports that. And if > not, perhaps can automatically lower MTU. > > Looks like a solution :) > > What's current status of this work? Thank you for taking a look. I'm planning to post v2 soon. > What is not really clear - what if several tagging protocols are used > together. AFAIU, things may be more complex that simple appending of > tags, e.g. EDSA tag can carry VLAN id inside. If kernel is aware of VLAN configuration, add 4 bytes + DSA tag size. (I'm not familiar with how dsa knows vlan configuration, but probably through switchdev_port_obj_add()? If so, dsa should be able to take into account additional vlan tag size.) If vlan tag is opaque from kernel, e.g. forwarding vlan tagged frames without configuring vlan_filtering in bridge, admin needs to set env_hdr_len manually. This is why I'm proposing manual operation. Regards, Toshiaki Makita
Powered by blists - more mailing lists