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: Thu, 23 Aug 2007 15:30:47 -0700 (PDT) From: David Miller <davem@...emloft.net> To: hadi@...erus.ca Cc: rick.jones2@...com, krkumar2@...ibm.com, gaagaan@...il.com, general@...ts.openfabrics.org, herbert@...dor.apana.org.au, jagana@...ibm.com, jeff@...zik.org, johnpol@....mipt.ru, kaber@...sh.net, kumarkr@...ux.ibm.com, mcarlson@...adcom.com, mchan@...adcom.com, netdev@...r.kernel.org, peter.p.waskiewicz.jr@...el.com, rdreier@...co.com, Robert.Olsson@...a.slu.se, shemminger@...ux-foundation.org, sri@...ibm.com, tgraf@...g.ch, xma@...ibm.com Subject: Re: [PATCH 0/9 Rev3] Implement batching skb API and support in IPoIB From: jamal <hadi@...erus.ca> Date: Thu, 23 Aug 2007 18:04:10 -0400 > Possibly a bug - but you really should turn off TSO if you are doing > huge interactive transactions (which is fair because there is a clear > demarcation). I don't see how this can matter. TSO only ever does anything if you accumulate more than one MSS worth of data. And when that does happen, all it does is take whats in the send queue and send as much as possible at once. The packets are already built in big chunks, so there is no extra work to do. The card is going to send the things back to back and as fast as in the non-TSO case as well. It doesn't change application scheduling, and it absolutely does not penalize small sends by the application unless we have a bug somewhere. So I see no reason to disable TSO for any reason other than hardware implementation deficiencies. And for the drivers I am familiar with they do make smart default TSO enabling decisions based upon how well the chip does TSO. - 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