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: Tue, 30 Sep 2014 21:44:50 -0700 From: Tom Herbert <therbert@...gle.com> To: Jesper Dangaard Brouer <brouer@...hat.com> Cc: Eric Dumazet <eric.dumazet@...il.com>, Florian Westphal <fw@...len.de>, Linux Netdev List <netdev@...r.kernel.org>, "David S. Miller" <davem@...emloft.net>, Hannes Frederic Sowa <hannes@...essinduktion.org>, Daniel Borkmann <dborkman@...hat.com>, Jamal Hadi Salim <jhs@...atatu.com>, Alexander Duyck <alexander.duyck@...il.com>, John Fastabend <john.r.fastabend@...el.com>, Dave Taht <dave.taht@...il.com>, Toke Høiland-Jørgensen <toke@...e.dk> Subject: Re: [net-next PATCH] dql: add a burst attribute On Tue, Sep 30, 2014 at 2:46 PM, Jesper Dangaard Brouer <brouer@...hat.com> wrote: > > On Tue, 30 Sep 2014 07:55:36 -0700 > Eric Dumazet <eric.dumazet@...il.com> wrote: > > > On Tue, 2014-09-30 at 16:31 +0200, Florian Westphal wrote: > > > Eric Dumazet <eric.dumazet@...il.com> wrote: > > > > If you feel not comfortable with "burst", rename it to whatever you > > > > think is best. > > > > But please, do not hard code magic 7 in your code. > > > > > > I had hoped that this 'magic' value could be removed > > > completely, only using bql data for bulking decisions. > > > > But it is apparently not the case, since you guys decided to had it set > > to 8, then to 7 later, based on experiments. > > The "magic" limit is only a conservative save guard. We do plan to > remove this completely. That is the reason for not exporting this, as > we want free-hands to remove this completely. > > Guess, I'll remove it completely now, so we can move on. > > > I would like some off/on switch, exported to userspace, for disabling > this bulking (then we don't need this conservative magic number). How > would that be done best? I'd suggest to keep the packet limit as an unsigned. Default value is infinity (-1UL), 0 turns it off, and other values are available if someone really wants to tune this (for example, if BQL is disabled-- BQL limit is infinity). Export this as sys variable for the TX queue. Tom > > > -- > Best regards, > Jesper Dangaard Brouer > MSc.CS, Sr. Network Kernel Developer at Red Hat > Author of http://www.iptv-analyzer.org > LinkedIn: http://www.linkedin.com/in/brouer -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists