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
| ||
|
Message-ID: <20230216103536.abju64jbpucfyqir@skbuf> Date: Thu, 16 Feb 2023 12:35:36 +0200 From: Vladimir Oltean <vladimir.oltean@....com> To: Kurt Kanzenbach <kurt@...utronix.de> Cc: netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Jamal Hadi Salim <jhs@...atatu.com>, Cong Wang <xiyou.wangcong@...il.com>, Jiri Pirko <jiri@...nulli.us>, Vinicius Costa Gomes <vinicius.gomes@...el.com>, Gerhard Engleder <gerhard@...leder-embedded.com>, linux-kernel@...r.kernel.org Subject: Re: [PATCH net-next 3/3] net/sched: taprio: dynamic max_sdu larger than the max_mtu is unlimited On Thu, Feb 16, 2023 at 12:29:14PM +0200, Vladimir Oltean wrote: > On Thu, Feb 16, 2023 at 10:28:48AM +0100, Kurt Kanzenbach wrote: > > On Thu Feb 16 2023, Vladimir Oltean wrote: > > > It makes no sense to keep randomly large max_sdu values, especially if > > > larger than the device's max_mtu. These are visible in "tc qdisc show". > > > Such a max_sdu is practically unlimited and will cause no packets for > > > that traffic class to be dropped on enqueue. > > > > > > Just set max_sdu_dynamic to U32_MAX, which in the logic below causes > > > taprio to save a max_frm_len of U32_MAX and a max_sdu presented to user > > > space of 0 (unlimited). > > > > > > Signed-off-by: Vladimir Oltean <vladimir.oltean@....com> > > > > Doesn't this deserve a Fixes tag as well? > > No, I don't think so. It's just so that the user (and later, the offloading > driver) doesn't see arbitrarily large values, just a simplifying 0. I guess > it could potentially make a difference to the software taprio data path with > TSO, if the max MTU is comparable with the segment sizes. > > Anyway, with or without the Fixes tag, the patch lands in the same place. I should probably clarify the term "later". Right now, taprio_enable_offload() still passes q->max_sdu[tc] to the offloading driver and not sched->max_sdu[tc], or in other words, it always passes what the user has requested, not the value postprocessed by taprio to take the current speed into consideration.
Powered by blists - more mailing lists