On 2012/05/19 19:09, Loganaden Velvindron wrote: > On Fri, May 18, 2012 at 5:16 AM, Brad Smith <[email protected]> wrote: > > On Mon, May 07, 2012 at 10:24:37AM +0100, Stuart Henderson wrote: > >> On 2012/05/06 21:34, Brad Smith wrote: > >> > I have resurrected the old jumbo allocator to MCLGETI conversion diff > >> > that was reverted with rev 1.152. The commit did not indicate why that > >> > was so. I updated it to -current and have tested it a fair bit on amd64 > >> > with a SysKonnect GEnesis board using jumbos and have not found any > >> > issues > >> > so far. Theo or Stuart can you comment on why this was reverted? > >> > >> Forwarded you some mails offlist, TL;DR version is it dies under heavy > >> packet load. Would be nice to have this back as the jumbo allocator uses > >> a huge wodge of kvm. Not sure if I have a good machine for testing it > >> any more. > > > > Ya, so I've heard but cannot reproduce any issues so far. Also test > > with a Yukon board with multiple ping -f's in both directions. Up to > > 53 jumbo mbuf clusters allocated so far. > > > > > > skc0 at pci1 dev 7 function 0 "Schneider & Koch SK-98xx v2.0" rev 0x20, > > Yukon (0x1): apic 2 int 16 > > sk0 at skc0 port A: address 00:00:5a:9f:31:32 > > eephy0 at sk0 phy 0: 88E1011 Gigabit PHY, rev. 3 > > > > It appears that MCLGETI() is affected by different chipset revisions . > Testing all the revisions is difficult to > do. That's why my MCLGETI diffs still sleep in my local tree :-)
Looking at old dmesg, mine would have been this one, skc0 at pci1 dev 6 function 0 "3Com 3c940" rev 0x10, Yukon (0x1): apic 2 int 3 (irq 3) sk0 at skc0 port A: address 00:0a:5e:1a:a3:00 eephy0 at sk0 phy 0: Marvell 88E1011 Gigabit PHY, rev. 3 Not sure what card gollo@ was using.
