On Wed, 2005-07-12 at 13:47 -0800, John Ronciak wrote: > On 12/7/05, David S. Miller <[EMAIL PROTECTED]> wrote: > > > Regardless of the decision, it's incorrect to point out e1000 > > specifically as many other Linux networking drivers do copybreak too > > and I've always public advocated for copybreak to be used by drivers > > due to the socket buffering issue. Whatever we decide here about > > copybreak, we should apply consistently across all drivers and my vote > > is on by default with an ethtool switch folks can use to tweak this. > > I can even do the tg3 bits :-) > > > I agree completely. For a simple test to show this, try to flood an > interface with small UDP packets. Do this with and without copybreak > and look at how many more packets get dropped when copybreak is not > used. This was why we added it in the first place. >
ok, sorry this stuck in my mind and i had to go back and find this email. What Dave explained in terms of accounting makes sense - and there could be a relationship with what you are saying with UDP. or maybe not ;-> heres why: Many many moons ago when i was hitting a box with UDP i saw that the socket code just couldnt keep up. I was able to show that if you can feedback all the way to the driver, we could infact get better results. This was in the days of the tulip. So the question is: - is it because you are slowing the code path down by the copies that you are doing or is it because the accounting issues? ;-> what does netstat -s show in both cases of with and without copybreak? My experience at the time was the socket code just couldnt keep up. Now the reason maybe because of the accounting issue the code cant keep up. I am tempted to go back and retest this. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
