Messages in this thread | | | Date | Sat, 09 Jan 2010 13:34:20 -0500 | From | Michael Breuer <> | Subject | Re: [PATCH] af_packet: Don't use skb after dev_queue_xmit() |
| |
On 1/9/2010 7:28 AM, Jarek Poplawski wrote: > On Fri, Jan 08, 2010 at 11:45:35PM -0500, Michael Breuer wrote: > >> On 1/8/2010 4:48 PM, Michael Breuer wrote: >> >>> On 1/8/2010 4:29 PM, Jarek Poplawski wrote: >>> ... >>> >>>> BTW, don't hurry with that yet, but in the next test, please try >>>> alternative 2 again (i.e. with MMAP + no DMAR + disable_msi). >>>> >>>> >>> Will do - still up from yesterday... no more dropped packets... >>> none of the dns errors either. To be expected I suppose as long as >>> I'm trying to sniff it. Assuming no immediate erorrs with alt2, no >>> DMAR + disable_msi I'll report back after it's been up for a >>> while. >>> -- >>> >> Ok - ran alt1 and alt2, both with MMAP, no DMAR and disable_msi. >> Both seem to behave similarly. No logged errors; >> > Ok - since alt2 introduces less changes and is acked by Stephen > already, I'll resend it with your "Tested-by" in a new thread to clear > things a bit. > > Ok - good, and thank you for all your help. >> large numbers of dropped RX packets. >> > You might try some tweaking with another sky2 parameter "copybreak" > or even editing its "NAPI_WEIGHT" variable. > > I'll play around with this after I figure out what's actually being dropped and why. Looking at ethtool, over 99% of RX packets are in the >=1024 bucket. I'll play with weight and perhaps rmem as time permits. >> One odd thing: when driving every sort of >> traffic through, I was able to hose the client adapter (win7) >> repeatedly by runnnig the win7 backup and connecting Windows Media >> Player to a Mediatomb stream while also running a remote X11 >> session. Looks like the SSDP traffic that occurs at the same time as >> the SMB traffic and X11 traffic takes out the adapter on Win7 - >> Nforce. >> Reran with msi enabled, MMAP and no DMAR. Also no errors; much >> faster, and the Win7 side survives the same conditions that don't >> work when msi is disabled. Doesn't make sense to me, but it is what >> it is. >> >> Going to leave this up for a while and see if things remain functional. >> > It looks like DMAR is the main candidate for a new linux-kernel@ or > bugzilla bug report. You should also consider reporting these ipv6 > problems, especially if you think they can trigger TX timeouts. (In > both cases it would be good to try current mainline first, when you > get it workable.) > Ok - I'll get onto mainline and then deal with DMAR. > Thanks, > Jarek P. >
| |