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: Wed, 3 Feb 2016 17:36:24 +0000 From: David Laight <David.Laight@...LAB.COM> To: 'Herbert Xu' <herbert@...dor.apana.org.au>, Hannes Frederic Sowa <hannes@...essinduktion.org> CC: Hans Westgaard Ry <hans.westgaard.ry@...cle.com>, "David S. Miller" <davem@...emloft.net>, Alexey Kuznetsov <kuznet@....inr.ac.ru>, James Morris <jmorris@...ei.org>, Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>, "Patrick McHardy" <kaber@...sh.net>, Tom Herbert <tom@...bertland.com>, "Pablo Neira Ayuso" <pablo@...filter.org>, Eric Dumazet <edumazet@...gle.com>, "Florian Westphal" <fw@...len.de>, Jiri Pirko <jiri@...nulli.us>, Alexander Duyck <alexander.h.duyck@...hat.com>, Michal Hocko <mhocko@...e.com>, Linus Lüssing <linus.luessing@...3.blue>, Tejun Heo <tj@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>, Alexey Kodanev <alexey.kodanev@...cle.com>, Håkon Bugge <haakon.bugge@...cle.com>, open list <linux-kernel@...r.kernel.org>, "open list:NETWORKING [GENERAL]" <netdev@...r.kernel.org> Subject: RE: [PATCH v3] net:Add sysctl_max_skb_frags From: Herbert Xu > Sent: 03 February 2016 12:21 > On Wed, Feb 03, 2016 at 12:36:21PM +0100, Hannes Frederic Sowa wrote: > > > > Agreed that it feels like a hack, but a rather simple one. I would > > consider this to be just a performance improvement. We certainly need > > a slow-path when virtio drivers submit gso packets to the stack (and > > already discussed with Hans). The sysctl can't help here. But without > > the sysctl the packets would constantly hit the slow-path in case of > > e.g. IPoIB and that would also be rather bad. > > So you want to penalise every NIC in the system if just one of > them is broken? This is insane. Just do the partial linearisation > in that one driver that needs it and not only won't you have to > penalise anyone else but you still get the best result for that > driver that needs it. > > Besides, you have to implement the linearisation anyway because > of virtualisation. And if a MAC driver needs to linearize a tx frame it might as well copy it into a separately allocated tx buffer area. Indeed it can copy fragments until the number left is less than the fragment limit. David
Powered by blists - more mailing lists