Date: Tue, 11 Dec 2012 08:26:49 -0800 (PST) From: Barney Cordoba <barney_cordoba@yahoo.com> To: freebsd-net@freebsd.org, Karim Fodil-Lemelin <fodillemlinkarim@gmail.com> Cc: nodens2099@gmail.com Subject: Re: igb and ALTQ in 9.1-rc3 Message-ID: <1355243209.48529.YahooMailClassic@web121606.mail.ne1.yahoo.com> In-Reply-To: <50C74990.2090803@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
=0A=0A--- On Tue, 12/11/12, Karim Fodil-Lemelin <fodillemlinkarim@gmail.com= > wrote:=0A=0A> From: Karim Fodil-Lemelin <fodillemlinkarim@gmail.com>=0A> = Subject: Re: igb and ALTQ in 9.1-rc3=0A> To: freebsd-net@freebsd.org=0A> Cc= : nodens2099@gmail.com=0A> Date: Tuesday, December 11, 2012, 9:56 AM=0A> On= 11/12/2012 9:15 AM, Ermal Lu=E7i=0A> wrote:=0A> > On Tue, Dec 11, 2012 at = 2:05 PM, Barney Cordoba <barney_cordoba@yahoo.com>wrote:=0A> >=0A> >>=0A> >= > --- On Tue, 12/11/12, Gleb Smirnoff <glebius@FreeBSD.org>=0A> wrote:=0A> = >>=0A> >>> From: Gleb Smirnoff <glebius@FreeBSD.org>=0A> >>> Subject: Re: i= gb and ALTQ in 9.1-rc3=0A> >>> To: "Jack Vogel" <jfvogel@gmail.com>=0A> >>>= Cc: "Clement Hermann (nodens)" <nodens2099@gmail.com>,=0A> "Barney Cordoba= "=0A> >> <barney_cordoba@yahoo.com>,=0A> freebsd-net@FreeBSD.org=0A> >>> Da= te: Tuesday, December 11, 2012, 2:58 AM=0A> >>> On Mon, Dec 10, 2012 at 03:= 31:19PM=0A> >>> -0800, Jack Vogel wrote:=0A> >>> J> UH, maybe asking the ow= ner of the driver=0A> would help=0A> >>> :)=0A> >>> J>=0A> >>> J> ... and n= o, I've never been aware of=0A> doing anything to=0A> >>> stop supporting a= ltq=0A> >>> J> so you wouldn't see any commits. If=0A> there's something=0A= > >>> in the altq code or=0A> >>> J> support (which I have nothing to do wi= th)=0A> that caused=0A> >>> this no-one informed=0A> >>> J> me.=0A> >>>=0A>= >>> Switching from if_start to if_transmit=0A> effectively disables=0A> >>= > ALTQ support.=0A> >>>=0A> >>> AFAIR, there is some magic implemented in o= ther=0A> drivers that=0A> >>> makes them=0A> >>> modern (that means using i= f_transmit), but=0A> still capable to=0A> >>> switch to queueing=0A> >>> mo= de if SIOCADDALTQ was casted upon them.=0A> >>>=0A> >> It seems pretty diff= icult to say that something is=0A> compatible with=0A> >> something else if= it hasn't been tested in a few=0A> years.=0A> >>=0A> >> It seems to me tha= t ATLQ is the one that should=0A> handle if_transmit.=0A> >> although it's = a good argument for having a raw=0A> "send" function in=0A> >> drivers. Eth= ernet drivers don't need more than a=0A> send() routing that=0A> >> loads a= packet into the ring. The decision on what=0A> to do if you can't=0A> >> q= ueue a packet should be in the=A0 network=0A> layer, if we must still call= =0A> >> things layers.=0A> >>=0A> >> "start" is a leftover from a day when = you stuffed a=0A> buffer and waited=0A> >> for an interrupt to stuff in ano= ther. The whole=0A> idea is antiquated.=0A> >>=0A> >> Imagine drivers that = pull packets off of a card and=0A> simply queue it;=0A> >> and that you sim= ply submit a packet to be queued=0A> for transmit. Instead=0A> >> of trying= to find 35 programmers that understand=0A> all of the lock BS,=0A> >> you = only need to have a couple.=0A> >>=0A> >> I always disable all of the gobbl= edegook like=0A> checksum offloading. They=0A> >> just muddy the water and = have very little effect on=0A> performance. A modern=0A> >> cpu can do a ch= ecksum as fast as you can manage the=0A> "capabilities" without=0A> >> disr= upting the processing path.=0A> >>=0A> >> With FreeBSD, every driver is an = experience. Some=0A> suck so bad that they=0A> >> should come with a warnin= g. The MSK driver is=0A> completely useless, as=0A> >> an example.=0A> >>= =0A> >>=0A> >> BC=0A> >> _______________________________________________=0A= > >> freebsd-net@freebsd.org=0A> mailing list=0A> >> http://lists.freebsd.o= rg/mailman/listinfo/freebsd-net=0A> >> To unsubscribe, send any mail to "fr= eebsd-net-unsubscribe@freebsd.org"=0A> >>=0A> > During implementation of if= _transmit altq was not=0A> considered at all.=0A> > The default if_transmit= provides some compatibility but=0A> that is void since=0A> > altq has not = been converted to call if_transmit after=0A> processing the mbuf.=0A> >=0A>= > ALTQ can be adapted quite easily to if_transmit model=0A> it just wasn't= done=0A> > at the time.=0A> > With if_transmit model it can even be modula= rized and=0A> not be a compile=0A> > kernel option since the queue of the i= face is=0A> abstracted now.=0A> >=0A> > I have always wanted to do a diff b= ut have not yet got=0A> to it.=0A> > The change is quite simple just provid= e an=0A> altq_transmit default method and=0A> > just hook into if_transmit = model on the fly.=0A> > You surely need to handle some iface events and ena= ble=0A> altq based on=0A> > request but its is not a hard to implement.=0A>= >=0A> > I will always have this in my TODO but not sure when i=0A> can get= to it.=0A> >=0A> The issue is not only that igb doesn't support if_transmi= t=0A> or if_start =0A> method but that ALTQ isn't multiqueue ready and stil= l uses=0A> the IFQ_LOCK =0A> for all of its enqueue/dequeue operations. A s= imple drop in=0A> of =0A> if_transmit is bound to cause race conditions on = any=0A> multiqueue driver =0A> with ALTQ.=0A> =0A> I do have a patch set fo= r this on igb but its ugly and needs=0A> more work =0A> although it should = get you going. Let me know if your=0A> interested I will =0A> clean it up a= nd send it over. For more information on ALTQ=0A> discussion =0A> and igb p= lease read this thread: =0A> http://freebsd.1045724.n5.nabble.com/em-igb-if= -transmit-drbr-and-ALTQ-td5760338.html=0A> =0A> Best regards,=0A> =0A> Kari= m.=0A=0AAt minimum, the drivers should make multiqueue an option, at least= =0Auntil it works better than a single queue driver. Many MOBOs have igb=0A= nics on board and such a mainstream NIC shouldn't be strapped using=0Aexper= imental code that clearly isn't ready for prime time.=0A=0ABC=0A
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1355243209.48529.YahooMailClassic>