Date: Thu, 14 Aug 2008 01:02:31 -0400 From: Paul <paul@gtcomm.net> To: Jack Vogel <jfvogel@gmail.com> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: HEADS UP: E1000 networking changes in STABLE/7.1 RELEASE Message-ID: <48A3BC67.3050905@gtcomm.net> In-Reply-To: <2a41acea0808132135oe9ebc6bk9423ac19f2e9f77a@mail.gmail.com> References: <2a41acea0808131502y39879a22u39c472bd0b810fc2@mail.gmail.com> <48A3A2DA.8030404@gtcomm.net> <2a41acea0808132135oe9ebc6bk9423ac19f2e9f77a@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
The hardware spec sheet says it does support multi queue but only MSI, so I would suspect it is disabled by default since that would (maybe) cause performance to be less. Would it take advantage of multiple cpus to turn on the multiple queues even without MSIX? (i.e. having more than 1 taskq in freebsd per interface for receives/sends) It should still do per-vector masking so it couldn't be THAT bad with the multi queues enabled but there's probably a good reason why they are disabled by default eh? Would be fun to test it out though :> :> I think even if the driver / bsd split it up into multiple taskq's so it would take advantage of SMP better that it would work, but that might require some modifications outside of the driver level (which I can think of a lot) but I guess i"m hoping for an easier solution so I don't have to go replacing all these 82571EB cards.. They work great, but the cpus are running out.. Having 3 or 4 idle cpus while the other ones are struggling due to network load and dropping packets is aggravating :) Will the 82575/6 cards alleviate that problem or will I still be faced with the same issue (due to os limitations)? I plan on buying the dual port ET controller[82576] (which was supoosed to be shipping last month) but I can't find one anywhere! argh.. Thanks Paul Jack Vogel wrote: > On Wed, Aug 13, 2008 at 8:13 PM, Paul <paul@gtcomm.net> wrote: > >> Hi Jack. Will the em driver ever support the multiple hardware queues of >> the 82571 or are we just stuck with the standard em driver? >> Has there been any significant change in the em driver itself ? >> I have a feeling that the 82571 should be in the igb driver but for some >> reason it isn't. I am curious because we have a LOT of 4 port 82571 PCI-E >> cards and they are not cheap. :] >> > > Hey Paul, > > You are right, quad port cards aren't cheap, Intel has sold them > even back in a > PCI-X based system. And the one you are talking about was released since I > have been in this job, so pretty new :) However, they will never > support multiple > queues, the reason being that in order to do this you need multple MSI vectors, > in other words, MSIX. Still, they are very handy, they do support MSI, but just > one per interface. Oh, and I debated about where to make the cutoff line on the > em/igb split and decided the best thing to do was to follow Linux. The biggest > difference between the two drivers is that those in the igb use a > different descriptor > format, called 'advanced descriptors'. > > The split does NOT mean that em is now fixed. Quite the contrary, > the em driver > that was just MFC'd into STABLE has support for what I think is going to be the > coolest new consumer adapter out there, called 82574, code name Hartwell, and > also for ICH10. Both these two new interfaces have IEEE 1588 Precision Time > Protocol support, something that is becoming important for networked multimedia > applications. Oh, and Hartwell is the first adapter in the em driver > that actually > does multiqueue, although in a limited fashion, it does MSIX. This > adapter is made > at a lower cost point, but it has really nice features. I only wish > the new motherboard > that I bought had them rather than ICH9 but oh well :) I predict they > are going to > be selling like hotcakes before the end of year. > > I will continue to share fixes between the em and igb drivers as they > are applicable. > I still think a real legacy driver for the oldest adapters would be a > good idea, just so > they don't get broken by new development, with as many as we support regression > testing is already not being done adequately. I just have not had time > to think about > this yet, it may be coming, it would probably be for everything that > was not PCI Express. > > Hope the info was helpful, I'm always happy to answer questions, > > Jack > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48A3BC67.3050905>