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: Wed, 19 Aug 2009 13:19:26 +1000 From: Herbert Xu <herbert@...dor.apana.org.au> To: David Miller <davem@...emloft.net> Cc: rusty@...tcorp.com.au, patrick.ohly@...el.com, netdev@...r.kernel.org, virtualization@...ts.linux-foundation.org, divy@...lsio.com, rolandd@...co.com, xemul@...nvz.org, dcbw@...hat.com, libertas-dev@...ts.infradead.org Subject: Re: [PATCH 1/4] net: skb_orphan on dev_hard_start_xmit On Mon, Aug 17, 2009 at 06:47:12PM -0700, David Miller wrote: > > I'm pretty sure that for normal TCP and UDP workloads, this is just > going to set the interrupt bit on the first packet that gets into the > queue, and then not in the rest. > > TCP just loops over packets in the send queue, and at initial state > the qdisc will be empty. The scheme I actually tried on the e1000e is not quite the same as what I had here. I'm basically just adding descriptors per usual. However, I don't give them to the hardware immediately. Instead they're held back so that on average we have about three descriptors in the queue spaced equally that will cause interrupts. It seems to work fairly well for netperf-generated TCP/UDP traffic in terms of generating the right amount of interrupts (once every qlen/3 packets). I haven't posted anything yet because I ran into a weird problem with the e1000e. It was generating a lot more interrupts than what I'm telling it to do. Even if I hard-code the interrupts at 0, qlen/3, 2qlen/2 I still get way more than qlen/3 interrupts for qlen packets. This may be related to the fact that e1000e doesn't really have a way of turning the interrupts off for a given descriptor. Well actually it does but it also turns off status reporting which means that we will never know whether that entry has finished processing. So I've had to rely on using its TX interrupt delay mechanism as an approximation of turning interrupt notification off. Evidently that is not working in the way I intended it to. I'm in the process of repeating the same experiment with cxgb3 which hopefully should let me turn interrupts off on descriptors while still reporting completion status. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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