From owner-freebsd-net@FreeBSD.ORG Sun Mar 31 12:13:42 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CE940C40 for ; Sun, 31 Mar 2013 12:13:42 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm35-vm3.bullet.mail.ne1.yahoo.com (nm35-vm3.bullet.mail.ne1.yahoo.com [98.138.229.99]) by mx1.freebsd.org (Postfix) with ESMTP id 8CCDDA0D for ; Sun, 31 Mar 2013 12:13:42 +0000 (UTC) Received: from [98.138.90.49] by nm35.bullet.mail.ne1.yahoo.com with NNFMP; 31 Mar 2013 12:11:57 -0000 Received: from [98.138.89.166] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 31 Mar 2013 12:11:57 -0000 Received: from [127.0.0.1] by omp1022.mail.ne1.yahoo.com with NNFMP; 31 Mar 2013 12:11:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 614944.77444.bm@omp1022.mail.ne1.yahoo.com Received: (qmail 69359 invoked by uid 60001); 31 Mar 2013 12:11:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1364731917; bh=Y7d0hfAXweG9rRrmo89pmHD0LGfbObOjZ+OefRyffAQ=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=VNZb9Hgcd/L/alfW3c6S5n8JjceANO8HMSa/diSP9Y59bUbGOD+Y7MbufXuHJFMrtwIiU1WVK/UGLQVyTIDLRTE3ZP/xH7A14wCE2+/LFvdaeqESkd1+X5uIBNhJbZIZ5OVZswy6GIXdMUTgneOrwbUh2uIa3b7K+s6HKReiymU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mD/8gKJqlwFbM77G87kaYg3zKDKjymgeFnXEKHO4g2xO2qJ8nz9P891tySyp2hvRM4UJbElGZ/TO+oJxHL2jHNYCugN860HLJIcA2T72Tb+kNcjfq3IjUdaaB9N8wniURFazVSpaXcWUBso+dQlSVX7/ScrmjBCDwm3WAH++nhY=; X-YMail-OSG: K3qwftsVM1mtyMw1CGYAEeZ1k1JtuFwM1vvg6kgKJQpjd2V HFQCX2Jv8K_ph0oLpSU.J3e7vmkZTbfQX1IYmQ2h6MPqlvj1ZL_jBpXgzqpT iLi_Ur7A5oVYlM_E13A3jqXaSBc1IcPCISdz5JmAmWWRG9JBccBuzr9FQ_CN DEsceCbhJHEEzdEfjl6sb.8KBbC9NnXRf0tFRT73GwbFQrUHJXGMph.Rn_5c 8ZeNBrv5C.bhZzE3QGkroCgegCIF5YDiSPHyBAjD0QjnmPlDcet8dZZAXQ7. 4ySLTAqrDfIZ7WGdEwjsM.ZsPXH9lLngDVXt1NXW6JZskJiFOAA6I5mzDcUK dgiPkj4ra686Ah1LmATmnTNlr7_1lnTOuhitj39WyPNQ1dUKOuMC3BveXcAP ysLERVyq9Fop0OdH9Xz.F5rnmr8JS7s3ggaMv9nRUHanp_yOyoBob6RAKpfY qgvFQbq8XhmzlXpPMkZ7KgT7Lkb1GufoFSJdg5fOZYub3kMA.ZK6VnWpvflx t8ojbtaX1tZ3EwjXVDxdZHr5z_JZxrg-- Received: from [98.203.118.124] by web121603.mail.ne1.yahoo.com via HTTP; Sun, 31 Mar 2013 05:11:57 PDT X-Rocket-MIMEInfo: 002.001, RG8geW91IGtub3cgYW55dGhpbmcgYWJvdXQgdGhlIHN1YmplY3QsIFNjb3R0PyBJJ2QgYmUgaW50ZXJlc3RlZCBpbiBzZWVpbmcgeW91ciBiZW5jaG1hcmtzIHdpdGggdmFyaW91cyBxdWV1ZSBjb3VudHMsIGJpbmRpbmcgdG8gY3B1cyB2cyBub3QgYmluZGluZywgYW5kIHRoZSBudW1iZXJzIGNvbXBhcmluZyB0aGUgcHJlIG11bHRpcXVldWUgZHJpdmVyIHRvIHRoZSBjdXJyZW50IG9uZS4gSXQncyB0aGUgbWluaW11bSB0aGF0IGFueSBtYXJnaW5hbGx5IGNvbXBldGVudCBuZXR3b3JrIGRyaXZlciBkZXZlbG8BMAEBAQE- X-Mailer: YahooMailClassic/15.1.7 YahooMailWebService/0.8.139.530 Message-ID: <1364731917.68949.YahooMailClassic@web121603.mail.ne1.yahoo.com> Date: Sun, 31 Mar 2013 05:11:57 -0700 (PDT) From: Barney Cordoba Subject: Re: igb and ALTQ in 9.1-rc3 To: Scott Long In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Nick Rogers , Adrian Chadd , Jeffrey EPieper , "freebsd-net@freebsd.org" , "Clement Hermann \(nodens\)" , Jack Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 12:13:42 -0000 Do you know anything about the subject, Scott? I'd be interested in seeing = your benchmarks with various queue counts, binding to cpus vs not binding, = and the numbers comparing the pre multiqueue driver to the current one. It'= s the minimum that any marginally competent network driver developer would = do.=0A=0AOr are you just hurling insults because you're devoid of actual id= eas?=0A=0ABC=0A=0A=0A--- On Fri, 3/29/13, Scott Long = wrote:=0A=0A> From: Scott Long =0A> Subject: Re: igb= and ALTQ in 9.1-rc3=0A> To: "Barney Cordoba" =0A= > Cc: "Nick Rogers" , "Adrian Chadd" , "Jeffrey EPieper" , "freebsd-net@freebsd.or= g" , "Clement Hermann (nodens)" , "Jack Vogel" =0A> Date: Friday, March 29, 2013, 12= :42 PM=0A> Comedy gold.=A0 It's been a while=0A> since I've seen this much = idiocy from you, Barney.=A0=0A> Hopefully the rest of the mailing list will= blackhole you,=0A> as I'm about to, and we can all get back to real work.= =0A> =0A> Scott=0A> =0A> =0A> =0A> On Mar 29, 2013, at 10:38 AM, Barney Cor= doba =0A> wrote:=0A> =0A> > it needs a lot more t= han a patch. It needs to be=0A> completely re-thunk=0A> > =0A> > --- On Fri= , 3/29/13, Adrian Chadd =0A> wrote:=0A> > =0A> > From: = Adrian Chadd =0A> > Subject: Re: igb and ALTQ in 9.1-rc= 3=0A> > To: "Barney Cordoba" =0A> > Cc: "Jack Vog= el" ,=0A> "Nick Rogers" ,=0A> "Jeffr= ey EPieper" ,=0A> "freebsd-net@freebsd.org"=0A>= ,=0A> "Clement Hermann (nodens)" =0A> > Date: Friday, March 29, 2013, 12:07 PM=0A> > =0A> > Barney,=0A= > > Patches gratefully accepted.=0A> > =0A> > =0A> > =0A> > Adrian=0A> > = =0A> > =0A> > =0A> > On 29 March 2013 08:54, Barney Cordoba =0A> wrote:=0A> > =0A> > =0A> > =0A> > =0A> > =0A> > --- On Fri,= 3/29/13, Pieper, Jeffrey E =0A> wrote:=0A> > = =0A> > =0A> > =0A> >> From: Pieper, Jeffrey E = =0A> > =0A> >> Subject: RE: igb and ALTQ in 9.1-rc3=0A> > =0A> >> To: "Barn= ey Cordoba" ,=0A> "Jack Vogel" ,=0A> "Nick Rogers" =0A> > =0A> > =0A> >> Cc: "freebsd= -net@freebsd.org"=0A> ,=0A> "Clement Hermann (node= ns)" =0A> > =0A> > =0A> >> Date: Friday, March 29, 20= 13, 11:45 AM=0A> > =0A> >> =0A> > =0A> >> =0A> > =0A> >> -----Original Mess= age-----=0A> > =0A> >> From: owner-freebsd-net@freebsd.org=0A> > =0A> >> [m= ailto:owner-freebsd-net@freebsd.org]=0A> > =0A> >> On Behalf Of Barney Cord= oba=0A> > =0A> >> Sent: Friday, March 29, 2013 5:51 AM=0A> > =0A> >> To: Ja= ck Vogel; Nick Rogers=0A> > =0A> >> Cc: freebsd-net@freebsd.org;=0A> > =0A>= >> Clement Hermann (nodens)=0A> > =0A> >> Subject: Re: igb and ALTQ in 9.1= -rc3=0A> > =0A> >> =0A> > =0A> >> =0A> > =0A> >> =0A> > =0A> >> --- On Thu,= 3/28/13, Nick Rogers =0A> > =0A> >> wrote:=0A> > =0A> = >> =0A> > =0A> >>> From: Nick Rogers =0A> > =0A> >>> Su= bject: Re: igb and ALTQ in 9.1-rc3=0A> > =0A> >>> To: "Jack Vogel" =0A> > =0A> >>> Cc: "Barney Cordoba" ,= =0A> > =0A> >> "Clement Hermann (nodens)" ,=0A> > =0A= > >> "freebsd-net@freebsd.org"=0A> > =0A> >> =0A> = > =0A> >>> Date: Thursday, March 28, 2013, 9:29 PM=0A> > =0A> >>> On Thu, M= ar 28, 2013 at 4:16 PM, Jack=0A> > =0A> >>> Vogel =0A> >= =0A> >>> wrote:=0A> > =0A> >>>> Have been kept fairly busy with other=0A> = matters,=0A> > =0A> >> one=0A> > =0A> >>> thing I could do short=0A> > =0A>= >>>> term is=0A> > =0A> >>>> change the defines in igb the way I did in=0A= > the em=0A> > =0A> >>> driver so you could still=0A> > =0A> >>>> define=0A= > > =0A> >>>> the older if_start entry. Right now those=0A> are=0A> > =0A> = >> based on=0A> > =0A> >>> OS version and so you=0A> > =0A> >>>> will=0A> >= =0A> >>>> automatically get if_transmit, but I could=0A> change=0A> > =0A>= >> it to=0A> > =0A> >>> be IGB_LEGACY_TX or=0A> > =0A> >>>> so,=0A> > =0A>= >>>> and that could be defined in the Makefile.=0A> > =0A> >>>> =0A> > =0A= > >>>> Would this help?=0A> > =0A> >>> =0A> > =0A> >>> I'm currently using = ALTQ successfully with the=0A> em=0A> > =0A> >> driver, so=0A> > =0A> >>> i= f igb=0A> > =0A> >>> behaved the same with respect to using if_start=0A> in= stead=0A> > =0A> >> of=0A> > =0A> >>> if_transmit=0A> > =0A> >>> when ALTQ = is in play, that would be great. I do=0A> not=0A> > =0A> >>> completely=0A>= > =0A> >>> understand the change you propose as I am not=0A> very=0A> > = =0A> >> familiar=0A> > =0A> >>> with the=0A> > =0A> >>> driver internals. A= ny kind of patch or extra=0A> > =0A> >>> Makefile/make.conf=0A> > =0A> >>> = definition that would allow me to build a=0A> 9-STABLE=0A> > =0A> >> kernel= =0A> > =0A> >>> with an igb=0A> > =0A> >>> driver that works again with ALT= Q, ASAP, would=0A> be much=0A> > =0A> >>> appreciated.=0A> > =0A> >>> =0A> = > =0A> >>>> =0A> > =0A> >>>> Jack=0A> > =0A> >>>> =0A> > =0A> >>>> =0A> > = =0A> >>>> =0A> > =0A> >>>> On Thu, Mar 28, 2013 at 2:31 PM, Nick=0A> Rogers= =0A> > =0A> >> =0A> > =0A> >>> wrote:=0A> > =0A> >>>>> = =0A> > =0A> >>>>> On Tue, Dec 11, 2012 at 1:09 AM, Jack=0A> Vogel=0A> > =0A= > >> =0A> > =0A> >>> wrote:=0A> > =0A> >>>>>> On Mon, De= c 10, 2012 at 11:58 PM,=0A> Gleb=0A> > =0A> >>> Smirnoff =0A> > =0A> >>>>>> wrote:=0A> > =0A> >>>>>> =0A> > =0A> >>>>>>> On Mon, = Dec 10, 2012 at=0A> 03:31:19PM=0A> > =0A> >> -0800,=0A> > =0A> >>> Jack Vog= el wrote:=0A> > =0A> >>>>>>> J> UH, maybe asking the=0A> owner of=0A> > =0A= > >> the=0A> > =0A> >>> driver would help :)=0A> > =0A> >>>>>>> J>=0A> > = =0A> >>>>>>> J> ... and no, I've never=0A> been=0A> > =0A> >> aware of=0A> = > =0A> >>> doing anything to stop=0A> > =0A> >>>>>>> supporting=0A> > =0A> = >>>>>>> altq=0A> > =0A> >>>>>>> J> so you wouldn't see any=0A> > =0A> >> co= mmits. If=0A> > =0A> >>> there's something in the altq=0A> > =0A> >>>>>>> c= ode=0A> > =0A> >>>>>>> or=0A> > =0A> >>>>>>> J> support (which I have=0A> n= othing=0A> > =0A> >> to do=0A> > =0A> >>> with) that caused this no-one=0A>= > =0A> >>>>>>> informed=0A> > =0A> >>>>>>> J> me.=0A> > =0A> >>>>>>> =0A> = > =0A> >>>>>>> Switching from if_start to=0A> > =0A> >> if_transmit=0A> > = =0A> >>> effectively disables ALTQ=0A> > =0A> >>>>>>> support.=0A> > =0A> >= >>>>>> =0A> > =0A> >>>>>>> AFAIR, there is some magic=0A> > =0A> >> impleme= nted in=0A> > =0A> >>> other drivers that makes them=0A> > =0A> >>>>>>> mod= ern (that means using=0A> > =0A> >> if_transmit), but=0A> > =0A> >>> still = capable to switch to=0A> > =0A> >>>>>>> queueing=0A> > =0A> >>>>>>> mode if= SIOCADDALTQ was casted=0A> upon=0A> > =0A> >> them.=0A> > =0A> >>>>>>> =0A= > > =0A> >>>>>>> =0A> > =0A> >>>>>> Oh, hmmm, I'll look into the matter=0A>= after=0A> > =0A> >> my=0A> > =0A> >>> vacation.=0A> > =0A> >>>>>> =0A> > = =0A> >>>>>> Jack=0A> > =0A> >>>>> =0A> > =0A> >>>>> Has there been any prog= ress on=0A> resolving this=0A> > =0A> >>> issue? I recently ran=0A> > =0A> = >>>>> into this problem upgrading my servers=0A> from=0A> > =0A> >> 8.3 to= =0A> > =0A> >>> 9.1-RELEASE and am=0A> > =0A> >>>>> wondering what the late= st=0A> recommendation is.=0A> > =0A> >> I've=0A> > =0A> >>> used ALTQ and i= gb=0A> > =0A> >>>>> successfully for years and it is=0A> unfortunate=0A> > = =0A> >> it no=0A> > =0A> >>> longer works.=0A> > =0A> >>>>> Appreciate any = advice.=0A> > =0A> >>>>> =0A> > =0A> >>> =0A> > =0A> >>> Do yourself a favo= r and either get a cheap dual=0A> port=0A> > =0A> >> 82571 card or=0A> > = =0A> >>> 2 cards and disable the IGB ports. The igb=0A> driver is=0A> > =0A= > >> defective, and until=0A> > =0A> >>> they back out the new, untested mu= lti-queue=0A> stuff you're=0A> > =0A> >> just neutering=0A> > =0A> >>> your= system trying to use it.=0A> > =0A> >>> =0A> > =0A> >>> Frankly this proje= ct made a huge mistake by=0A> moving=0A> > =0A> >> forward with multi=0A> >= =0A> >>> queue just for the sake of saying that you=0A> support it;=0A> > = =0A> >> without having=0A> > =0A> >>> any credible plan for implementing it= . That=0A> nonsense=0A> > =0A> >> that Bill Macy did=0A> > =0A> >>> should = have been tarballed up and deposited in=0A> the trash=0A> > =0A> >> folder.= The=0A> > =0A> >>> biggest mess in programming history.=0A> > =0A> >>> =0A= > > =0A> >>> That being said, the solution is not to hack=0A> the igb=0A> >= =0A> >> driver; its to make=0A> > =0A> >>> ALTQ if_transmit compatible, wh= ich shouldn't be=0A> all that=0A> > =0A> >> difficult.=0A> > =0A> >>> =0A> = > =0A> >>> BC=0A> > =0A> >> =0A> > =0A> >> I may be misunderstanding what y= ou are saying, but=0A> if the=0A> > =0A> >> solution is, as you say "not to= hack the igb=0A> driver", then=0A> > =0A> >> how is it defective in this c= ase? Or are you just=0A> directing=0A> > =0A> >> vitriol toward Intel? Mult= i-queue is working fine=0A> in igb.=0A> > =0A> >> =0A> > =0A> >> Jeff=0A> >= =0A> > =0A> > =0A> > It's defective because it's been poorly implemented a= nd=0A> has more bugs=0A> > =0A> > than a Manhattan hotel bed. Adding queues= without a=0A> proper plan just add=0A> > =0A> > more lock contention. It's= not a production-ready=0A> driver.=0A> > =0A> > =0A> > =0A> > As Jack once= said, Intel doesn't care about=0A> performance, they're just=0A> > =0A> > = example drivers. igb is an example of how not to do=0A> things.=0A> > =0A> = > =0A> > =0A> > BC=0A> > =0A> > ___________________________________________= ____=0A> > =0A> > freebsd-net@freebsd.org=0A> mailing list=0A> > =0A> > htt= p://lists.freebsd.org/mailman/listinfo/freebsd-net=0A> > =0A> > To unsubscr= ibe, send any mail to "freebsd-net-unsubscribe@freebsd.org"=0A> > =0A> > = =0A> > =0A> > _______________________________________________=0A> > freebsd= -net@freebsd.org=0A> mailing list=0A> > http://lists.freebsd.org/mailman/li= stinfo/freebsd-net=0A> > To unsubscribe, send any mail to "freebsd-net-unsu= bscribe@freebsd.org"=0A> =0A> _____________________________________________= __=0A> freebsd-net@freebsd.org=0A> mailing list=0A> http://lists.freebsd.or= g/mailman/listinfo/freebsd-net=0A> To unsubscribe, send any mail to "freebs= d-net-unsubscribe@freebsd.org"=0A> From owner-freebsd-net@FreeBSD.ORG Sun Mar 31 12:38:08 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1C3449D for ; Sun, 31 Mar 2013 12:38:08 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm38-vm5.bullet.mail.ne1.yahoo.com (nm38-vm5.bullet.mail.ne1.yahoo.com [98.138.229.149]) by mx1.freebsd.org (Postfix) with ESMTP id D01AEADC for ; Sun, 31 Mar 2013 12:38:07 +0000 (UTC) Received: from [98.138.90.50] by nm38.bullet.mail.ne1.yahoo.com with NNFMP; 31 Mar 2013 12:35:15 -0000 Received: from [98.138.226.168] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 31 Mar 2013 12:35:15 -0000 Received: from [127.0.0.1] by omp1069.mail.ne1.yahoo.com with NNFMP; 31 Mar 2013 12:35:15 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 27507.22300.bm@omp1069.mail.ne1.yahoo.com Received: (qmail 85602 invoked by uid 60001); 31 Mar 2013 12:35:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1364733314; bh=sDnans9PjaboivVVcfo3P8yOjD+WhaiXPVljNEGG6Sc=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=MoRj/Fkhv7ox+smoue6evQeIinw67IXMxeP0PjIRyUO+YRifk0nXMGKu+t2XJzokDO5isvwzhiPo4rGIWNEd6AKlcPnJQM1Y1QwU2hnlVuNYm9dTtXcU6YqAZz3gnxnWfZtZ+On12uJLXqfuGZzqCe6+oOpgb2JbM0Bfo3nlcZY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=HiMXtbiK5cNJAJb3K3PtIonackQgXoWN1tijrZFBdLAjXInczmB3GWXGdxTU5JvrhXgSZJNbQKWICzbUmc+7a/2TrfGyedAoKnLFDFOc1bgaJ+JS9bR6FSL3buYxSM1nERcdOi0UX+PWVZPEpaWzHzteQJkINQkLmxw8+O7txyE=; X-YMail-OSG: qZT219YVM1np76NGei94Bba0c6fWajFQhDSIlX.JOQ99rh4 dc2g_lkpDBSXc5gu3Sa4vJsEveEhHowy_abahrt2VVk8pljjWtgt1Rawn2Nk AW5dzBJe4RvHayBlBxboZZJoXeaUYsT4EAWaES6zGWwaBTsegI_MMxbxsr6q 3jGBgTqu.earWNa.plVOeet.84RHcVbfmHRgQpK2zjltb0xu_sG780O9v3KJ 5zgYqfw.6axM_rmp4FZubE2qUhB0DFZMNOcteRpAqw9ipu297zjdQqnHdlUh Iy8cY0izCF03AUez0_58p1A.h7_fdUicpJ4YliO60algzcSEQwwUTSFw4psl eQDLRsENurxhX0VMbINPTxgNyXW6vUylu7XF250dlhdw43Hu3m6.LpmWQrQH x8APjpAsSmqLrXxFCHZZezqqE6hMqNfuh3aDdFmg9Rm_.q79V4B8xoQMtNPy g4g_lh1YR_w6xFFJj_jNcd3C2j62YEzlt_84Fzm.iNYHjon4AIml6a0cj7lm irmZgne6hVcZpPCT_kq0os9ePGSdn3w-- Received: from [98.203.118.124] by web121603.mail.ne1.yahoo.com via HTTP; Sun, 31 Mar 2013 05:35:14 PDT X-Rocket-MIMEInfo: 002.001, VGhlIHJlYXNvbiB0aGF0IEphY2sgaXMgYSBubyBiZXR0ZXIgcHJvZ3JhbW1lciBub3cgdGhhbiBoZSB3YXMgaW4gMjAwOSBtaWdodCBoYXZlwqBzb21ldGhpbmcgdG8gZG8gd2l0aCB0aGUgZmFjdCB0aGF0IGhlIGhpZGVzIHdoZW4gaGlzIHdvcmsgaXMgY3JpdGljaXplZC7CoA0KV2h5IG5vdCByZWxlYXNlIHRoZSBiZW5jaG1hcmtzIHlvdSBkaWQgd2hpbGUgZGVzaWduaW5nIHRoZSBpZ2IgZHJpdmVyLCBKYWNrPyBTYXkgd2hhdCx5b3UgZGlkbid0IGRvIGFueSBiZW5jaG1hcmtpbmc_IEhvdyBkb2VzIHRoZSABMAEBAQE- X-Mailer: YahooMailClassic/15.1.7 YahooMailWebService/0.8.139.530 Message-ID: <1364733314.80531.YahooMailClassic@web121603.mail.ne1.yahoo.com> Date: Sun, 31 Mar 2013 05:35:14 -0700 (PDT) From: Barney Cordoba Subject: Re: igb and ALTQ in 9.1-rc3 To: Jeffrey EPieper , Jack Vogel In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Nick Rogers , "freebsd-net@freebsd.org" , "Clement Hermann \(nodens\)" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 12:38:08 -0000 The reason that Jack is a no better programmer now than he was in 2009 migh= t have=A0something to do with the fact that he hides when his work is criti= cized.=A0 Why not release the benchmarks you did while designing the igb driver, Jack= ? Say what,you didn't do any benchmarking? How does the default driver perf= orm, say in a firewall,with 1000 user load? What's the optimum number of qu= eues to use in such a system?What's the effect of CPU binding? What's the e= ffect with multiple cards when you havemore queues than you have physical c= pus?=A0 What made you decide to use buf_ring? Something new to play with? I'm guessing that you have no idea. BC--- On Fri, 3/29/13, Jack Vogel wrote: From: Jack Vogel Subject: Re: igb and ALTQ in 9.1-rc3 To: "Pieper, Jeffrey E" Cc: "Barney Cordoba" , "Nick Rogers" , "freebsd-net@freebsd.org" , "Clement Her= mann (nodens)" Date: Friday, March 29, 2013, 12:36 PM Fortunately, Barney doesn't speak for me, or for Intel, and I've long ago r= ealized its pointless to attempt anything like a fair conversation with him. The only thing he's eve= r contributed is slander =0Aand pseudo-critique... another poison thread I'm done with. Jack On Fri, Mar 29, 2013 at 8:45 AM, Pieper, Jeffrey E wrote: =0A =0A =0A-----Original Message----- =0AFrom: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.or= g] On Behalf Of Barney Cordoba =0ASent: Friday, March 29, 2013 5:51 AM =0ATo: Jack Vogel; Nick Rogers =0ACc: freebsd-net@freebsd.org; Clement Hermann (nodens) =0ASubject: Re: igb and ALTQ in 9.1-rc3 =0A =0A =0A =0A--- On Thu, 3/28/13, Nick Rogers wrote: =0A =0A> From: Nick Rogers =0A> Subject: Re: igb and ALTQ in 9.1-rc3 =0A> To: "Jack Vogel" =0A> Cc: "Barney Cordoba" , "Clement Hermann (nod= ens)" , "freebsd-net@freebsd.org" =0A=0A> Date: Thursday, March 28, 2013, 9:29 PM =0A> On Thu, Mar 28, 2013 at 4:16 PM, Jack =0A> Vogel =0A> wrote: =0A> > Have been kept fairly busy with other matters, one =0A> thing I could do short =0A> > term is =0A> > change the defines in igb the way I did in the em =0A> driver so you could still =0A> > define =0A> > the older if_start entry. Right now those are based on =0A> OS version and so you =0A> > will =0A> > automatically get if_transmit, but I could change it to =0A> be IGB_LEGACY_TX or =0A> > so, =0A> > and that could be defined in the Makefile. =0A> > =0A> > Would this help? =0A> =0A> I'm currently using ALTQ successfully with the em driver, so =0A> if igb =0A> behaved the same with respect to using if_start instead of =0A> if_transmit =0A> when ALTQ is in play, that would be great. I do not =0A> completely =0A> understand the change you propose as I am not very familiar =0A> with the =0A> driver internals. Any kind of patch or extra =0A> Makefile/make.conf =0A> definition that would allow me to build a 9-STABLE kernel =0A> with an igb =0A> driver that works again with ALTQ, ASAP, would be much =0A> appreciated. =0A> =0A> > =0A> > Jack =0A> > =0A> > =0A> > =0A> > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers =0A> wrote: =0A> >> =0A> >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel =0A> wrote: =0A> >> > On Mon, Dec 10, 2012 at 11:58 PM, Gleb =0A> Smirnoff =0A> >> > wrote: =0A> >> > =0A> >> >> On Mon, Dec 10, 2012 at 03:31:19PM -0800, =0A> Jack Vogel wrote: =0A> >> >> J> UH, maybe asking the owner of the =0A> driver would help :) =0A> >> >> J> =0A> >> >> J> ... and no, I've never been aware of =0A> doing anything to stop =0A> >> >> supporting =0A> >> >> altq =0A> >> >> J> so you wouldn't see any commits. If =0A> there's something in the altq =0A> >> >> code =0A> >> >> or =0A> >> >> J> support (which I have nothing to do =0A> with) that caused this no-one =0A> >> >> informed =0A> >> >> J> me. =0A> >> >> =0A> >> >> Switching from if_start to if_transmit =0A> effectively disables ALTQ =0A> >> >> support. =0A> >> >> =0A> >> >> AFAIR, there is some magic implemented in =0A> other drivers that makes them =0A> >> >> modern (that means using if_transmit), but =0A> still capable to switch to =0A> >> >> queueing =0A> >> >> mode if SIOCADDALTQ was casted upon them. =0A> >> >> =0A> >> >> =0A> >> > Oh, hmmm, I'll look into the matter after my =0A> vacation. =0A> >> > =0A> >> > Jack =0A> >> =0A> >> Has there been any progress on resolving this =0A> issue? I recently ran =0A> >> into this problem upgrading my servers from 8.3 to =0A> 9.1-RELEASE and am =0A> >> wondering what the latest recommendation is. I've =0A> used ALTQ and igb =0A> >> successfully for years and it is unfortunate it no =0A> longer works. =0A> >> Appreciate any advice. =0A> >> =0A> =0A>Do yourself a favor and either get a cheap dual port 82571 card or =0A>2 cards and disable the IGB ports. The igb driver is defective, and unt= il =0A>they back out the new, untested multi-queue stuff you're just neutering =0A>your system trying to use it. =0A> =0A>Frankly this project made a huge mistake by moving forward with multi =0A>queue just for the sake of saying that you support it; without having =0A>any credible plan for implementing it. That nonsense that Bill Macy did =0A>should have been tarballed up and deposited in the trash folder. The =0A>biggest mess in programming history. =0A> =0A>That being said, the solution is not to hack the igb driver; its to mak= e =0A>ALTQ if_transmit compatible, which shouldn't be all that difficult. =0A> =0A>BC =0A =0AI may be misunderstanding what you are saying, but if the solution is, a= s you say "not to hack the igb driver", then how is it defective in this ca= se? Or are you just directing vitriol toward Intel? Multi-queue is working = fine in igb. =0A=0A =0AJeff =0A =0A_______________________________________________ =0Afreebsd-net@freebsd.org mailing list =0Ahttp://lists.freebsd.org/mailman/listinfo/freebsd-net =0ATo unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" =0A_______________________________________________ =0Afreebsd-net@freebsd.org mailing list =0Ahttp://lists.freebsd.org/mailman/listinfo/freebsd-net =0ATo unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" =0A =0A From owner-freebsd-net@FreeBSD.ORG Sun Mar 31 12:42:48 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D4A6F168 for ; Sun, 31 Mar 2013 12:42:48 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm32-vm5.bullet.mail.ne1.yahoo.com (nm32-vm5.bullet.mail.ne1.yahoo.com [98.138.229.53]) by mx1.freebsd.org (Postfix) with ESMTP id 9D6D3AF7 for ; Sun, 31 Mar 2013 12:42:48 +0000 (UTC) Received: from [98.138.90.57] by nm32.bullet.mail.ne1.yahoo.com with NNFMP; 31 Mar 2013 12:42:42 -0000 Received: from [98.138.89.197] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 31 Mar 2013 12:42:42 -0000 Received: from [127.0.0.1] by omp1055.mail.ne1.yahoo.com with NNFMP; 31 Mar 2013 12:42:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 239295.23083.bm@omp1055.mail.ne1.yahoo.com Received: (qmail 16077 invoked by uid 60001); 31 Mar 2013 12:42:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1364733762; bh=+gRRIodxTu9U0bx7Y8YesfxVmfbI/h8A7b634aRkut0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=s1WoxAr4Drx/w5hFweAG8At5Fa9+tY63b9auD6qddiYOa+p0Lb41s1HqHoZoVAkSN62Jyr7/xtCiRQqASp3fTZ3aahZwC8Znb57+zBWHICWYv3D8z7/NIme8ln3ZPitbCtUlC8iJyAzuB8aoAOHNm97Et+ZyCd8Kriw28eak/YA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=dVYXCOlnUUTBtf74iGyGWhudreZW2ZJfG6LjBGViIkidr6LnLClhExkhMIJIVgKaYe3PgiL1298I+BwNUUkRomA0scrQKUTjd4KwhAHopIFSSP+EY7Iis2G9V4lNArL0Qb0kXUo2RfGSDfvLkyKgb5g7iqg9NsV0ufUVdxE8GEU=; X-YMail-OSG: HRkucTUVM1keDvWEUwsjvSgjM2EJvEg.BBv_MBtqAkoLyo_ iZ5sM52n2W60aYPsmZYLx_7R_geEQdI8TNIkDzgW.KhrTExBTndR5eIRgJ43 GWs4sm_hsAG1oUGXhcWrfPtBVmZUfbO3tm6nd8qUEbj7I6zcXTs4P7vBnpl4 HaEI3hdxiUZqLhkq8E5FVwV6.Y0Ngmp2g7C5YljfwVc5bKrd1dq5jJhhlkmX 2syIKscLNut_MdLzDgMhoAhYhzBOH9TlxoO4dMrnbKAL3Vw7HErUO5WmC1Ba qt7XvZ2J1jzH0Tl8.Zj9vwfcEwDpg2FRwb05GiUyx3iKERcnuhVO3dVKoFVn 9cvTXYDGTGOMaEBnqzB_QFqpz0X8C_ZAA1DHZz.J5PrA3J3Tz2yUgiLuk7su QLbJkXcr30wpEoaluh_mY63Xe16TU5jNiIdmgiFvXaWV7mU3LlDeVybWNJOr hpYznb0C0ikSdfjcNYbSiMikl2qK6ToCWD0ZYbSj2J1fwOaVlcWkJqhd30m7 StL6fpO3I.jPRrHOD15CbuKzYYS15Xg-- Received: from [98.203.118.124] by web121606.mail.ne1.yahoo.com via HTTP; Sun, 31 Mar 2013 05:42:39 PDT X-Rocket-MIMEInfo: 002.001, CgotLS0gT24gRnJpLCAzLzI5LzEzLCBBZHJpYW4gQ2hhZGQgPGFkcmlhbkBmcmVlYnNkLm9yZz4gd3JvdGU6Cgo.IEZyb206IEFkcmlhbiBDaGFkZCA8YWRyaWFuQGZyZWVic2Qub3JnPgo.IFN1YmplY3Q6IFJlOiBpZ2IgYW5kIEFMVFEgaW4gOS4xLXJjMwo.IFRvOiAiTmljayBSb2dlcnMiIDxuY3JvZ2Vyc0BnbWFpbC5jb20.Cj4gQ2M6ICJQaWVwZXIsIEplZmZyZXkgRSIgPGplZmZyZXkuZS5waWVwZXJAaW50ZWwuY29tPiwgImZyZWVic2QtbmV0QGZyZWVic2Qub3JnIiA8ZnJlZWJzZC1uZXRAZnJlZWJzZC4BMAEBAQE- X-Mailer: YahooMailClassic/15.1.7 YahooMailWebService/0.8.139.530 Message-ID: <1364733759.8517.YahooMailClassic@web121606.mail.ne1.yahoo.com> Date: Sun, 31 Mar 2013 05:42:39 -0700 (PDT) From: Barney Cordoba Subject: Re: igb and ALTQ in 9.1-rc3 To: Nick Rogers , Adrian Chadd In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jeffrey EPieper , "freebsd-net@freebsd.org" , "Clement Hermann \(nodens\)" , Jack Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 12:42:48 -0000 --- On Fri, 3/29/13, Adrian Chadd wrote: > From: Adrian Chadd > Subject: Re: igb and ALTQ in 9.1-rc3 > To: "Nick Rogers" > Cc: "Pieper, Jeffrey E" , "freebsd-net@freebsd.org" , "Clement Hermann (nodens)" , "Jack Vogel" > Date: Friday, March 29, 2013, 1:10 PM > On 29 March 2013 10:04, Nick Rogers > > wrote: > > > > Multiqueue or not, I would appreciate any help with > this thread's > > original issue. Whether or not its the ideal thing to > do, I cannot > > simply just replace the NICs with an em(4) variant, as > I have hundreds > > of customers/systems already in production running 8.3 > and relying on > > the igb driver + ALTQ. I need to be able to upgrade > these systems to > > 9.1 without making hardware changes. > > > > > If it's that critical, have you thought about contracting > out that task to > a developer? You have 100s of systems/customers using 1990s-class traffic shaping and you have no programmer on staff with the skills to patch and test an ethernet driver? the igb driver has always sucked rocks, why did you use them in the first place. Or did they just happen to be on the MB you use? BC From owner-freebsd-net@FreeBSD.ORG Sun Mar 31 12:57:07 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 01AF55F6 for ; Sun, 31 Mar 2013 12:57:07 +0000 (UTC) (envelope-from rlp@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id B1F9BB83 for ; Sun, 31 Mar 2013 12:57:06 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 48886D4C44; Sun, 31 Mar 2013 14:56:59 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id yeNrqGy+KaCj; Sun, 31 Mar 2013 14:56:58 +0200 (CEST) Received: from webmail.semihalf.com (semihalf.com [206.130.101.55]) by smtp.semihalf.com (Postfix) with ESMTPSA id 160BBD4C25; Sun, 31 Mar 2013 14:56:57 +0200 (CEST) MIME-Version: 1.0 Date: Sun, 31 Mar 2013 06:56:55 -0600 From: Pablo Ribalta Lorenzo To: Subject: Re: vlan with modified MAC fails to communicate In-Reply-To: <201303301948.r2UJm2PX061547@mail.karels.net> References: <201303301948.r2UJm2PX061547@mail.karels.net> Message-ID: X-Sender: rlp@semihalf.com User-Agent: RoundCube Webmail/0.2.2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 12:57:07 -0000 >> From what I see, looks like this behavior from FreeBSD side is expected >> and the changes should be incorporated to my NIC. > > I'm not sure what you mean, but there is no existing code to propagate > a MAC change on a VLAN to its parent device. I think it is a bug that > a change appears to work. Rather than to my NIC, I wanted to say that my solution can be related to improve the packet filtering for not dropping the packets in the NIC after changing vlan's MAC, my fault. Anyway you previous experience is a good hint for me, thank you for sharing it. However, I won't be able to perform concrete tests on this side once this easter weeekend passes and I have the time, so by now I can only speculate. From owner-freebsd-net@FreeBSD.ORG Sun Mar 31 18:56:22 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 76D73A56 for ; Sun, 31 Mar 2013 18:56:22 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0F3F5A34 for ; Sun, 31 Mar 2013 18:56:21 +0000 (UTC) Received: by mail-wg0-f54.google.com with SMTP id a12so1566879wgh.33 for ; Sun, 31 Mar 2013 11:56:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mU4is1uHkPNErD2wvuwfReGOoXSGVO0YPAKZ5Wx+Wpg=; b=pbaxJoLo7AkX6UP6ZkyUt3OO5GM6Ofdz0OHWPcqFJDITgFm3hke23rBuxlO8we/Spy BMQ7aVXK4rH0HnVc2vd8BIDcmKkGZBWva8JOT0mkW7xqpF4yzIpp0+sDtkfLANNQeuve 47WQQF9YGweu3U7GMp4DyxYmfsyvZi3MM8WiqWV/wQ+7b4UD9UGPC2jLU4+mQeeJEjps OlibUZf1BNIhUNi0pCxoH9OFgdqKXfqjkwUfgHxCQ8BI3jXMOMp0ZWhb/cX4j1GdeRn0 UZqO9eaKuWbmlsCQ3lngbO6IYKtzlqUQqx/wgNGH/xnR5PEz7j+T+0tDbzhTRU4B9P/z knCQ== MIME-Version: 1.0 X-Received: by 10.181.11.164 with SMTP id ej4mr6796205wid.29.1364755691573; Sun, 31 Mar 2013 11:48:11 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Sun, 31 Mar 2013 11:48:11 -0700 (PDT) In-Reply-To: <1364733314.80531.YahooMailClassic@web121603.mail.ne1.yahoo.com> References: <1364733314.80531.YahooMailClassic@web121603.mail.ne1.yahoo.com> Date: Sun, 31 Mar 2013 11:48:11 -0700 X-Google-Sender-Auth: 5rmrcBzG5anzyMFsPJreQHmmug8 Message-ID: Subject: Re: igb and ALTQ in 9.1-rc3 From: Adrian Chadd To: Barney Cordoba Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Jeffrey EPieper , Nick Rogers , "Clement Hermann \(nodens\)" , Jack Vogel , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 18:56:22 -0000 Barney, As much as we'd like it, Jack's full time job involves other things besides supporting FreeBSD. If you want to see it done better, please work with the FreeBSD developer community and improve the intel driver. No-one is stopping you from stepping in. In fact, this would be _beneficial_ to Jack's work inside Intel with FreeBSD. If there is more of an active community participating with the intel drivers and more companies choosing intel hardware for FreeBSD network services, Intel will likely dump more effort into FreeBSD. So please, stop your non-constructive trolling and complaining and put your skills to use for the greater good. Sheesh. Intel have supplied a very thorough, detailed driver as well as programming and errata datasheets for their chips. We aren't in the dark here. There's more than enough rope to hang ourselves with. Please focus on making it better. Adrian On 31 March 2013 05:35, Barney Cordoba wrote: > The reason that Jack is a no better programmer now than he was in 2009 mi= ght have something to do with the fact that he hides when his work is criti= cized. > Why not release the benchmarks you did while designing the igb driver, Ja= ck? Say what,you didn't do any benchmarking? How does the default driver pe= rform, say in a firewall,with 1000 user load? What's the optimum number of = queues to use in such a system?What's the effect of CPU binding? What's the= effect with multiple cards when you havemore queues than you have physical= cpus? > What made you decide to use buf_ring? Something new to play with? > I'm guessing that you have no idea. > BC--- On Fri, 3/29/13, Jack Vogel wrote: > > From: Jack Vogel > Subject: Re: igb and ALTQ in 9.1-rc3 > To: "Pieper, Jeffrey E" > Cc: "Barney Cordoba" , "Nick Rogers" , "freebsd-net@freebsd.org" , "Clement H= ermann (nodens)" > Date: Friday, March 29, 2013, 12:36 PM > > Fortunately, Barney doesn't speak for me, or for Intel, and I've long ago= realized its pointless to > attempt anything like a fair conversation with him. The only thing he's e= ver contributed is slander > > and pseudo-critique... another poison thread I'm done with. > > Jack > > > > On Fri, Mar 29, 2013 at 8:45 AM, Pieper, Jeffrey E wrote: > > > > > > -----Original Message----- > > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org= ] On Behalf Of Barney Cordoba > > Sent: Friday, March 29, 2013 5:51 AM > > To: Jack Vogel; Nick Rogers > > Cc: freebsd-net@freebsd.org; Clement Hermann (nodens) > > Subject: Re: igb and ALTQ in 9.1-rc3 > > > > > > > > --- On Thu, 3/28/13, Nick Rogers wrote: > > > >> From: Nick Rogers > >> Subject: Re: igb and ALTQ in 9.1-rc3 > >> To: "Jack Vogel" > >> Cc: "Barney Cordoba" , "Clement Hermann (noden= s)" , "freebsd-net@freebsd.org" > > >> Date: Thursday, March 28, 2013, 9:29 PM > >> On Thu, Mar 28, 2013 at 4:16 PM, Jack > >> Vogel > >> wrote: > >> > Have been kept fairly busy with other matters, one > >> thing I could do short > >> > term is > >> > change the defines in igb the way I did in the em > >> driver so you could still > >> > define > >> > the older if_start entry. Right now those are based on > >> OS version and so you > >> > will > >> > automatically get if_transmit, but I could change it to > >> be IGB_LEGACY_TX or > >> > so, > >> > and that could be defined in the Makefile. > >> > > >> > Would this help? > >> > >> I'm currently using ALTQ successfully with the em driver, so > >> if igb > >> behaved the same with respect to using if_start instead of > >> if_transmit > >> when ALTQ is in play, that would be great. I do not > >> completely > >> understand the change you propose as I am not very familiar > >> with the > >> driver internals. Any kind of patch or extra > >> Makefile/make.conf > >> definition that would allow me to build a 9-STABLE kernel > >> with an igb > >> driver that works again with ALTQ, ASAP, would be much > >> appreciated. > >> > >> > > >> > Jack > >> > > >> > > >> > > >> > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers > >> wrote: > >> >> > >> >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel > >> wrote: > >> >> > On Mon, Dec 10, 2012 at 11:58 PM, Gleb > >> Smirnoff > >> >> > wrote: > >> >> > > >> >> >> On Mon, Dec 10, 2012 at 03:31:19PM -0800, > >> Jack Vogel wrote: > >> >> >> J> UH, maybe asking the owner of the > >> driver would help :) > >> >> >> J> > >> >> >> J> ... and no, I've never been aware of > >> doing anything to stop > >> >> >> supporting > >> >> >> altq > >> >> >> J> so you wouldn't see any commits. If > >> there's something in the altq > >> >> >> code > >> >> >> or > >> >> >> J> support (which I have nothing to do > >> with) that caused this no-one > >> >> >> informed > >> >> >> J> me. > >> >> >> > >> >> >> Switching from if_start to if_transmit > >> effectively disables ALTQ > >> >> >> support. > >> >> >> > >> >> >> AFAIR, there is some magic implemented in > >> other drivers that makes them > >> >> >> modern (that means using if_transmit), but > >> still capable to switch to > >> >> >> queueing > >> >> >> mode if SIOCADDALTQ was casted upon them. > >> >> >> > >> >> >> > >> >> > Oh, hmmm, I'll look into the matter after my > >> vacation. > >> >> > > >> >> > Jack > >> >> > >> >> Has there been any progress on resolving this > >> issue? I recently ran > >> >> into this problem upgrading my servers from 8.3 to > >> 9.1-RELEASE and am > >> >> wondering what the latest recommendation is. I've > >> used ALTQ and igb > >> >> successfully for years and it is unfortunate it no > >> longer works. > >> >> Appreciate any advice. > >> >> > >> > >>Do yourself a favor and either get a cheap dual port 82571 card or > >>2 cards and disable the IGB ports. The igb driver is defective, and until > >>they back out the new, untested multi-queue stuff you're just neutering > >>your system trying to use it. > >> > >>Frankly this project made a huge mistake by moving forward with multi > >>queue just for the sake of saying that you support it; without having > >>any credible plan for implementing it. That nonsense that Bill Macy did > >>should have been tarballed up and deposited in the trash folder. The > >>biggest mess in programming history. > >> > >>That being said, the solution is not to hack the igb driver; its to make > >>ALTQ if_transmit compatible, which shouldn't be all that difficult. > >> > >>BC > > > > I may be misunderstanding what you are saying, but if the solution is, as= you say "not to hack the igb driver", then how is it defective in this cas= e? Or are you just directing vitriol toward Intel? Multi-queue is working f= ine in igb. > > > > > Jeff > > > > _______________________________________________ > > 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" > > _______________________________________________ > > 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" > > > > _______________________________________________ > 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" From owner-freebsd-net@FreeBSD.ORG Sun Mar 31 19:39:32 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AEAEB283 for ; Sun, 31 Mar 2013 19:39:32 +0000 (UTC) (envelope-from richard@tector.org.uk) Received: from mx0.thekeelecentre.com (mx0.thekeelecentre.com [88.98.64.52]) by mx1.freebsd.org (Postfix) with ESMTP id 722BAC00 for ; Sun, 31 Mar 2013 19:39:31 +0000 (UTC) Received: from filter.mx0.thekeelecentre.com (unknown [88.98.64.55]) by mx0.thekeelecentre.com (Postfix) with ESMTP id E141FB94D for ; Sun, 31 Mar 2013 20:33:33 +0100 (BST) X-Virus-Scanned: amavisd-new at thekeelecentre.com Received: from mx0.thekeelecentre.com ([88.98.64.52]) by filter.mx0.thekeelecentre.com (filter.mx0.thekeelecentre.com [88.98.64.55]) (amavisd-new, port 10024) with ESMTP id OwVX7YDZweuK for ; Sun, 31 Mar 2013 19:33:32 +0000 (UTC) Received: from [10.0.2.13] (nat-gw.hl.tector.org.uk [88.96.67.61]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx0.thekeelecentre.com (Postfix) with ESMTPSA id E410CB921 for ; Sun, 31 Mar 2013 20:33:31 +0100 (BST) Message-ID: <51588F43.7060609@tector.org.uk> Date: Sun, 31 Mar 2013 20:32:19 +0100 From: Richard Tector User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Route next-hop interface behaviour Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 19:39:32 -0000 Hi, I'm not sure if it is expected behaviour but when configuring a static route (default or otherwise) the outbound interface recorded in the table does not update when the system's IP changes interface, even when removing and re-adding it. Fairly simple topology, system running 9.1-STABLE (30th March) with just one of four 'em' interfaces in use - em0 with 10.0.2.199. Default route to 10.0.2.1. Whilst troubleshooting some odd TCP behaviour I thought I'd try a different interface and so downed the active interface and brought up one on a PCI card, and swapped the cable over: # ifconfig em0 down # ifconfig em2 inet 10.0.2.199/24 # ifconfig em2 up ##### If I then ping an external host it shows as the destination network being inaccessible: root@daffy:~ # ping 212.23.6.76 PING 212.23.6.76 (212.23.6.76): 56 data bytes ping: sendto: Network is down ##### Can contact the next hop just fine: root@daffy:~ # ping 10.0.2.1 PING 10.0.2.1 (10.0.2.1): 56 data bytes 64 bytes from 10.0.2.1: icmp_seq=0 ttl=64 time=0.211 ms ##### Routing table shows that the default route is still bound to em0 even though the next hop is on em2: root@daffy:~ # netstat -rfinet -n Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.0.2.1 UGS 0 3141 em0 ^^^ 10.0.2.0/24 link#4 U 1 255 em2 10.0.2.199 link#1 UHS 1 0 lo0 127.0.0.1 link#9 UH 0 0 lo0 ##### Removing the default route and re-adding also leaves it on the old interface: root@daffy:~ # route delete default delete net default root@daffy:~ # route add default 10.0.2.1 add net default: gateway 10.0.2.1 root@daffy:~ # netstat -rfinet -n Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.0.2.1 UGS 0 0 em0 10.0.2.0/24 link#4 U 0 688 em2 10.0.2.199 link#1 UHS 1 0 lo0 127.0.0.1 link#9 UH 0 0 lo0 I can understand the initial problem, but surely when I re-add the route it should do a lookup against the table for the next hop, ie. 10.0.2.0/24, and use the associated Netif? What's interesting is that if I remove the IP configuration from em0 it removes the default route above (even though the interface is downed). Re-adding the route works. Regards, Richard From owner-freebsd-net@FreeBSD.ORG Mon Apr 1 10:24:25 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2E4A6E2B for ; Mon, 1 Apr 2013 10:24:25 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by mx1.freebsd.org (Postfix) with ESMTP id AC49F137 for ; Mon, 1 Apr 2013 10:24:24 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id v10so1789123lbd.2 for ; Mon, 01 Apr 2013 03:24:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=1SWEgF8v58HSuGGNctiC3NXesPEc/NJ8eyeqbLmJMn4=; b=GBbZyrIvwTHqME3XxRIJaiOmEvkuzpck9ojHBpIDQL3frJWrahxcqC24m8eo6CVnZW dJoIiZVhOurpvGTFyWClhUxXll9bP3HvDjM52rd+Zml3GY8I3U+xYKILkW8oqhxqDHRp K7BuzeJHeX4T0NRuS9h5I6arNqnT50AGHooPwHNZy/5mFXy66YhTU4XlRPzXXihoGXb9 mInd6BrNHvVAqejvKfVaNME8OzLzXpFfMgtAy7klkghcL4HD8cNT9lrms4V+b+IFpf/7 XaW1W6IESYwY0JV4EmOY2pLdZmKWpILlsNTxkRtnRVGs3Y15ihKnxJHVfovrt4yW91ok fxrQ== MIME-Version: 1.0 X-Received: by 10.152.106.5 with SMTP id gq5mr5500147lab.5.1364811857937; Mon, 01 Apr 2013 03:24:17 -0700 (PDT) Sender: ndenev@gmail.com Received: by 10.114.92.10 with HTTP; Mon, 1 Apr 2013 03:24:17 -0700 (PDT) In-Reply-To: References: Date: Mon, 1 Apr 2013 11:24:17 +0100 X-Google-Sender-Auth: epyzCMVq33njl5xsx4CO9N67nu4 Message-ID: Subject: Re: 2 vlans - setfib - kernel: arpresolve: can't allocate llinfo for x.x.x.x From: Nikolay Denev To: Eduardo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 10:24:25 -0000 Hi, You can try the patch form this PR : http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/167947 Looks like exactly the same issue. Regards, Nikolay On Thu, Mar 28, 2013 at 7:44 PM, Eduardo wrote: > Hi Folks, > > I have a server with a 10G intel card, X520-DA2, and it is working > fine, interface shows up as ix0 > > On this card, I have one interface connected at 10G, and it has 2 > vlans on it (no "plain" IP is on the machine or on this card, only via > these vlans) > > I have it also configured them with setfib on rc.local, so each vlan > is on your own fib and sees a different default gateway etc. > > I removed the other net and gateway from the FIBs, so one FIB has to > go to the gateway in order to reach the other vlan. > > I can ssh to the vlan10 fine ... and I can even do iperf UDP tests > between the two vlans, but TCP does not work... and I keep getting > these messages: > > kernel: arpresolve: can't allocate llinfo for > > I already removed IPFW from the kernel, (saw some reference to that > being the culprit), so there is no firewall right now. > > This is now on FreeBSD 8 STABLE ( to be more exact: 8.4-beta-1) and it > was before on 9.1, both have the same problem. I also tried something > I saw on a list, hard coding ixgbe_num_queues, but made no difference > either. > > Any ideias are appreciated. > > thanks > -Ed > _______________________________________________ > 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" > From owner-freebsd-net@FreeBSD.ORG Mon Apr 1 11:06:47 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AF3818E7 for ; Mon, 1 Apr 2013 11:06:47 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 91A8D33A for ; Mon, 1 Apr 2013 11:06:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r31B6lIQ033733 for ; Mon, 1 Apr 2013 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r31B6lDr033731 for freebsd-net@FreeBSD.org; Mon, 1 Apr 2013 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 1 Apr 2013 11:06:47 GMT Message-Id: <201304011106.r31B6lDr033731@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 11:06:47 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/177456 net [tcp] [patch] An error of calculating TCP sequence num o kern/177417 net [ip6] Invalid protocol value in ipsec6_common_input_cb o kern/177402 net [igb] [pf] problem with ethernet driver igb + pf / alt o kern/177400 net [jme] JMC25x 1000baseT establishment issues o kern/177384 net [igb] [patch] Updating igb manpage/code with info abou o kern/177366 net [ieee80211] negative malloc(9) statistics for 80211nod o kern/177362 net [netinet] [patch] Wrong control used to return TOS o kern/177194 net [netgraph] Unnamed netgraph nodes for vlan interfaces o kern/177184 net [bge] [patch] enable wake on lan o kern/177139 net [igb] igb drops ethernet ports 2 and 3 o kern/176884 net [re] re0 flapping up/down o kern/176671 net [epair] MAC address for epair device not unique o kern/176667 net [libalias] [patch] libalias locks on uninitalized data o kern/176596 net [firewire] [ip6] Crash with IPv6 and Firewire o kern/176484 net [ipsec] [enc] [patch] panic: IPsec + enc(4); device na o kern/176446 net [netinet] [patch] Concurrency in ixgbe driving out-of- o kern/176420 net [kernel] [patch] incorrect errno for LOCAL_PEERCRED o kern/176419 net [kernel] [patch] socketpair support for LOCAL_PEERCRED o kern/176401 net [netgraph] page fault in netgraph o kern/176167 net [ipsec][lagg] using lagg and ipsec causes immediate pa o kern/176097 net [lagg] [patch] lagg/lacp broken when aggregated interf o kern/176027 net [em] [patch] flow control systcl consistency for em dr o kern/176026 net [tcp] [patch] TCP wrappers caused quite a lot of warni o bin/175974 net ppp(8): logic issue o kern/175864 net [re] Intel MB D510MO, onboard ethernet not working aft o kern/175852 net [amd64] [patch] in_cksum_hdr() behaves differently on o kern/175734 net no ethernet detected on system with EG20T PCH chipset o kern/175267 net [pf] [tap] pf + tap keep state problem o kern/175236 net [epair] [gif] epair and gif Devices On Bridge o kern/175182 net [panic] kernel panic on RADIX_MPATH when deleting rout o kern/175153 net [tcp] will there miss a FIN when do TSO? o kern/174959 net [net] [patch] rnh_walktree_from visits spurious nodes o kern/174958 net [net] [patch] rnh_walktree_from makes unreasonable ass o kern/174897 net [route] Interface routes are broken o kern/174851 net [bxe] [patch] UDP checksum offload is wrong in bxe dri o kern/174850 net [bxe] [patch] bxe driver does not receive multicasts o kern/174849 net [bxe] [patch] bxe driver can hang kernel when reset o kern/174822 net [tcp] Page fault in tcp_discardcb under high traffic o kern/174602 net [gif] [ipsec] traceroute issue on gif tunnel with ipse o kern/174535 net [tcp] TCP fast retransmit feature works strange o kern/173871 net [gif] process of 'ifconfig gif0 create hangs' when if_ o kern/173475 net [tun] tun(4) stays opened by PID after process is term o kern/173201 net [ixgbe] [patch] Missing / broken ixgbe sysctl's and tu o kern/173137 net [em] em(4) unable to run at gigabit with 9.1-RC2 o kern/173002 net [patch] data type size problem in if_spppsubr.c o kern/172985 net [patch] [ip6] lltable leak when adding and removing IP o kern/172895 net [ixgb] [ixgbe] do not properly determine link-state o kern/172683 net [ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos o kern/172113 net [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net [ip6] IPv6 packets transmitting only on queue 0 o kern/171739 net [bce] [panic] bce related kernel panic o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net [ndis] undocumented dependency for ndis(4) o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net [epair] [request] Add the ability to name epair device o kern/171228 net [re] [patch] if_re - eeprom write issues o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169664 net [bgp] Wrongful replacement of interface connected net o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/167059 net [tcp] [panic] System does panic in in_pcbbind() and ha o kern/166940 net [ipfilter] [panic] Double fault in kern 8.2 o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166372 net [patch] ipfilter drops UDP packets with zero checksum o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis o kern/165963 net [panic] [ipf] ipfilter/nat NULL pointer deference o kern/165903 net mbuf leak o kern/165643 net [net] [patch] Missing vnet restores in net/if_ethersub o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155680 net [multicast] problems with multicast s kern/155642 net [new driver] [request] Add driver for Realtek RTL8191S o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel p kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [new driver] [request]: Port brcm80211 driver from Lin o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph f kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 463 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Apr 1 15:36:04 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 65A97812; Mon, 1 Apr 2013 15:36:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 45995DC9; Mon, 1 Apr 2013 15:36:04 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A259BB9B2; Mon, 1 Apr 2013 11:36:03 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: close(2) while accept(2) is blocked Date: Mon, 1 Apr 2013 11:22:12 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <515475C7.6010404@FreeBSD.org> In-Reply-To: <515475C7.6010404@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201304011122.13101.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 01 Apr 2013 11:36:03 -0400 (EDT) Cc: FreeBSD Hackers , Andriy Gapon X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 15:36:04 -0000 On Thursday, March 28, 2013 12:54:31 pm Andriy Gapon wrote: > > So, this started as a simple question, but the answer was quite unexpected to me. > > Let's say we have an opened and listen-ed socket and let's assume that we know > that one thread is blocked in accept(2) and another thread is calling close(2). > What is going to happen? > > Turns out that practically nothing. For kernel the close call would be almost a nop. > My understanding is this: > - when socket is created, its reference count is 1 > - when accept(2) is called, fget in kernel increments the reference count (kept in > an associated struct file) > - when close(2) is called, the reference count is decremented > > The reference count is still greater than zero, so fdrop does not call fo_close. > That means that in the case of a socket soclose is not called. > > I am sure that the reference counting in this case is absolutely correct with > respect to managing kernel side structures. But I am not that it is correct with > respect to hiding the explicit close(2) call from other threads that may be > waiting on the socket. > In other words, I am not sure if fo_close is supposed to signify that there are no > uses of a file, or that userland close-d the file. Or perhaps these should be two > different methods. > > Additional note is that shutdown(2) doesn't wake up the thread in accept(2) > either. At least that's true for unix domain sockets. > Not sure if this is a bug. > > But the summary seems to be is that currently it is not possible to break a thread > out of accept(2) (at least without resorting to signals). I think you need to split the 'struct file' reference count into two different counts similar to the how we have vref/vrele vs vhold/vdrop for vnodes. The fget for accept and probably most other system calls should probably be equivalent to vhold, whereas things like open/dup (and storing an fd in a cmsg) should be more like vref. close() should then be a vrele(). -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Mon Apr 1 15:44:53 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id ED66DE8F for ; Mon, 1 Apr 2013 15:44:53 +0000 (UTC) (envelope-from fodillemlinkarim@gmail.com) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id BFB18E72 for ; Mon, 1 Apr 2013 15:44:53 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id c11so2476038ieb.29 for ; Mon, 01 Apr 2013 08:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=6ny1dBH7lRMiWgCENCNwuAoU+z+V8pn7rNDa1e1QkoE=; b=wFNSpez3J8N7iJQkNagCQiCj2udxGIYM52Qn7dezX2LP/RRT6IALmKueAK2JiFKzLw hoGmhQj6Ga9UeoW+HxrPwEGc3fBwo0mbRM4+jy17WaAEASMtZp+1Xl0/PHb8Ta6d118c t1qXFbG2OpdQhalW9Km1b+rKAXcdi5pjD5EAvGC29D2OpbXNngT65E22uWziCDnX3JTp mk6GuTQQxzZ+7fQlVlCltwO/RfGIoxIjZjmUiT4XTh4LrJsNJhART+qbH/tG+31Orc06 DIjHXNNoJxRDUE5PD6jowbGaEv5+PypjJwRGx3esHzxWKvvyUBiSgclPzQ/Ps89ntx30 nxtQ== X-Received: by 10.50.119.102 with SMTP id kt6mr3738705igb.12.1364831093526; Mon, 01 Apr 2013 08:44:53 -0700 (PDT) Received: from [192.168.1.73] ([208.85.112.101]) by mx.google.com with ESMTPS id a3sm5019547igq.5.2013.04.01.08.44.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Apr 2013 08:44:51 -0700 (PDT) Message-ID: <5159AB72.1050202@gmail.com> Date: Mon, 01 Apr 2013 11:44:50 -0400 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: igb and ALTQ in 9.1-rc3 References: <1355177348.71087.YahooMailClassic@web121601.mail.ne1.yahoo.com> <50C6656E.3020601@gmail.com> <20121211075853.GU48639@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 15:44:54 -0000 Hi Jack, I think this would help M. Rogers case as we have done something similar here to circumvent the issue and it seems to work well. I would also add that when using ALTQ we found it much more stable to set the number of queues to 1: static int igb_num_queues = 1; Our approach consisted in keeping igb_start() defined and using igb_mq_start_locked() inside it instead of igb_start_locked(). Regards, Karim. On 28/03/2013 7:16 PM, Jack Vogel wrote: > Have been kept fairly busy with other matters, one thing I could do short > term is > change the defines in igb the way I did in the em driver so you could still > define > the older if_start entry. Right now those are based on OS version and so > you will > automatically get if_transmit, but I could change it to be IGB_LEGACY_TX or > so, > and that could be defined in the Makefile. > > Would this help? > > Jack > > > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers wrote: > >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel wrote: >>> On Mon, Dec 10, 2012 at 11:58 PM, Gleb Smirnoff >> wrote: >>>> On Mon, Dec 10, 2012 at 03:31:19PM -0800, Jack Vogel wrote: >>>> J> UH, maybe asking the owner of the driver would help :) >>>> J> >>>> J> ... and no, I've never been aware of doing anything to stop >> supporting >>>> altq >>>> J> so you wouldn't see any commits. If there's something in the altq >> code >>>> or >>>> J> support (which I have nothing to do with) that caused this no-one >>>> informed >>>> J> me. >>>> >>>> Switching from if_start to if_transmit effectively disables ALTQ >> support. >>>> AFAIR, there is some magic implemented in other drivers that makes them >>>> modern (that means using if_transmit), but still capable to switch to >>>> queueing >>>> mode if SIOCADDALTQ was casted upon them. >>>> >>>> >>> Oh, hmmm, I'll look into the matter after my vacation. >>> >>> Jack >> Has there been any progress on resolving this issue? I recently ran >> into this problem upgrading my servers from 8.3 to 9.1-RELEASE and am >> wondering what the latest recommendation is. I've used ALTQ and igb >> successfully for years and it is unfortunate it no longer works. >> Appreciate any advice. >> >>> _______________________________________________ >>> 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" > _______________________________________________ > 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" From owner-freebsd-net@FreeBSD.ORG Mon Apr 1 19:01:56 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5AB53D4E; Mon, 1 Apr 2013 19:01:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 39BA79C5; Mon, 1 Apr 2013 19:01:56 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 82C57B94C; Mon, 1 Apr 2013 15:01:55 -0400 (EDT) From: John Baldwin To: freebsd-virtualization@freebsd.org Subject: Re: KVM with freeBSD and SR-IOV vlan doesn't working! Date: Mon, 1 Apr 2013 13:47:55 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <1364376687875-5799323.post@n5.nabble.com> In-Reply-To: <1364376687875-5799323.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201304011347.55406.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 01 Apr 2013 15:01:55 -0400 (EDT) Cc: freebsd-net@freebsd.org, kindule X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 19:01:56 -0000 On Wednesday, March 27, 2013 5:31:27 am kindule wrote: > Recently, we use KVM and SR-IOV in our project. And we choose freeBSD10 as > the guest os.As we use the ip address in the igb0 of our freeBSD10 guest, it > working no problem.However when i use vlan in our igb0 of the freeBSD10 > guest,we can see the vlan assigned right and we can ping the vlan address > without problem.But we add a gateway of the vlan area.we can't connnected to > the gateway. > there are some os messages: > Host: Debian 7.0 and KVM 1.2 > Guest: FreeBSD10-current > > And thanks for your help! Hmm, does the same vlan setup work on a standalone machine? -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Mon Apr 1 20:58:47 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CACC0925 for ; Mon, 1 Apr 2013 20:58:47 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id AC2A5DA for ; Mon, 1 Apr 2013 20:58:47 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 01 Apr 2013 14:01:17 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id r31KweuD049887; Mon, 1 Apr 2013 13:58:40 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id r31KwdkI049885; Mon, 1 Apr 2013 13:58:39 -0700 (PDT) (envelope-from ambrisko) Date: Mon, 1 Apr 2013 13:58:39 -0700 From: Doug Ambrisko To: Richard Tector Subject: Re: Route next-hop interface behaviour Message-ID: <20130401205839.GA24595@ambrisko.com> References: <51588F43.7060609@tector.org.uk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="3uo+9/B/ebqu+fSQ" Content-Disposition: inline In-Reply-To: <51588F43.7060609@tector.org.uk> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 20:58:47 -0000 --3uo+9/B/ebqu+fSQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Mar 31, 2013 at 08:32:19PM +0100, Richard Tector wrote: | Hi, | | I'm not sure if it is expected behaviour but when configuring a static | route (default or otherwise) the outbound interface recorded in the | table does not update when the system's IP changes interface, even when | removing and re-adding it. | | Fairly simple topology, system running 9.1-STABLE (30th March) with just | one of four 'em' interfaces in use - em0 with 10.0.2.199. Default route | to 10.0.2.1. | | Whilst troubleshooting some odd TCP behaviour I thought I'd try a | different interface and so downed the active interface and brought up | one on a PCI card, and swapped the cable over: | | # ifconfig em0 down | # ifconfig em2 inet 10.0.2.199/24 | # ifconfig em2 up | | ##### | If I then ping an external host it shows as the destination network | being inaccessible: | | root@daffy:~ # ping 212.23.6.76 | PING 212.23.6.76 (212.23.6.76): 56 data bytes | ping: sendto: Network is down | | | ##### | Can contact the next hop just fine: | | root@daffy:~ # ping 10.0.2.1 | PING 10.0.2.1 (10.0.2.1): 56 data bytes | 64 bytes from 10.0.2.1: icmp_seq=0 ttl=64 time=0.211 ms | | | ##### | Routing table shows that the default route is still bound to em0 even | though the next hop is on em2: | | root@daffy:~ # netstat -rfinet -n | Routing tables | | Internet: | Destination Gateway Flags Refs Use Netif Expire | default 10.0.2.1 UGS 0 3141 em0 | ^^^ | 10.0.2.0/24 link#4 U 1 255 em2 | 10.0.2.199 link#1 UHS 1 0 lo0 | 127.0.0.1 link#9 UH 0 0 lo0 | | | ##### | Removing the default route and re-adding also leaves it on the old | interface: | | root@daffy:~ # route delete default | delete net default | root@daffy:~ # route add default 10.0.2.1 | add net default: gateway 10.0.2.1 | root@daffy:~ # netstat -rfinet -n | Routing tables | | Internet: | Destination Gateway Flags Refs Use Netif Expire | default 10.0.2.1 UGS 0 0 em0 | 10.0.2.0/24 link#4 U 0 688 em2 | 10.0.2.199 link#1 UHS 1 0 lo0 | 127.0.0.1 link#9 UH 0 0 lo0 | | I can understand the initial problem, but surely when I re-add the route | it should do a lookup against the table for the next hop, ie. | 10.0.2.0/24, and use the associated Netif? | | What's interesting is that if I remove the IP configuration from em0 it | removes the default route above (even though the interface is downed). | Re-adding the route works. You can try this patch: Index: net/if.c =================================================================== --- net/if.c (revision 248707) +++ net/if.c (working copy) @@ -1532,6 +1532,8 @@ IFNET_RLOCK_NOSLEEP(); TAILQ_FOREACH(ifp, &V_ifnet, if_link) { + if ((ifp->if_flags & IFF_UP) == 0) + continue; IF_ADDR_RLOCK(ifp); TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { if (ifa->ifa_addr->sa_family != addr->sa_family) @@ -1620,6 +1622,8 @@ IFNET_RLOCK_NOSLEEP(); TAILQ_FOREACH(ifp, &V_ifnet, if_link) { + if ((ifp->if_flags & IFF_UP) == 0) + continue; if ((ifp->if_flags & IFF_POINTOPOINT) == 0) continue; IF_ADDR_RLOCK(ifp); @@ -1672,6 +1676,8 @@ */ IFNET_RLOCK_NOSLEEP(); TAILQ_FOREACH(ifp, &V_ifnet, if_link) { + if ((ifp->if_flags & IFF_UP) == 0) + continue; IF_ADDR_RLOCK(ifp); TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { char *cp, *cp2, *cp3; Index: net/if_ethersubr.c =================================================================== --- net/if_ethersubr.c (revision 248707) +++ net/if_ethersubr.c (working copy) @@ -812,6 +871,11 @@ #if defined(NETATALK) struct llc *l; #endif + /* Discard packet if interface is not up */ + if ((ifp->if_flags & IFF_UP) == 0) { + m_freem(m); + return; + } KASSERT(ifp != NULL, ("%s: NULL interface pointer", __func__)); The issue is that the routing doesn't look to see if the NIC is up or not. It just looks at the IP address. So it tries to send it out the first matching NIC that could be down. Doug A. --3uo+9/B/ebqu+fSQ Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="up.patch" Index: net/if.c =================================================================== --- net/if.c (revision 248707) +++ net/if.c (working copy) @@ -1532,6 +1532,8 @@ IFNET_RLOCK_NOSLEEP(); TAILQ_FOREACH(ifp, &V_ifnet, if_link) { + if ((ifp->if_flags & IFF_UP) == 0) + continue; IF_ADDR_RLOCK(ifp); TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { if (ifa->ifa_addr->sa_family != addr->sa_family) @@ -1620,6 +1622,8 @@ IFNET_RLOCK_NOSLEEP(); TAILQ_FOREACH(ifp, &V_ifnet, if_link) { + if ((ifp->if_flags & IFF_UP) == 0) + continue; if ((ifp->if_flags & IFF_POINTOPOINT) == 0) continue; IF_ADDR_RLOCK(ifp); @@ -1672,6 +1676,8 @@ */ IFNET_RLOCK_NOSLEEP(); TAILQ_FOREACH(ifp, &V_ifnet, if_link) { + if ((ifp->if_flags & IFF_UP) == 0) + continue; IF_ADDR_RLOCK(ifp); TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { char *cp, *cp2, *cp3; Index: net/if_ethersubr.c =================================================================== --- net/if_ethersubr.c (revision 248707) +++ net/if_ethersubr.c (working copy) @@ -812,6 +871,11 @@ #if defined(NETATALK) struct llc *l; #endif + /* Discard packet if interface is not up */ + if ((ifp->if_flags & IFF_UP) == 0) { + m_freem(m); + return; + } KASSERT(ifp != NULL, ("%s: NULL interface pointer", __func__)); --3uo+9/B/ebqu+fSQ-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 2 00:22:50 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E047044A for ; Tue, 2 Apr 2013 00:22:50 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) by mx1.freebsd.org (Postfix) with ESMTP id A177A97F for ; Tue, 2 Apr 2013 00:22:50 +0000 (UTC) Received: by mail-vc0-f177.google.com with SMTP id ia10so2932978vcb.22 for ; Mon, 01 Apr 2013 17:22:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=5V+7QifvexrLSfh1vvunzCwao3Gx29YgHkxOTXm6V/c=; b=CNflfh9KyEYFLEZ8a0VHn+ImZrQxQ6AKhT4fF1jusdk3puZUUlDn8t99X2q0t6E0Dl 5yJAGfLbO5zAtLqtMXHcFpt6P54gu9GVwK8Q0ApKdU+B8Vh4OGd+r95sGaFwgi9+bRK2 mQT/P2vjTYj85dZsxHy8gXKCQs03BFMMQLV9O/WwvZf4SOK7i5/uP7bOD8WLIfFxtmc8 OIEDM0o6CH2UMZ4ylolHAMx4iWEGWn05gOJlDoHKBf3+TkZiaoaBtjjSrBLa4cm6DH5p Ef4EKL0+SEV26/89ObB3cW7BMy8ih+9eh62x9O1ETNQ3jCHirvvZym3hto+j8hulgvU6 kDGQ== MIME-Version: 1.0 X-Received: by 10.52.99.1 with SMTP id em1mr9375804vdb.48.1364862163844; Mon, 01 Apr 2013 17:22:43 -0700 (PDT) Received: by 10.52.176.131 with HTTP; Mon, 1 Apr 2013 17:22:43 -0700 (PDT) In-Reply-To: <5159AB72.1050202@gmail.com> References: <1355177348.71087.YahooMailClassic@web121601.mail.ne1.yahoo.com> <50C6656E.3020601@gmail.com> <20121211075853.GU48639@FreeBSD.org> <5159AB72.1050202@gmail.com> Date: Mon, 1 Apr 2013 17:22:43 -0700 Message-ID: Subject: Re: igb and ALTQ in 9.1-rc3 From: Nick Rogers To: Karim Fodil-Lemelin Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 00:22:50 -0000 On Mon, Apr 1, 2013 at 8:44 AM, Karim Fodil-Lemelin wrote: > Hi Jack, > > I think this would help M. Rogers case as we have done something similar > here to circumvent the issue and it seems to work well. I would also add > that when using ALTQ we found it much more stable to set the number of > queues to 1: > > static int igb_num_queues = 1; > > Our approach consisted in keeping igb_start() defined and using > igb_mq_start_locked() inside it instead of igb_start_locked(). > > Regards, > > Karim. Thanks for the pointer. I've been working with Jack to get a fix for this in that downgrades the stack to the older if_start/non-multiqueue interface. See the following two commits he made to HEAD. http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_igb.c?revision=248906&view=markup http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_igb.h?revision=248908&view=markup I've applied these changes to latest 9.1-STABLE src and included the IGB_LEGACY_TX in the e1000 Makefile. So far I am not having any luck getting pfctl to think igb is supported. i.e. I am still getting the following when loading my PF config: pfctl -f /etc/pf.conf pfctl: igb0: driver does not support altq Can anyone comment on if the above referenced changes that Jack made should be sufficient to get ALTQ working with igb? The error is coming from src/contrib/pf/pfctl/pfctl.c. There seems to be a function that checks if the driver is supported or not but I cannot figure out why the ioctl is not returning a device. Here is the device check code for reference: int pfctl_add_altq(struct pfctl *pf, struct pf_altq *a) { if (altqsupport && (loadopt & PFCTL_FLAG_ALTQ) != 0) { memcpy(&pf->paltq->altq, a, sizeof(struct pf_altq)); if ((pf->opts & PF_OPT_NOACTION) == 0) { if (ioctl(pf->dev, DIOCADDALTQ, pf->paltq)) { if (errno == ENXIO) errx(1, "qtype not configured"); else if (errno == ENODEV) errx(1, "%s: driver does not support " "altq", a->ifname); else err(1, "DIOCADDALTQ"); } } pfaltq_store(&pf->paltq->altq); } return (0); } > > > > On 28/03/2013 7:16 PM, Jack Vogel wrote: >> >> Have been kept fairly busy with other matters, one thing I could do short >> term is >> change the defines in igb the way I did in the em driver so you could >> still >> define >> the older if_start entry. Right now those are based on OS version and so >> you will >> automatically get if_transmit, but I could change it to be IGB_LEGACY_TX >> or >> so, >> and that could be defined in the Makefile. >> >> Would this help? >> >> Jack >> >> >> On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers wrote: >> >>> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel wrote: >>>> >>>> On Mon, Dec 10, 2012 at 11:58 PM, Gleb Smirnoff >>> >>> wrote: >>>>> >>>>> On Mon, Dec 10, 2012 at 03:31:19PM -0800, Jack Vogel wrote: >>>>> J> UH, maybe asking the owner of the driver would help :) >>>>> J> >>>>> J> ... and no, I've never been aware of doing anything to stop >>> >>> supporting >>>>> >>>>> altq >>>>> J> so you wouldn't see any commits. If there's something in the altq >>> >>> code >>>>> >>>>> or >>>>> J> support (which I have nothing to do with) that caused this no-one >>>>> informed >>>>> J> me. >>>>> >>>>> Switching from if_start to if_transmit effectively disables ALTQ >>> >>> support. >>>>> >>>>> AFAIR, there is some magic implemented in other drivers that makes them >>>>> modern (that means using if_transmit), but still capable to switch to >>>>> queueing >>>>> mode if SIOCADDALTQ was casted upon them. >>>>> >>>>> >>>> Oh, hmmm, I'll look into the matter after my vacation. >>>> >>>> Jack >>> >>> Has there been any progress on resolving this issue? I recently ran >>> into this problem upgrading my servers from 8.3 to 9.1-RELEASE and am >>> wondering what the latest recommendation is. I've used ALTQ and igb >>> successfully for years and it is unfortunate it no longer works. >>> Appreciate any advice. >>> >>>> _______________________________________________ >>>> 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" >> >> _______________________________________________ >> 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" > > > _______________________________________________ > 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" From owner-freebsd-net@FreeBSD.ORG Tue Apr 2 06:16:42 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D8F9C377; Tue, 2 Apr 2013 06:16:42 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by mx1.freebsd.org (Postfix) with ESMTP id 03607A41; Tue, 2 Apr 2013 06:16:41 +0000 (UTC) Received: by mail-lb0-f180.google.com with SMTP id t11so132688lbi.11 for ; Mon, 01 Apr 2013 23:16:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=XwIdg/PASth0kmGzCt9vNdSho6Y2PhU5OQHYZ6Y0ufc=; b=P5S3NVLAhqwOtrPyxYbwRDAOu4+Rb7LmABoL+4+fH0Sau2t0zcvAnvPLn/2xvN9J2K C24pO/gpSg8O9JOnqeEQXXnKRn6JvdMiFtFTlHSc47KFTd3KgYGIcjYX7AjlqUy5Gp47 AcNDoGtU89unCou08Dh3CXgxU4HFmjQrFuXfaaahAeU2XmmTKomjZOHluusexbL/hAhN Z3tIh/nMb+LK1zCn0HwCqec9zc6tLD0AaJ1W47dzupjt5ybhyEmmORrTFE5O2bfhMb+6 SrQk9Dxhv88AlLINB43YmifHH3FiKhAtyaaqZaENSTe0VaaRmWQ5ZPhD+2xlTvwEJvsd 0yeQ== MIME-Version: 1.0 X-Received: by 10.112.132.40 with SMTP id or8mr3788681lbb.119.1364883394617; Mon, 01 Apr 2013 23:16:34 -0700 (PDT) Received: by 10.114.48.102 with HTTP; Mon, 1 Apr 2013 23:16:34 -0700 (PDT) In-Reply-To: <51471974.3090300@freebsd.org> References: <5146121B.5080608@FreeBSD.org> <514649A5.4090200@freebsd.org> <3659B942-7C37-431F-8945-C8A5BCD8DC67@ipfw.ru> <51471974.3090300@freebsd.org> Date: Tue, 2 Apr 2013 14:16:34 +0800 Message-ID: Subject: Re: MPLS From: Sepherosa Ziehau To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 Cc: Sami Halabi , "Alexander V. Chernikov" , "Alexander V. Chernikov" , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 06:16:42 -0000 On Mon, Mar 18, 2013 at 9:41 PM, Andre Oppermann wrote: > On 18.03.2013 13:20, Alexander V. Chernikov wrote: >> >> On 17.03.2013, at 23:54, Andre Oppermann wrote: >> >>> On 17.03.2013 19:57, Alexander V. Chernikov wrote: >>>> >>>> On 17.03.2013 13:20, Sami Halabi wrote: >>>>>> >>>>>> ITOH OpenBSD has a complete implementation of MPLS out of the box, >>>>>> maybe >>>> >>>> Their control plane code is mostly useless due to design approach >>>> (routing daemons talk via kernel). >>> >>> >>> What's your approach? >> >> It is actually not mine. We have discussed this a bit in radix-related >> thread. Generally quagga/bird (and other hiperf hardware-accelerated and >> software routers) have feature-rich RIb from which best routes (possibly >> multipath) are installed to kernel/fib. Kernel main task should be to do >> efficient lookups while every other advanced feature should be implemented >> in userland. > > > Yes, we have started discussing it but haven't reached a conclusion among > the > two philosophies. We have also agreed that the current radix code is > horrible > in terms of cache misses per lookup. That however doesn't preclude an > agnostic > FIB+RIB approach. It's mostly a matter of structure layout to keep it > efficient. > > >>>> Their data plane code, well.. Yes, we can use some defines from their >>>> headers, but that's all :) >>>>>> >>>>>> porting it would be short and more straight forward than porting linux >>>>>> LDP >>>>>> implementation of BIRD. >>>> >>>> >>>> It is not 'linux' implementation. LDP itself is cross-platform. >>>> The most tricky place here is control plane. >>>> However, making _fast_ MPLS switching is tricky too, since it requires >>>> chages in our netisr/ethernet >>>> handling code. >>> >>> >>> Can you explain what changes you think are necessary and why? > >> >> >> We definitely need ability to dispatch chain of mbufs - this was already >> discussed in intel rx ring lock thread in -net. > > > Actually I'm not so convinced of that. Packet handling is a tradeoff > between > doing process-to-completion on each packet and doing context switches on > batches > of packets. > > Every few years the balance tilts forth and back between > process-to-completion > and batch processing. DragonFly went with a batch-lite token-passing > approach > throughout their kernel. It seems it didn't work out to the extent they > expected. > Now many parts are moving back to the more traditional locking approach. At least, the per-CPU netisr and other related per-CPU network stuffs (e.g. routing table) work quite well as we have _expected_ (the measured bi-directional IPv4 forwarding performance w/ fastforwarding is 5.6Mpps+, w/o fastforwarding 4.6Mpps+, w/ 4 igb(4) on i7-2600, using 90% cpu time on each HT in Dfly's polling(4) mode); it is _not_ using traditional locking approach on major network paths at all and for IPv4 forwarding Dfly is _not_ doing "process-to-completion". And as a side note: There was a paper compared the message-based parallelism TCP implementation, connection-based thread serialization TCP implementaion (Dfly is using) and connection-based lock serialization TCP implementation. The conclusion was connection-based thread serialization TCP implementation (Dfly is using) had too many scheduling cost. The paper's conclusion _no longer_ holds for Dfly nowadays; we have wiped out major scheduling cost on the hot TCP paths. So as far as I could see, its _not_ the problem of the model itself sometimes, but how the model should be implemented. Best Regards, sephe -- Tomorrow Will Never Die From owner-freebsd-net@FreeBSD.ORG Tue Apr 2 07:29:49 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1E486B6 for ; Tue, 2 Apr 2013 07:29:49 +0000 (UTC) (envelope-from nl@ecanode.com) Received: from qmail3.webindia.com (qmail3.webindia.com [67.218.96.133]) by mx1.freebsd.org (Postfix) with ESMTP id ED250D06 for ; Tue, 2 Apr 2013 07:29:48 +0000 (UTC) Received: (qmail 21094 invoked by uid 89); 2 Apr 2013 07:32:07 -0000 Received: from unknown (HELO TIANODE) (ewhizs@tiaanosoft.com@67.218.96.216) by qmail3.webindia.com with ESMTPA; 2 Apr 2013 07:32:07 -0000 From: nl@ecanode.com To: freebsd-net@freebsd.org Date: 2 Apr 2013 00:28:41 -0700 Subject: Sea Water Electrolyzer for Electro-Chlorination Message-Id: <20130402072949.1E486B6@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: nl@ecanode.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 07:29:49 -0000 [1]If you can't view this mail click here.. [2] 2011111721370email.jpg __________________________________________________________________ [3]Unsubscribeme! [4]Update Email Address! This email sent to freebsd-net@freebsd.org by [5]nl@ecanode.com Powered by [6][elogo1.jpg] References 1. http://www.ewhizs.com/Preview.aspx?nno=MTAw-T%2f3%2fcheYTl4%3d&mem=14 2. http://www.ecanode.com/ 3. http://www.ewhizs.com/unsubscribeme.aspx?ee=ZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmc%3d-hJ92ptlVoGg%3d&mem=14 4. http://www.ewhizs.com/updat.aspx?ee=ZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmc%3d-hJ92ptlVoGg%3d&mem=14 5. mailto:%20nl@ecanode.com 6. http://www.tiaanosoft.com/ From owner-freebsd-net@FreeBSD.ORG Tue Apr 2 09:20:26 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C120FF87 for ; Tue, 2 Apr 2013 09:20:26 +0000 (UTC) (envelope-from Jean@femrice.com) Received: from mail.mail72.cn4e.com (mail.mail72.cn4e.com [218.107.207.72]) by mx1.freebsd.org (Postfix) with ESMTP id 6E390282 for ; Tue, 2 Apr 2013 09:20:25 +0000 (UTC) Received: from WK (localhost.localdomain [127.0.0.1]) by mail.mail72.cn4e.com (Postfix) with SMTP id 65D8160021D for ; Tue, 2 Apr 2013 17:20:23 +0800 (CST) Received: from WK (unknown [218.11.179.167]) by mail.mail72.cn4e.com (Postfix) with ESMTPA for ; Tue, 2 Apr 2013 17:20:23 +0800 (CST) Date: Tue, 2 Apr 2013 17:20:26 +0800 From: Jean To: freebsd-net Subject: SFP/SFP+ , PCI Express Gigabit Ethernet NIC Card supplier, 10G NIC, Server Adapter Intel chipsets X-Priority: 3 X-Message-Flag: =?gb2312?B?x+u72Li0?= X-GUID: 588EE3E1-1BFE-4329-A850-80000EA919D0 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2013040217202471867312@femrice.com> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Jean List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 09:20:26 -0000 SGVsbG8sDQoNCg0KSSBhbSBqZWFuIGFuZCB2ZXJ5IGdsYWQgdG8ga25vdyB5b3UgZnJvbSBHb29n bGUgd2Vic2l0ZSAuQ2hlY2tlZCB5b3VyIHdlYnNpdGUgYW5kIG1heWJlIHlvdXIgY3VzdG9tZXIg bmVlZCBvdXIgDQoNCnByb2R1Y3RzIHNvIFdyaXRlIHRvIHlvdSBhbmQgdGFsayBhYm91dCB3aGV0 aGVyIHdlIGNvdWxkIGNvb3BlcmF0ZSB3aXRoIGVhY2ggb3RoZXIgaW4gdGhlIGZ1cnRoZXIgLg0K DQoNCndlIGFyZSB0aGUgbWFudWZhY3R1cmVyIG9mIFBDSSBFeHByZXNzIDFHICYxMEcgRXRoZXJu ZXQgTklDIENhcmQoU2VydmVyIEFkYXB0ZXIgTklDIENhcmRzKSxJbnRlbCBjaGlwc2V0cywgT3Vy IA0KDQpGZW1yaWNlIGJyYW5kIC5DRSxGQyxST0hTLCBTdG9jaywgbGlmZXRpbWUgd2FycmFudHku VmVyeSBnb29kIHByaWNlIGluIHRoZSBtYXJrZXQuIA0KDQoNCndlIGFsc28gc3VwcGx5IFNGUCAs U0ZQKyxYRlAgYW5kIG90aGVyIHNwZWNpYWwgbW9kdWxlcyAuDQoNCg0KVGhlIEZvbGxvd2luZyBv bmUgaXMgb3VyIG1haW5seSBOSUMgQ2FyZHM6DQoNCg0KRmliZXIgY2FyZHMgOg0KDQoNCjEuIFBD SSBFeHByZXNzKHg0LykgRHVhbCBQb3J0IEdpZ2FiaXQgRXRoZXJuZXQgTklDIENhcmQsIEZpYmVy IE5JQyBDYXJkICwgU0ZQIFNsb3QgLExDLCBJbnRlbDgyNTcxRUIgQ2hpcHNldCBjb250cm9sbGVy ICwgVHlwZSBOdW1iZXIgOiAxMDAwMlBGDQoNCg0KMi4gUENJIEV4cHJlc3MgKHg0KSBEdWFsIFBv cnQgR2lnYWJpdCBFdGhlcm5ldCBOSUMgQ2FyZCwgRmliZXIgTklDIENhcmQgLFNGUCBTbG90ICxM QywgSW50ZWw4MjU3NkVCIENoaXBzZXQgY29udHJvbGxlciAsICBUeXBlIE51bWJlciA6IDEwMDAy RUYNCg0KDQozLlBDSSBFeHByZXNzKHg0KSAgRHVhbCBQb3J0IEdpZ2FiaXQgRXRoZXJuZXQgTklD IENhcmQsIEZpYmVyIE5JQyBDYXJkICxTRlAgU2xvdCAsTEMsIEludGVsODI1ODBEQkNoaXBzZXQg Y29udHJvbGxlciAsICBUeXBlIE51bWJlciA6IDFHMkRCNTgwLVNGUA0KDQoNCjQuIFBDSSBFeHBy ZXNzICh4NCkgU2luZ2xlIFBvcnQgR2lnYWJpdCBFdGhlcm5ldCBOSUMgQ2FyZCwgRmliZXIgTklD IENhcmQgLFNGUCBTbG90ICxMQywgSW50ZWw4MjU3MkVJIENoaXBzZXQgY29udHJvbGxlciAsICBU eXBlIE51bWJlciA6IDEwMDAxUEYNCg0KDQo1LiBQQ0kgRXhwcmVzcyAoeDEpIFNpbmdsZSBQb3J0 IEdpZ2FiaXQgRXRoZXJuZXQgTklDIENhcmQsIEZpYmVyIE5JQyBDYXJkICxTRlAgU2xvdCAsTEMs IEludGVsODI1ODMgQ2hpcHNldCBjb250cm9sbGVyICwgIFR5cGUgTnVtYmVyIDogMUdQRjU4My1T RlANCg0KDQo2LlBDSSBFeHByZXNzICh4OCkgRHVhbCBQb3J0IDEwRyBFdGhlcm5ldCBOSUMgQ2Fy ZCwgRmliZXIgTklDIENhcmQgLFNGUCBTbG90ICxMQywgSW50ZWw4MjU5OUVTIENoaXBzZXQgY29u dHJvbGxlciAsICBUeXBlIE51bWJlciA6IDEwRzJCRi1TRlArDQoNCg0KNy4gUENJIEV4cHJlc3Mo eDQvKSBEdWFsIFBvcnQvU2luZ2xlIFBvcnQgR2lnYWJpdCBFdGhlcm5ldCBOSUMgQ2FyZCwgRmli ZXIgLCBTRlAgU2xvdCAsTEMsIEludGVsODI1NzFFQiBDaGlwc2V0IGNvbnRyb2xsZXIgLCBqdXN0 IFRyYW5zbWlzc2l2ZSBubyANCg0KcmVjZWl2ZXIgZnVuY3Rpb25zIFR5cGUgTnVtYmVyIDogMUcy QkY1NzEtVFggKE1haW5seSB1c2VkIGluIFVuaS1kaXJlY3Rpb25hbCBHQVAgKQ0KDQoNCjguUENJ IEV4cHJlc3MoeDQvKSBEdWFsIFBvcnQvU2luZ2xlIFBvcnQgR2lnYWJpdCBFdGhlcm5ldCBOSUMg Q2FyZCwgRmliZXIgLCBTRlAgU2xvdCAsTEMsIEludGVsODI1NzFFQiBDaGlwc2V0IGNvbnRyb2xs ZXIgLCBqdXN0IFJlY2VpdmVyIG5vIA0KDQp0cmFuc21pc3Npb24gZnVuY3Rpb25zIFR5cGUgTnVt YmVyIDogMUcyQkY1NzEtUlggKE1haW5seSB1c2VkIGluIFVuaS1kaXJlY3Rpb25hbCBHQVAgKQ0K DQoNCg0KUGx6IHJlcGx5IHRvIG1lIGlmIHlvdSBhcmUgaW50ZXJlc3RlZCBpbiBvdXIgUHJvZHVj dHMgLg0KDQoNCkhvcGUgd2UgaGF2ZSBjaGFuY2UgdG8gY29vcGVyYXRlIHdpdGggZWFjaCBvdGhl ciBpbiB0aGUgZnVydGhlciAuDQoNCg0KSWYgeW91IGhhdmUgU2t5cGUgb3IgTVNOIElEIGlzIG1v cmUgYmV0dGVyICxNeSBza3lwZSA6IERyZWFtLWZseTk5DQoNCg0KQmVzdCBSZWdhcmRzDQoNCg0K SmVhbiBoZW5nDQoNCg0KRmVtcmljZSAoQ2hpbmEpIFRlY2hub2xvZ3kgQ28uLCBMdGQuDQoNCg0K VGVsOjAwODYtMTAtNTEyNjY4MDctODEzIA0KDQoNCk1vYmlsZTowMDg2LTEzMDAxMDIzNjE1DQoN Cg0KRmF4OiAwMDg2LTEwLTYyOTc5MzQzDQoNCg0KRW1haWw6IEplYW5AZmVtcmljZS5jb20gDQoN Cg0KV2Vic2l0ZXM6IGh0dHA6Ly93d3cuZXRoZXJuZXRzZXJ2ZXJhZGFwdGVyLmNvbS8NCiAgICAg ICAgICB3d3cuZmVtcmljZS5jb20gDQoNCg0KU2t5cGU6IERyZWFtLWZseTk5DQoNCg0KTVNOOiBE cmVhbS1mbHk5OUBIb3RtYWlsLmNvbQ== From owner-freebsd-net@FreeBSD.ORG Tue Apr 2 13:01:54 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 758405CE; Tue, 2 Apr 2013 13:01:54 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by mx1.freebsd.org (Postfix) with ESMTP id 4576613F; Tue, 2 Apr 2013 13:01:54 +0000 (UTC) Received: by mail-pb0-f53.google.com with SMTP id un15so227143pbc.40 for ; Tue, 02 Apr 2013 06:01:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=zZEydzkkzeTMv1LAKcwI8cxUO69QGnm9d0gcm2iQgvI=; b=GBEEs9p1we6ux8ojpxDb8CL4lMYfEcTE5jnKNJivdynOrfh4wIL5bFWjOYE9Dv/UzX c3MvJEc4kNSkbuiLQHrijVIdapQ7ktUYWhtaKiymw9EkMpTezkqHds1mICBsvHGwoZuN +CHJPoY2CCinUqAvKkh2MbrDfzvLak4N/HTiL9a/5+mK1R9jon7aPcjwi5inUJ8BCFqt S5p8r6fSaDuGW7pnmvsuf5I0Sng6HGZTz/yM8yGxD7gJemJV8uqoN4MCZ1cZdWhVau1+ 8Q69hpoKXXWBvqG4f8aLPfwo9KJUi+yvjmi1C5buGY54kZNHxdsurhjJHvwJnfXwTk3I vJ7w== MIME-Version: 1.0 X-Received: by 10.68.243.98 with SMTP id wx2mr24531069pbc.68.1364907707855; Tue, 02 Apr 2013 06:01:47 -0700 (PDT) Received: by 10.70.34.103 with HTTP; Tue, 2 Apr 2013 06:01:47 -0700 (PDT) In-Reply-To: References: <5146121B.5080608@FreeBSD.org> <514649A5.4090200@freebsd.org> <3659B942-7C37-431F-8945-C8A5BCD8DC67@ipfw.ru> <51471974.3090300@freebsd.org> Date: Tue, 2 Apr 2013 16:01:47 +0300 Message-ID: Subject: Re: MPLS From: Sami Halabi To: Sepherosa Ziehau Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "Alexander V. Chernikov" , Andre Oppermann , "Alexander V. Chernikov" , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 13:01:54 -0000 >At least, the per-CPU netisr and other related per-CPU network stuffs >(e.g. routing table) work quite well as we have _expected_ (the >measured bi-directional IPv4 forwarding performance w/ fastforwarding >is 5.6Mpps+, w/o fastforwarding 4.6Mpps+ are you talking about the work Luigi did with Netmap? or performance out of the box in GENERIC? Sami On Tue, Apr 2, 2013 at 9:16 AM, Sepherosa Ziehau wrote: > On Mon, Mar 18, 2013 at 9:41 PM, Andre Oppermann > wrote: > > On 18.03.2013 13:20, Alexander V. Chernikov wrote: > >> > >> On 17.03.2013, at 23:54, Andre Oppermann wrote: > >> > >>> On 17.03.2013 19:57, Alexander V. Chernikov wrote: > >>>> > >>>> On 17.03.2013 13:20, Sami Halabi wrote: > >>>>>> > >>>>>> ITOH OpenBSD has a complete implementation of MPLS out of the box, > >>>>>> maybe > >>>> > >>>> Their control plane code is mostly useless due to design approach > >>>> (routing daemons talk via kernel). > >>> > >>> > >>> What's your approach? > >> > >> It is actually not mine. We have discussed this a bit in radix-related > >> thread. Generally quagga/bird (and other hiperf hardware-accelerated and > >> software routers) have feature-rich RIb from which best routes (possibly > >> multipath) are installed to kernel/fib. Kernel main task should be to do > >> efficient lookups while every other advanced feature should be > implemented > >> in userland. > > > > > > Yes, we have started discussing it but haven't reached a conclusion among > > the > > two philosophies. We have also agreed that the current radix code is > > horrible > > in terms of cache misses per lookup. That however doesn't preclude an > > agnostic > > FIB+RIB approach. It's mostly a matter of structure layout to keep it > > efficient. > > > > > >>>> Their data plane code, well.. Yes, we can use some defines from their > >>>> headers, but that's all :) > >>>>>> > >>>>>> porting it would be short and more straight forward than porting > linux > >>>>>> LDP > >>>>>> implementation of BIRD. > >>>> > >>>> > >>>> It is not 'linux' implementation. LDP itself is cross-platform. > >>>> The most tricky place here is control plane. > >>>> However, making _fast_ MPLS switching is tricky too, since it requires > >>>> chages in our netisr/ethernet > >>>> handling code. > >>> > >>> > >>> Can you explain what changes you think are necessary and why? > > > >> > >> > >> We definitely need ability to dispatch chain of mbufs - this was already > >> discussed in intel rx ring lock thread in -net. > > > > > > Actually I'm not so convinced of that. Packet handling is a tradeoff > > between > > doing process-to-completion on each packet and doing context switches on > > batches > > of packets. > > > > Every few years the balance tilts forth and back between > > process-to-completion > > and batch processing. DragonFly went with a batch-lite token-passing > > approach > > throughout their kernel. It seems it didn't work out to the extent they > > expected. > > Now many parts are moving back to the more traditional locking approach. > > At least, the per-CPU netisr and other related per-CPU network stuffs > (e.g. routing table) work quite well as we have _expected_ (the > measured bi-directional IPv4 forwarding performance w/ fastforwarding > is 5.6Mpps+, w/o fastforwarding 4.6Mpps+, w/ 4 igb(4) on i7-2600, > using 90% cpu time on each HT in Dfly's polling(4) mode); it is _not_ > using traditional locking approach on major network paths at all and > for IPv4 forwarding Dfly is _not_ doing "process-to-completion". > > And as a side note: There was a paper compared the message-based > parallelism TCP implementation, connection-based thread serialization > TCP implementaion (Dfly is using) and connection-based lock > serialization TCP implementation. The conclusion was connection-based > thread serialization TCP implementation (Dfly is using) had too many > scheduling cost. The paper's conclusion _no longer_ holds for Dfly > nowadays; we have wiped out major scheduling cost on the hot TCP > paths. So as far as I could see, its _not_ the problem of the model > itself sometimes, but how the model should be implemented. > > Best Regards, > sephe > > -- > Tomorrow Will Never Die > -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert From owner-freebsd-net@FreeBSD.ORG Tue Apr 2 13:19:14 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0364FBAD for ; Tue, 2 Apr 2013 13:19:14 +0000 (UTC) (envelope-from fodillemlinkarim@gmail.com) Received: from mail-ia0-x22f.google.com (mail-ia0-x22f.google.com [IPv6:2607:f8b0:4001:c02::22f]) by mx1.freebsd.org (Postfix) with ESMTP id C45301F3 for ; Tue, 2 Apr 2013 13:19:13 +0000 (UTC) Received: by mail-ia0-f175.google.com with SMTP id e16so305481iaa.34 for ; Tue, 02 Apr 2013 06:19:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=olx90bvkItxoosMhqetXTgxaFWA8gBX9mwPq9k6xSGQ=; b=oy3rqH6pSBLfMJApwAvOjkBAYAxn+WsMXBNPfMuSoUP8KRxwDQHlxeCuI3IpxhqOZw xwHITnWnN6cjmptAyxOl82MWM166V0+CQkj2E2H4ePdpJnnm3P8sYkLHKIO6OFfvNbbk 5ucLhz3ucq8Fin6e8ekmnNSBhMWpGLihMtNGqAs8Et9sm7Cm9NOOaFp4uuO3KkL9OyK/ QrBKNdYqjtylYr5HLNGpaMMLzdazF/zniVrliNYRGGaoha/uDLS93EKVVVYHEEqYglum YZzymfzBbwuTmCkdB5qoH45SUHQVv/WKbs8lKPGDm3UBlvBL4sMXi8BxI/cbOYUa7oMi ZPMA== X-Received: by 10.50.183.233 with SMTP id ep9mr5160279igc.87.1364908753395; Tue, 02 Apr 2013 06:19:13 -0700 (PDT) Received: from [192.168.1.73] ([208.85.112.101]) by mx.google.com with ESMTPS id px9sm5446742igc.0.2013.04.02.06.19.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Apr 2013 06:19:11 -0700 (PDT) Message-ID: <515ADACD.8010108@gmail.com> Date: Tue, 02 Apr 2013 09:19:09 -0400 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Nick Rogers Subject: Re: igb and ALTQ in 9.1-rc3 References: <1355177348.71087.YahooMailClassic@web121601.mail.ne1.yahoo.com> <50C6656E.3020601@gmail.com> <20121211075853.GU48639@FreeBSD.org> <5159AB72.1050202@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 13:19:14 -0000 Hi Nick, Can you verify that you have at least one of those options in your kernel config file: ALTQ_CBQ ALTQ_PRIQ ALTQ_HFSC Regards, Karim. On 01/04/2013 8:22 PM, Nick Rogers wrote: > On Mon, Apr 1, 2013 at 8:44 AM, Karim Fodil-Lemelin > wrote: >> Hi Jack, >> >> I think this would help M. Rogers case as we have done something similar >> here to circumvent the issue and it seems to work well. I would also add >> that when using ALTQ we found it much more stable to set the number of >> queues to 1: >> >> static int igb_num_queues = 1; >> >> Our approach consisted in keeping igb_start() defined and using >> igb_mq_start_locked() inside it instead of igb_start_locked(). >> >> Regards, >> >> Karim. > Thanks for the pointer. > > I've been working with Jack to get a fix for this in that downgrades > the stack to the older if_start/non-multiqueue interface. See the > following two commits he made to HEAD. > > http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_igb.c?revision=248906&view=markup > http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_igb.h?revision=248908&view=markup > > I've applied these changes to latest 9.1-STABLE src and included the > IGB_LEGACY_TX in the e1000 Makefile. So far I am not having any luck > getting pfctl to think igb is supported. > > i.e. I am still getting the following when loading my PF config: > pfctl -f /etc/pf.conf > pfctl: igb0: driver does not support altq > > Can anyone comment on if the above referenced changes that Jack made > should be sufficient to get ALTQ working with igb? > > The error is coming from src/contrib/pf/pfctl/pfctl.c. There seems to > be a function that checks if the driver is supported or not but I > cannot figure out why the ioctl is not returning a device. > > Here is the device check code for reference: > > int > pfctl_add_altq(struct pfctl *pf, struct pf_altq *a) > { > if (altqsupport && > (loadopt & PFCTL_FLAG_ALTQ) != 0) { > memcpy(&pf->paltq->altq, a, sizeof(struct pf_altq)); > if ((pf->opts & PF_OPT_NOACTION) == 0) { > if (ioctl(pf->dev, DIOCADDALTQ, pf->paltq)) { > if (errno == ENXIO) > errx(1, "qtype not configured"); > else if (errno == ENODEV) > errx(1, "%s: driver does not support " > "altq", a->ifname); > else > err(1, "DIOCADDALTQ"); > } > } > pfaltq_store(&pf->paltq->altq); > } > return (0); > } > > > >> >> >> On 28/03/2013 7:16 PM, Jack Vogel wrote: >>> Have been kept fairly busy with other matters, one thing I could do short >>> term is >>> change the defines in igb the way I did in the em driver so you could >>> still >>> define >>> the older if_start entry. Right now those are based on OS version and so >>> you will >>> automatically get if_transmit, but I could change it to be IGB_LEGACY_TX >>> or >>> so, >>> and that could be defined in the Makefile. >>> >>> Would this help? >>> >>> Jack >>> >>> >>> On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers wrote: >>> >>>> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel wrote: >>>>> On Mon, Dec 10, 2012 at 11:58 PM, Gleb Smirnoff >>>> wrote: >>>>>> On Mon, Dec 10, 2012 at 03:31:19PM -0800, Jack Vogel wrote: >>>>>> J> UH, maybe asking the owner of the driver would help :) >>>>>> J> >>>>>> J> ... and no, I've never been aware of doing anything to stop >>>> supporting >>>>>> altq >>>>>> J> so you wouldn't see any commits. If there's something in the altq >>>> code >>>>>> or >>>>>> J> support (which I have nothing to do with) that caused this no-one >>>>>> informed >>>>>> J> me. >>>>>> >>>>>> Switching from if_start to if_transmit effectively disables ALTQ >>>> support. >>>>>> AFAIR, there is some magic implemented in other drivers that makes them >>>>>> modern (that means using if_transmit), but still capable to switch to >>>>>> queueing >>>>>> mode if SIOCADDALTQ was casted upon them. >>>>>> >>>>>> >>>>> Oh, hmmm, I'll look into the matter after my vacation. >>>>> >>>>> Jack >>>> Has there been any progress on resolving this issue? I recently ran >>>> into this problem upgrading my servers from 8.3 to 9.1-RELEASE and am >>>> wondering what the latest recommendation is. I've used ALTQ and igb >>>> successfully for years and it is unfortunate it no longer works. >>>> Appreciate any advice. >>>> >>>>> _______________________________________________ >>>>> 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" >>> _______________________________________________ >>> 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" >> >> _______________________________________________ >> 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" From owner-freebsd-net@FreeBSD.ORG Tue Apr 2 13:58:23 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CDD2E6B0 for ; Tue, 2 Apr 2013 13:58:23 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-ve0-f172.google.com (mail-ve0-f172.google.com [209.85.128.172]) by mx1.freebsd.org (Postfix) with ESMTP id 8CF82629 for ; Tue, 2 Apr 2013 13:58:23 +0000 (UTC) Received: by mail-ve0-f172.google.com with SMTP id oz10so499069veb.17 for ; Tue, 02 Apr 2013 06:58:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0T+M2Neah+7t69AaKWXPMbwZ8X60jlpmAh6tzbCu2xs=; b=eS3tRw0NuvQL9oimDzh2t9k1D04Bdr2pW2U1SsPOAUmDvZALPFDgqfeZNMFiVsNSwc 9FmoWT5JTVjTFjyeRN9Wwgmbg228XASeZ1T2mbIk5LYvbhn4Q3fspsTZgIQmvBBTtpL7 18FcOEBbcxTMhC76RoC8CYIKZX1HMbDde/4uoFJVuEkAgW+nnkoHBJF4hhuLhkUro2WA Jx2R59Ss0VBkOB85sL9qTe0fQAPFpWYBQrRs/P3pVox5PrWEYrUiK3k0dt2ZTSbmbQfP FirzO7+S3Ei7/W2LGxspk9cl8jJdKNjbprpEcYxl/XgawaZbPJe/BjvT1mKSKKjBgpRR imvw== MIME-Version: 1.0 X-Received: by 10.52.19.200 with SMTP id h8mr6989233vde.60.1364911102798; Tue, 02 Apr 2013 06:58:22 -0700 (PDT) Received: by 10.52.176.131 with HTTP; Tue, 2 Apr 2013 06:58:22 -0700 (PDT) In-Reply-To: <515ADACD.8010108@gmail.com> References: <1355177348.71087.YahooMailClassic@web121601.mail.ne1.yahoo.com> <50C6656E.3020601@gmail.com> <20121211075853.GU48639@FreeBSD.org> <5159AB72.1050202@gmail.com> <515ADACD.8010108@gmail.com> Date: Tue, 2 Apr 2013 06:58:22 -0700 Message-ID: Subject: Re: igb and ALTQ in 9.1-rc3 From: Nick Rogers To: Karim Fodil-Lemelin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 13:58:23 -0000 On Tuesday, April 2, 2013, Karim Fodil-Lemelin wrote: > Hi Nick, > > Can you verify that you have at least one of those options in your kernel > config file: > > ALTQ_CBQ > ALTQ_PRIQ > ALTQ_HFSC Yes I have hfsc included in the kernel. I have other machines using altq with em(4) interfaces and similar pf configurations on the same kernel that work fine. > Regards, > > Karim. > > On 01/04/2013 8:22 PM, Nick Rogers wrote: > > On Mon, Apr 1, 2013 at 8:44 AM, Karim Fodil-Lemelin > wrote: > > Hi Jack, > > I think this would help M. Rogers case as we have done something similar > here to circumvent the issue and it seems to work well. I would also add > that when using ALTQ we found it much more stable to set the number of > queues to 1: > > static int igb_num_queues = 1; > > Our approach consisted in keeping igb_start() defined and using > igb_mq_start_locked() inside it instead of igb_start_locked(). > > Regards, > > Karim. > > Thanks for the pointer. > > I've been working with Jack to get a fix for this in that downgrades > the stack to the older if_start/non-multiqueue interface. See the > following two commits he made to HEAD. > > http://svnweb.freebsd.org/**base/head/sys/dev/e1000/if_** > igb.c?revision=248906&view=**markup > http://svnweb.freebsd.org/**base/head/sys/dev/e1000/if_** > igb.h?revision=248908&view=**markup > > I've applied these changes to latest 9.1-STABLE src and included the > IGB_LEGACY_TX in the e1000 Makefile. So far I am not having any luck > getting pfctl to think igb is supported. > > i.e. I am still getting the following when loading my PF config: > pfctl -f /etc/pf.conf > pfctl: igb0: driver does not support altq > > Can anyone comment on if the above referenced changes that Jack made > should be sufficient to get ALTQ working with igb? > > The error is coming from src/contrib/pf/pfctl/pfctl.c. There seems to > be a function that checks if the driver is supported or not but I > cannot figure out why the ioctl is not returning a device. > > Here is the device check code for reference: > > int > pfctl_add_altq(struct pfctl *pf, struct pf_altq *a) > { > if (altqsupport && > (loadopt & PFCTL_FLAG_ALTQ) != 0) { > memcpy(&pf->paltq->altq, a, sizeof(struct pf_altq)); > if ((pf->opts & PF_OPT_NOACTION) == 0) { > if (ioctl(pf->dev, DIOCADDALTQ, pf->paltq)) { > if (errno == ENXIO) > errx(1, "qtype not configured"); > else if (errno == ENODEV) > errx(1, "%s: driver does not > support " > "altq", a->ifname); > else > err(1, "DIOCADDALTQ"); > } > } > pfaltq_store(&pf->paltq->altq)**; > } > return (0); > } > > > > > > On 28/03/2013 7:16 PM, Jack Vogel wrote: > > Have been kept fairly busy with other matters, one thing I could do short > term is > change the defines in igb the way I did in the em driver so you could > still > define > the older if_start entry. Right now those are based on OS version and so > you will > automatically get if_transmit, but I could change it to be IGB_LEGACY_TX > or > so, > and that could be defined in the Makefile. > > Would this help? > > Jack > > > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers wrote: > > On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel wrote: > > On Mon, Dec 10, 2012 at 11:58 PM, Gleb Smirnoff > > wrote: > > On Mon, Dec 10, 2012 at 03:31:19PM -0800, Jack Vogel wrote: > J> UH, maybe asking the owner of the driver would help :) > J> > J> ... and no, I've never been aware of doing anything to stop > > supporting > > From owner-freebsd-net@FreeBSD.ORG Tue Apr 2 14:20:39 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3BD94E75 for ; Tue, 2 Apr 2013 14:20:39 +0000 (UTC) (envelope-from fodillemlinkarim@gmail.com) Received: from mail-ia0-x229.google.com (mail-ia0-x229.google.com [IPv6:2607:f8b0:4001:c02::229]) by mx1.freebsd.org (Postfix) with ESMTP id 0AE11710 for ; Tue, 2 Apr 2013 14:20:39 +0000 (UTC) Received: by mail-ia0-f169.google.com with SMTP id j5so361393iaf.28 for ; Tue, 02 Apr 2013 07:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KH17o1JDcY1kYx2HZQjO3slw7Ug2eIN9sMQ7GWrkyZI=; b=GlAwS2nmuC5saCkzfq07Ik68uj1EUsw/9Lp7utIUL1sAVMIzq88n3mriOkP+sPyUcM /MvfnFr8JszuEzcZ4Wrj3VvJdBIEZHnixExmojO+K4Qhw8gqFtp7S+nSuFGXPSYpq81V +WQroSmwPOG6D8aqnTKSWoUpAtciWrhpSxsrqsMoAof0T7CZy4HqgQOfUv2ZXbyfQikl 2ROvlTCxqP98YVtaYcv1LU4bmzMshfjw8bQXuYPBBRzXZGu6xwHLYGI7vddgU2bmdbKv tC4AcTPE5TJQOHEz2UTi/Mz1nVwml5sA2iG6Co/C3puDrn964+w9GBN1WYMng0JyFGll WDLg== X-Received: by 10.50.150.167 with SMTP id uj7mr5316473igb.1.1364912438578; Tue, 02 Apr 2013 07:20:38 -0700 (PDT) Received: from [192.168.1.73] ([208.85.112.101]) by mx.google.com with ESMTPS id ur12sm622356igb.8.2013.04.02.07.20.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Apr 2013 07:20:37 -0700 (PDT) Message-ID: <515AE933.7020806@gmail.com> Date: Tue, 02 Apr 2013 10:20:35 -0400 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Nick Rogers Subject: Re: igb and ALTQ in 9.1-rc3 References: <1355177348.71087.YahooMailClassic@web121601.mail.ne1.yahoo.com> <50C6656E.3020601@gmail.com> <20121211075853.GU48639@FreeBSD.org> <5159AB72.1050202@gmail.com> <515ADACD.8010108@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 14:20:39 -0000 Hi Nick, You need to set the ALTQF_READY flag inside the igb driver. Make sure you have something like this in if_igb.c: ifp->if_start = igb_start; IFQ_SET_MAXLEN(&ifp->if_snd, adapter->num_tx_desc - 1); ifp->if_snd.ifq_drv_maxlen = adapter->num_tx_desc - 1; IFQ_SET_READY(&ifp->if_snd); The call to IFQ_SET_READY() is what will enable ALTQ on your device. Regards, Karim. On 02/04/2013 9:58 AM, Nick Rogers wrote: > On Tuesday, April 2, 2013, Karim Fodil-Lemelin wrote: > >> Hi Nick, >> >> Can you verify that you have at least one of those options in your kernel >> config file: >> >> ALTQ_CBQ >> ALTQ_PRIQ >> ALTQ_HFSC > > Yes I have hfsc included in the kernel. I have other machines using altq > with em(4) interfaces and similar pf configurations on the same kernel that > work fine. > > >> Regards, >> >> Karim. >> >> On 01/04/2013 8:22 PM, Nick Rogers wrote: >> >> On Mon, Apr 1, 2013 at 8:44 AM, Karim Fodil-Lemelin >> wrote: >> >> Hi Jack, >> >> I think this would help M. Rogers case as we have done something similar >> here to circumvent the issue and it seems to work well. I would also add >> that when using ALTQ we found it much more stable to set the number of >> queues to 1: >> >> static int igb_num_queues = 1; >> >> Our approach consisted in keeping igb_start() defined and using >> igb_mq_start_locked() inside it instead of igb_start_locked(). >> >> Regards, >> >> Karim. >> >> Thanks for the pointer. >> >> I've been working with Jack to get a fix for this in that downgrades >> the stack to the older if_start/non-multiqueue interface. See the >> following two commits he made to HEAD. >> >> http://svnweb.freebsd.org/**base/head/sys/dev/e1000/if_** >> igb.c?revision=248906&view=**markup >> http://svnweb.freebsd.org/**base/head/sys/dev/e1000/if_** >> igb.h?revision=248908&view=**markup >> >> I've applied these changes to latest 9.1-STABLE src and included the >> IGB_LEGACY_TX in the e1000 Makefile. So far I am not having any luck >> getting pfctl to think igb is supported. >> >> i.e. I am still getting the following when loading my PF config: >> pfctl -f /etc/pf.conf >> pfctl: igb0: driver does not support altq >> >> Can anyone comment on if the above referenced changes that Jack made >> should be sufficient to get ALTQ working with igb? >> >> The error is coming from src/contrib/pf/pfctl/pfctl.c. There seems to >> be a function that checks if the driver is supported or not but I >> cannot figure out why the ioctl is not returning a device. >> >> Here is the device check code for reference: >> >> int >> pfctl_add_altq(struct pfctl *pf, struct pf_altq *a) >> { >> if (altqsupport && >> (loadopt & PFCTL_FLAG_ALTQ) != 0) { >> memcpy(&pf->paltq->altq, a, sizeof(struct pf_altq)); >> if ((pf->opts & PF_OPT_NOACTION) == 0) { >> if (ioctl(pf->dev, DIOCADDALTQ, pf->paltq)) { >> if (errno == ENXIO) >> errx(1, "qtype not configured"); >> else if (errno == ENODEV) >> errx(1, "%s: driver does not >> support " >> "altq", a->ifname); >> else >> err(1, "DIOCADDALTQ"); >> } >> } >> pfaltq_store(&pf->paltq->altq)**; >> } >> return (0); >> } >> >> >> >> >> >> On 28/03/2013 7:16 PM, Jack Vogel wrote: >> >> Have been kept fairly busy with other matters, one thing I could do short >> term is >> change the defines in igb the way I did in the em driver so you could >> still >> define >> the older if_start entry. Right now those are based on OS version and so >> you will >> automatically get if_transmit, but I could change it to be IGB_LEGACY_TX >> or >> so, >> and that could be defined in the Makefile. >> >> Would this help? >> >> Jack >> >> >> On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers wrote: >> >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel wrote: >> >> On Mon, Dec 10, 2012 at 11:58 PM, Gleb Smirnoff >> >> wrote: >> >> On Mon, Dec 10, 2012 at 03:31:19PM -0800, Jack Vogel wrote: >> J> UH, maybe asking the owner of the driver would help :) >> J> >> J> ... and no, I've never been aware of doing anything to stop >> >> supporting >> >> > _______________________________________________ > 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" From owner-freebsd-net@FreeBSD.ORG Tue Apr 2 14:47:07 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B2A4358B for ; Tue, 2 Apr 2013 14:47:07 +0000 (UTC) (envelope-from fodillemlinkarim@gmail.com) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by mx1.freebsd.org (Postfix) with ESMTP id 81D2483B for ; Tue, 2 Apr 2013 14:47:07 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id tp5so485674ieb.36 for ; Tue, 02 Apr 2013 07:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+8L3CrmCGPkKUmnAzrEpdMODCsXt34HLTQdT3nbwgek=; b=Z3igAdogejEAhZiGxTRMB+bE8N7BirV0wxd5gx8fenmFu7sV1CJxkQRSrzjXGRnrnA uvq/q+ztFFrM0GdjGy93KC2VOsQ8BafM2jTOWJs9d93S4KyVRUTlUzrXPlkzY7pRTmCG 29rpxeNS97Oq4Bo5UfChJiNeAITqhm7YjYlJOXN/yZDWSYhNOsQL6ehF+R7NJheErWO7 6oP1IJaSyutVKn2FfcRac05TdkRyD0bHn7xYys/bfja0aWIZq1te5HpOwVueyhDBwQSr nF1E2yNo1x2GRXpT6YPMHW8h+W53aycLlkniC7CjJ5HRFzbS5e1a7WVD3TzPi0N5cDja z/Pw== X-Received: by 10.50.181.136 with SMTP id dw8mr5208222igc.39.1364914027154; Tue, 02 Apr 2013 07:47:07 -0700 (PDT) Received: from [192.168.1.73] ([208.85.112.101]) by mx.google.com with ESMTPS id ih1sm5337436igc.3.2013.04.02.07.47.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Apr 2013 07:47:05 -0700 (PDT) Message-ID: <515AEF67.4070206@gmail.com> Date: Tue, 02 Apr 2013 10:47:03 -0400 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Nick Rogers Subject: Re: igb and ALTQ in 9.1-rc3 References: <1355177348.71087.YahooMailClassic@web121601.mail.ne1.yahoo.com> <50C6656E.3020601@gmail.com> <20121211075853.GU48639@FreeBSD.org> <5159AB72.1050202@gmail.com> <515ADACD.8010108@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 14:47:07 -0000 Hi Nick, Unfortunately I do not have a FBSD 9 box around where I can compile and test this so bear with me as this is pretty much straight out of looking at the source code directly (i.e it might not even compile). But if your desperate please try the following (untested) patch (applied to stable/9): diff --git a/sys/dev/e1000/if_igb.c b/sys/dev/e1000/if_igb.c index 30bb052..3a6de2e 100644 --- a/sys/dev/e1000/if_igb.c +++ b/sys/dev/e1000/if_igb.c @@ -179,13 +179,13 @@ static int igb_detach(device_t); static int igb_shutdown(device_t); static int igb_suspend(device_t); static int igb_resume(device_t); +static void igb_start(struct ifnet *); #if __FreeBSD_version >= 800000 static int igb_mq_start(struct ifnet *, struct mbuf *); static int igb_mq_start_locked(struct ifnet *, struct tx_ring *); static void igb_qflush(struct ifnet *); static void igb_deferred_mq_start(void *, int); #else -static void igb_start(struct ifnet *); static void igb_start_locked(struct tx_ring *, struct ifnet *ifp); #endif static int igb_ioctl(struct ifnet *, u_long, caddr_t); @@ -377,7 +377,7 @@ SYSCTL_INT(_hw_igb, OID_AUTO, header_split, CTLFLAG_RDTUN, &igb_header_split, 0, ** This will autoconfigure based on ** the number of CPUs if left at 0. */ -static int igb_num_queues = 0; +static int igb_num_queues = 1; TUNABLE_INT("hw.igb.num_queues", &igb_num_queues); SYSCTL_INT(_hw_igb, OID_AUTO, num_queues, CTLFLAG_RDTUN, &igb_num_queues, 0, "Number of queues to configure, 0 indicates autoconfigure"); @@ -926,6 +926,8 @@ igb_start_locked(struct tx_ring *txr, struct ifnet *ifp) txr->queue_status |= IGB_QUEUE_WORKING; } } + +#endif /* __FreeBSD_version < 800000 */ /* * Legacy TX driver routine, called from the @@ -940,14 +942,17 @@ igb_start(struct ifnet *ifp) if (ifp->if_drv_flags & IFF_DRV_RUNNING) { IGB_TX_LOCK(txr); +#if __FreeBSD_version < 800000 + igb_start_locked(txr, ifp); +#else + igb_mq_start_locked(ifp, txr, NULL); +#endif igb_start_locked(txr, ifp); IGB_TX_UNLOCK(txr); } return; } -#else /* __FreeBSD_version >= 800000 */ - /* ** Multiqueue Transmit Entry: ** quick turnaround to the stack @@ -3089,12 +3094,11 @@ igb_setup_interface(device_t dev, struct adapter *adapter) #if __FreeBSD_version >= 800000 ifp->if_transmit = igb_mq_start; ifp->if_qflush = igb_qflush; -#else +#endif ifp->if_start = igb_start; IFQ_SET_MAXLEN(&ifp->if_snd, adapter->num_tx_desc - 1); ifp->if_snd.ifq_drv_maxlen = adapter->num_tx_desc - 1; IFQ_SET_READY(&ifp->if_snd); -#endif ether_ifattach(ifp, adapter->hw.mac.addr); On 02/04/2013 9:58 AM, Nick Rogers wrote: > On Tuesday, April 2, 2013, Karim Fodil-Lemelin wrote: > >> Hi Nick, >> >> Can you verify that you have at least one of those options in your kernel >> config file: >> >> ALTQ_CBQ >> ALTQ_PRIQ >> ALTQ_HFSC > > Yes I have hfsc included in the kernel. I have other machines using altq > with em(4) interfaces and similar pf configurations on the same kernel that > work fine. > > >> Regards, >> >> Karim. >> >> On 01/04/2013 8:22 PM, Nick Rogers wrote: >> >> On Mon, Apr 1, 2013 at 8:44 AM, Karim Fodil-Lemelin >> wrote: >> >> Hi Jack, >> >> I think this would help M. Rogers case as we have done something similar >> here to circumvent the issue and it seems to work well. I would also add >> that when using ALTQ we found it much more stable to set the number of >> queues to 1: >> >> static int igb_num_queues = 1; >> >> Our approach consisted in keeping igb_start() defined and using >> igb_mq_start_locked() inside it instead of igb_start_locked(). >> >> Regards, >> >> Karim. >> >> Thanks for the pointer. >> >> I've been working with Jack to get a fix for this in that downgrades >> the stack to the older if_start/non-multiqueue interface. See the >> following two commits he made to HEAD. >> >> http://svnweb.freebsd.org/**base/head/sys/dev/e1000/if_** >> igb.c?revision=248906&view=**markup >> http://svnweb.freebsd.org/**base/head/sys/dev/e1000/if_** >> igb.h?revision=248908&view=**markup >> >> I've applied these changes to latest 9.1-STABLE src and included the >> IGB_LEGACY_TX in the e1000 Makefile. So far I am not having any luck >> getting pfctl to think igb is supported. >> >> i.e. I am still getting the following when loading my PF config: >> pfctl -f /etc/pf.conf >> pfctl: igb0: driver does not support altq >> >> Can anyone comment on if the above referenced changes that Jack made >> should be sufficient to get ALTQ working with igb? >> >> The error is coming from src/contrib/pf/pfctl/pfctl.c. There seems to >> be a function that checks if the driver is supported or not but I >> cannot figure out why the ioctl is not returning a device. >> >> Here is the device check code for reference: >> >> int >> pfctl_add_altq(struct pfctl *pf, struct pf_altq *a) >> { >> if (altqsupport && >> (loadopt & PFCTL_FLAG_ALTQ) != 0) { >> memcpy(&pf->paltq->altq, a, sizeof(struct pf_altq)); >> if ((pf->opts & PF_OPT_NOACTION) == 0) { >> if (ioctl(pf->dev, DIOCADDALTQ, pf->paltq)) { >> if (errno == ENXIO) >> errx(1, "qtype not configured"); >> else if (errno == ENODEV) >> errx(1, "%s: driver does not >> support " >> "altq", a->ifname); >> else >> err(1, "DIOCADDALTQ"); >> } >> } >> pfaltq_store(&pf->paltq->altq)**; >> } >> return (0); >> } >> >> >> >> >> >> On 28/03/2013 7:16 PM, Jack Vogel wrote: >> >> Have been kept fairly busy with other matters, one thing I could do short >> term is >> change the defines in igb the way I did in the em driver so you could >> still >> define >> the older if_start entry. Right now those are based on OS version and so >> you will >> automatically get if_transmit, but I could change it to be IGB_LEGACY_TX >> or >> so, >> and that could be defined in the Makefile. >> >> Would this help? >> >> Jack >> >> >> On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers wrote: >> >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel wrote: >> >> On Mon, Dec 10, 2012 at 11:58 PM, Gleb Smirnoff >> >> wrote: >> >> On Mon, Dec 10, 2012 at 03:31:19PM -0800, Jack Vogel wrote: >> J> UH, maybe asking the owner of the driver would help :) >> J> >> J> ... and no, I've never been aware of doing anything to stop >> >> supporting >> >> > _______________________________________________ > 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" From owner-freebsd-net@FreeBSD.ORG Tue Apr 2 16:00:28 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C59AF8C4 for ; Tue, 2 Apr 2013 16:00:28 +0000 (UTC) (envelope-from jovanross@msn.com) Received: from blu0-omc2-s24.blu0.hotmail.com (blu0-omc2-s24.blu0.hotmail.com [65.55.111.99]) by mx1.freebsd.org (Postfix) with ESMTP id 641CACB0 for ; Tue, 2 Apr 2013 16:00:28 +0000 (UTC) Received: from BLU151-W36 ([65.55.111.72]) by blu0-omc2-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Apr 2013 09:00:21 -0700 X-EIP: [+aR+h2ceUA8eZ9mlAy9kXMgPkya2Wbst] X-Originating-Email: [jovanross@msn.com] Message-ID: From: Jovan Ross To: "freebsd-net@freebsd.org" Subject: stop Date: Tue, 2 Apr 2013 12:00:20 -0400 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 02 Apr 2013 16:00:21.0140 (UTC) FILETIME=[2DA37540:01CE2FBB] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 16:00:28 -0000 please stop emailing me > From: freebsd-net-request@freebsd.org > Subject: freebsd-net Digest=2C Vol 522=2C Issue 2 > To: freebsd-net@freebsd.org > Date: Tue=2C 2 Apr 2013 12:00:02 +0000 >=20 > Send freebsd-net mailing list submissions to > freebsd-net@freebsd.org >=20 > To subscribe or unsubscribe via the World Wide Web=2C visit > http://lists.freebsd.org/mailman/listinfo/freebsd-net > or=2C via email=2C send a message with subject or body 'help' to > freebsd-net-request@freebsd.org >=20 > You can reach the person managing the list at > freebsd-net-owner@freebsd.org >=20 > When replying=2C please edit your Subject line so it is more specific > than "Re: Contents of freebsd-net digest..." >=20 >=20 > Today's Topics: >=20 > 1. Re: close(2) while accept(2) is blocked (John Baldwin) > 2. Re: igb and ALTQ in 9.1-rc3 (Karim Fodil-Lemelin) > 3. Re: KVM with freeBSD and SR-IOV vlan doesn't working! > (John Baldwin) > 4. Re: Route next-hop interface behaviour (Doug Ambrisko) > 5. Re: igb and ALTQ in 9.1-rc3 (Nick Rogers) > 6. Re: MPLS (Sepherosa Ziehau) > 7. Sea Water Electrolyzer for Electro-Chlorination (nl@ecanode.com) > 8. SFP/SFP+ =2C PCI Express Gigabit Ethernet NIC Card supplier=2C > 10G NIC=2C Server Adapter Intel chipsets (Jean) >=20 >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Mon=2C 1 Apr 2013 11:22:12 -0400 > From: John Baldwin > To: freebsd-net@freebsd.org > Cc: FreeBSD Hackers =2C Andriy Gapon > > Subject: Re: close(2) while accept(2) is blocked > Message-ID: <201304011122.13101.jhb@freebsd.org> > Content-Type: Text/Plain=3B charset=3D"iso-8859-1" >=20 > On Thursday=2C March 28=2C 2013 12:54:31 pm Andriy Gapon wrote: > >=20 > > So=2C this started as a simple question=2C but the answer was quite une= xpected to me. > >=20 > > Let's say we have an opened and listen-ed socket and let's assume that = we know > > that one thread is blocked in accept(2) and another thread is calling c= lose(2). > > What is going to happen? > >=20 > > Turns out that practically nothing. For kernel the close call would be= almost a nop. > > My understanding is this: > > - when socket is created=2C its reference count is 1 > > - when accept(2) is called=2C fget in kernel increments the reference c= ount (kept in > > an associated struct file) > > - when close(2) is called=2C the reference count is decremented > >=20 > > The reference count is still greater than zero=2C so fdrop does not cal= l fo_close. > > That means that in the case of a socket soclose is not called. > >=20 > > I am sure that the reference counting in this case is absolutely correc= t with > > respect to managing kernel side structures. But I am not that it is co= rrect with > > respect to hiding the explicit close(2) call from other threads that ma= y be > > waiting on the socket. > > In other words=2C I am not sure if fo_close is supposed to signify that= there are no > > uses of a file=2C or that userland close-d the file. Or perhaps these = should be two > > different methods. > >=20 > > Additional note is that shutdown(2) doesn't wake up the thread in accep= t(2) > > either. At least that's true for unix domain sockets. > > Not sure if this is a bug. > >=20 > > But the summary seems to be is that currently it is not possible to bre= ak a thread > > out of accept(2) (at least without resorting to signals). >=20 > I think you need to split the 'struct file' reference count into two diff= erent > counts similar to the how we have vref/vrele vs vhold/vdrop for vnodes. = The > fget for accept and probably most other system calls should probably be e= quivalent > to vhold=2C whereas things like open/dup (and storing an fd in a cmsg) sh= ould be > more like vref. close() should then be a vrele(). >=20 > --=20 > John Baldwin >=20 >=20 > ------------------------------ >=20 > Message: 2 > Date: Mon=2C 01 Apr 2013 11:44:50 -0400 > From: Karim Fodil-Lemelin > To: freebsd-net@freebsd.org > Subject: Re: igb and ALTQ in 9.1-rc3 > Message-ID: <5159AB72.1050202@gmail.com> > Content-Type: text/plain=3B charset=3DISO-8859-1=3B format=3Dflowed >=20 > Hi Jack=2C >=20 > I think this would help M. Rogers case as we have done something similar= =20 > here to circumvent the issue and it seems to work well. I would also add= =20 > that when using ALTQ we found it much more stable to set the number of=20 > queues to 1: >=20 > static int igb_num_queues =3D 1=3B >=20 > Our approach consisted in keeping igb_start() defined and using=20 > igb_mq_start_locked() inside it instead of igb_start_locked(). >=20 > Regards=2C >=20 > Karim. >=20 >=20 > On 28/03/2013 7:16 PM=2C Jack Vogel wrote: > > Have been kept fairly busy with other matters=2C one thing I could do s= hort > > term is > > change the defines in igb the way I did in the em driver so you could s= till > > define > > the older if_start entry. Right now those are based on OS version and s= o > > you will > > automatically get if_transmit=2C but I could change it to be IGB_LEGACY= _TX or > > so=2C > > and that could be defined in the Makefile. > > > > Would this help? > > > > Jack > > > > > > On Thu=2C Mar 28=2C 2013 at 2:31 PM=2C Nick Rogers = wrote: > > > >> On Tue=2C Dec 11=2C 2012 at 1:09 AM=2C Jack Vogel = wrote: > >>> On Mon=2C Dec 10=2C 2012 at 11:58 PM=2C Gleb Smirnoff > >> wrote: > >>>> On Mon=2C Dec 10=2C 2012 at 03:31:19PM -0800=2C Jack Vogel wrote: > >>>> J> UH=2C maybe asking the owner of the driver would help :) > >>>> J> > >>>> J> ... and no=2C I've never been aware of doing anything to stop > >> supporting > >>>> altq > >>>> J> so you wouldn't see any commits. If there's something in the altq > >> code > >>>> or > >>>> J> support (which I have nothing to do with) that caused this no-one > >>>> informed > >>>> J> me. > >>>> > >>>> Switching from if_start to if_transmit effectively disables ALTQ > >> support. > >>>> AFAIR=2C there is some magic implemented in other drivers that makes= them > >>>> modern (that means using if_transmit)=2C but still capable to switch= to > >>>> queueing > >>>> mode if SIOCADDALTQ was casted upon them. > >>>> > >>>> > >>> Oh=2C hmmm=2C I'll look into the matter after my vacation. > >>> > >>> Jack > >> Has there been any progress on resolving this issue? I recently ran > >> into this problem upgrading my servers from 8.3 to 9.1-RELEASE and am > >> wondering what the latest recommendation is. I've used ALTQ and igb > >> successfully for years and it is unfortunate it no longer works. > >> Appreciate any advice. > >> > >>> _______________________________________________ > >>> freebsd-net@freebsd.org mailing list > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net > >>> To unsubscribe=2C send any mail to "freebsd-net-unsubscribe@freebsd.o= rg" > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe=2C send any mail to "freebsd-net-unsubscribe@freebsd.org= " >=20 >=20 >=20 > ------------------------------ >=20 > Message: 3 > Date: Mon=2C 1 Apr 2013 13:47:55 -0400 > From: John Baldwin > To: freebsd-virtualization@freebsd.org > Cc: freebsd-net@freebsd.org=2C kindule > Subject: Re: KVM with freeBSD and SR-IOV vlan doesn't working! > Message-ID: <201304011347.55406.jhb@freebsd.org> > Content-Type: Text/Plain=3B charset=3D"iso-8859-1" >=20 > On Wednesday=2C March 27=2C 2013 5:31:27 am kindule wrote: > > Recently=2C we use KVM and SR-IOV in our project. And we choose freeBSD= 10 as > > the guest os.As we use the ip address in the igb0 of our freeBSD10 gues= t=2C it > > working no problem.However when i use vlan in our igb0 of the freeBSD10 > > guest=2Cwe can see the vlan assigned right and we can ping the vlan add= ress > > without problem.But we add a gateway of the vlan area.we can't connnect= ed to > > the gateway. > > there are some os messages: > > Host: Debian 7.0 and KVM 1.2 > > Guest: FreeBSD10-current > >=20 > > And thanks for your help! >=20 > Hmm=2C does the same vlan setup work on a standalone machine? >=20 > --=20 > John Baldwin >=20 >=20 > ------------------------------ >=20 > Message: 4 > Date: Mon=2C 1 Apr 2013 13:58:39 -0700 > From: Doug Ambrisko > To: Richard Tector > Cc: freebsd-net@freebsd.org > Subject: Re: Route next-hop interface behaviour > Message-ID: <20130401205839.GA24595@ambrisko.com> > Content-Type: text/plain=3B charset=3D"us-ascii" >=20 > On Sun=2C Mar 31=2C 2013 at 08:32:19PM +0100=2C Richard Tector wrote: > | Hi=2C > |=20 > | I'm not sure if it is expected behaviour but when configuring a static= =20 > | route (default or otherwise) the outbound interface recorded in the=20 > | table does not update when the system's IP changes interface=2C even wh= en=20 > | removing and re-adding it. > |=20 > | Fairly simple topology=2C system running 9.1-STABLE (30th March) with j= ust=20 > | one of four 'em' interfaces in use - em0 with 10.0.2.199. Default route= =20 > | to 10.0.2.1. > |=20 > | Whilst troubleshooting some odd TCP behaviour I thought I'd try a=20 > | different interface and so downed the active interface and brought up=20 > | one on a PCI card=2C and swapped the cable over: > |=20 > | # ifconfig em0 down > | # ifconfig em2 inet 10.0.2.199/24 > | # ifconfig em2 up > |=20 > | ##### > | If I then ping an external host it shows as the destination network=20 > | being inaccessible: > |=20 > | root@daffy:~ # ping 212.23.6.76 > | PING 212.23.6.76 (212.23.6.76): 56 data bytes > | ping: sendto: Network is down > |=20 > |=20 > | ##### > | Can contact the next hop just fine: > |=20 > | root@daffy:~ # ping 10.0.2.1 > | PING 10.0.2.1 (10.0.2.1): 56 data bytes > | 64 bytes from 10.0.2.1: icmp_seq=3D0 ttl=3D64 time=3D0.211 ms > |=20 > |=20 > | ##### > | Routing table shows that the default route is still bound to em0 even=20 > | though the next hop is on em2: > |=20 > | root@daffy:~ # netstat -rfinet -n > | Routing tables > |=20 > | Internet: > | Destination Gateway Flags Refs Use Netif Exp= ire > | default 10.0.2.1 UGS 0 3141 em0 > | ^^^ > | 10.0.2.0/24 link#4 U 1 255 em2 > | 10.0.2.199 link#1 UHS 1 0 lo0 > | 127.0.0.1 link#9 UH 0 0 lo0 > |=20 > |=20 > | ##### > | Removing the default route and re-adding also leaves it on the old=20 > | interface: > |=20 > | root@daffy:~ # route delete default > | delete net default > | root@daffy:~ # route add default 10.0.2.1 > | add net default: gateway 10.0.2.1 > | root@daffy:~ # netstat -rfinet -n > | Routing tables > |=20 > | Internet: > | Destination Gateway Flags Refs Use Netif Exp= ire > | default 10.0.2.1 UGS 0 0 em0 > | 10.0.2.0/24 link#4 U 0 688 em2 > | 10.0.2.199 link#1 UHS 1 0 lo0 > | 127.0.0.1 link#9 UH 0 0 lo0 > |=20 > | I can understand the initial problem=2C but surely when I re-add the ro= ute=20 > | it should do a lookup against the table for the next hop=2C ie.=20 > | 10.0.2.0/24=2C and use the associated Netif? > |=20 > | What's interesting is that if I remove the IP configuration from em0 it= =20 > | removes the default route above (even though the interface is downed).= =20 > | Re-adding the route works. >=20 > You can try this patch: >=20 > Index: net/if.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- net/if.c (revision 248707) > +++ net/if.c (working copy) > @@ -1532=2C6 +1532=2C8 @@ > =20 > IFNET_RLOCK_NOSLEEP()=3B > TAILQ_FOREACH(ifp=2C &V_ifnet=2C if_link) { > + if ((ifp->if_flags & IFF_UP) =3D=3D 0) > + continue=3B > IF_ADDR_RLOCK(ifp)=3B > TAILQ_FOREACH(ifa=2C &ifp->if_addrhead=2C ifa_link) { > if (ifa->ifa_addr->sa_family !=3D addr->sa_family) > @@ -1620=2C6 +1622=2C8 @@ > =20 > IFNET_RLOCK_NOSLEEP()=3B > TAILQ_FOREACH(ifp=2C &V_ifnet=2C if_link) { > + if ((ifp->if_flags & IFF_UP) =3D=3D 0) > + continue=3B > if ((ifp->if_flags & IFF_POINTOPOINT) =3D=3D 0) > continue=3B > IF_ADDR_RLOCK(ifp)=3B > @@ -1672=2C6 +1676=2C8 @@ > */ > IFNET_RLOCK_NOSLEEP()=3B > TAILQ_FOREACH(ifp=2C &V_ifnet=2C if_link) { > + if ((ifp->if_flags & IFF_UP) =3D=3D 0) > + continue=3B > IF_ADDR_RLOCK(ifp)=3B > TAILQ_FOREACH(ifa=2C &ifp->if_addrhead=2C ifa_link) { > char *cp=2C *cp2=2C *cp3=3B > Index: net/if_ethersubr.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- net/if_ethersubr.c (revision 248707) > +++ net/if_ethersubr.c (working copy) > @@ -812=2C6 +871=2C11 @@ > #if defined(NETATALK) > struct llc *l=3B > #endif > + /* Discard packet if interface is not up */ > + if ((ifp->if_flags & IFF_UP) =3D=3D 0) { > + m_freem(m)=3B > + return=3B > + } > =20 > KASSERT(ifp !=3D NULL=2C ("%s: NULL interface pointer"=2C __func__))=3B > =20 >=20 > The issue is that the routing doesn't look to see if the NIC is > up or not. It just looks at the IP address. So it tries to send > it out the first matching NIC that could be down. >=20 > Doug A. > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: up.patch > Type: text/x-diff > Size: 1318 bytes > Desc: not available > URL: >=20 > ------------------------------ >=20 > Message: 5 > Date: Mon=2C 1 Apr 2013 17:22:43 -0700 > From: Nick Rogers > To: Karim Fodil-Lemelin > Cc: "freebsd-net@freebsd.org" > Subject: Re: igb and ALTQ in 9.1-rc3 > Message-ID: > > Content-Type: text/plain=3B charset=3DISO-8859-1 >=20 > On Mon=2C Apr 1=2C 2013 at 8:44 AM=2C Karim Fodil-Lemelin > wrote: > > Hi Jack=2C > > > > I think this would help M. Rogers case as we have done something simila= r > > here to circumvent the issue and it seems to work well. I would also ad= d > > that when using ALTQ we found it much more stable to set the number of > > queues to 1: > > > > static int igb_num_queues =3D 1=3B > > > > Our approach consisted in keeping igb_start() defined and using > > igb_mq_start_locked() inside it instead of igb_start_locked(). > > > > Regards=2C > > > > Karim. >=20 > Thanks for the pointer. >=20 > I've been working with Jack to get a fix for this in that downgrades > the stack to the older if_start/non-multiqueue interface. See the > following two commits he made to HEAD. >=20 > http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_igb.c?revision=3D248= 906&view=3Dmarkup > http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_igb.h?revision=3D248= 908&view=3Dmarkup >=20 > I've applied these changes to latest 9.1-STABLE src and included the > IGB_LEGACY_TX in the e1000 Makefile. So far I am not having any luck > getting pfctl to think igb is supported. >=20 > i.e. I am still getting the following when loading my PF config: > pfctl -f /etc/pf.conf > pfctl: igb0: driver does not support altq >=20 > Can anyone comment on if the above referenced changes that Jack made > should be sufficient to get ALTQ working with igb? >=20 > The error is coming from src/contrib/pf/pfctl/pfctl.c. There seems to > be a function that checks if the driver is supported or not but I > cannot figure out why the ioctl is not returning a device. >=20 > Here is the device check code for reference: >=20 > int > pfctl_add_altq(struct pfctl *pf=2C struct pf_altq *a) > { > if (altqsupport && > (loadopt & PFCTL_FLAG_ALTQ) !=3D 0) { > memcpy(&pf->paltq->altq=2C a=2C sizeof(struct pf_altq))= =3B > if ((pf->opts & PF_OPT_NOACTION) =3D=3D 0) { > if (ioctl(pf->dev=2C DIOCADDALTQ=2C pf->paltq)) { > if (errno =3D=3D ENXIO) > errx(1=2C "qtype not configured")= =3B > else if (errno =3D=3D ENODEV) > errx(1=2C "%s: driver does not su= pport " > "altq"=2C a->ifname)=3B > else > err(1=2C "DIOCADDALTQ")=3B > } > } > pfaltq_store(&pf->paltq->altq)=3B > } > return (0)=3B > } >=20 >=20 >=20 > > > > > > > > On 28/03/2013 7:16 PM=2C Jack Vogel wrote: > >> > >> Have been kept fairly busy with other matters=2C one thing I could do = short > >> term is > >> change the defines in igb the way I did in the em driver so you could > >> still > >> define > >> the older if_start entry. Right now those are based on OS version and = so > >> you will > >> automatically get if_transmit=2C but I could change it to be IGB_LEGAC= Y_TX > >> or > >> so=2C > >> and that could be defined in the Makefile. > >> > >> Would this help? > >> > >> Jack > >> > >> > >> On Thu=2C Mar 28=2C 2013 at 2:31 PM=2C Nick Rogers wrote: > >> > >>> On Tue=2C Dec 11=2C 2012 at 1:09 AM=2C Jack Vogel = wrote: > >>>> > >>>> On Mon=2C Dec 10=2C 2012 at 11:58 PM=2C Gleb Smirnoff > >>> > >>> wrote: > >>>>> > >>>>> On Mon=2C Dec 10=2C 2012 at 03:31:19PM -0800=2C Jack Vogel wrote: > >>>>> J> UH=2C maybe asking the owner of the driver would help :) > >>>>> J> > >>>>> J> ... and no=2C I've never been aware of doing anything to stop > >>> > >>> supporting > >>>>> > >>>>> altq > >>>>> J> so you wouldn't see any commits. If there's something in the alt= q > >>> > >>> code > >>>>> > >>>>> or > >>>>> J> support (which I have nothing to do with) that caused this no-on= e > >>>>> informed > >>>>> J> me. > >>>>> > >>>>> Switching from if_start to if_transmit effectively disables ALTQ > >>> > >>> support. > >>>>> > >>>>> AFAIR=2C there is some magic implemented in other drivers that make= s them > >>>>> modern (that means using if_transmit)=2C but still capable to switc= h to > >>>>> queueing > >>>>> mode if SIOCADDALTQ was casted upon them. > >>>>> > >>>>> > >>>> Oh=2C hmmm=2C I'll look into the matter after my vacation. > >>>> > >>>> Jack > >>> > >>> Has there been any progress on resolving this issue? I recently ran > >>> into this problem upgrading my servers from 8.3 to 9.1-RELEASE and am > >>> wondering what the latest recommendation is. I've used ALTQ and igb > >>> successfully for years and it is unfortunate it no longer works. > >>> Appreciate any advice. > >>> > >>>> _______________________________________________ > >>>> freebsd-net@freebsd.org mailing list > >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net > >>>> To unsubscribe=2C send any mail to "freebsd-net-unsubscribe@freebsd.= org" > >> > >> _______________________________________________ > >> freebsd-net@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-net > >> To unsubscribe=2C send any mail to "freebsd-net-unsubscribe@freebsd.or= g" > > > > > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe=2C send any mail to "freebsd-net-unsubscribe@freebsd.org= " >=20 >=20 > ------------------------------ >=20 > Message: 6 > Date: Tue=2C 2 Apr 2013 14:16:34 +0800 > From: Sepherosa Ziehau > To: Andre Oppermann > Cc: Sami Halabi =2C "Alexander V. Chernikov" > =2C "Alexander V. Chernikov" =2C > "freebsd-net@freebsd.org" > Subject: Re: MPLS > Message-ID: > > Content-Type: text/plain=3B charset=3DISO-8859-1 >=20 > On Mon=2C Mar 18=2C 2013 at 9:41 PM=2C Andre Oppermann wrote: > > On 18.03.2013 13:20=2C Alexander V. Chernikov wrote: > >> > >> On 17.03.2013=2C at 23:54=2C Andre Oppermann wrote= : > >> > >>> On 17.03.2013 19:57=2C Alexander V. Chernikov wrote: > >>>> > >>>> On 17.03.2013 13:20=2C Sami Halabi wrote: > >>>>>> > >>>>>> ITOH OpenBSD has a complete implementation of MPLS out of the box= =2C > >>>>>> maybe > >>>> > >>>> Their control plane code is mostly useless due to design approach > >>>> (routing daemons talk via kernel). > >>> > >>> > >>> What's your approach? > >> > >> It is actually not mine. We have discussed this a bit in radix-related > >> thread. Generally quagga/bird (and other hiperf hardware-accelerated a= nd > >> software routers) have feature-rich RIb from which best routes (possib= ly > >> multipath) are installed to kernel/fib. Kernel main task should be to = do > >> efficient lookups while every other advanced feature should be impleme= nted > >> in userland. > > > > > > Yes=2C we have started discussing it but haven't reached a conclusion a= mong > > the > > two philosophies. We have also agreed that the current radix code is > > horrible > > in terms of cache misses per lookup. That however doesn't preclude an > > agnostic > > FIB+RIB approach. It's mostly a matter of structure layout to keep it > > efficient. > > > > > >>>> Their data plane code=2C well.. Yes=2C we can use some defines from = their > >>>> headers=2C but that's all :) > >>>>>> > >>>>>> porting it would be short and more straight forward than porting l= inux > >>>>>> LDP > >>>>>> implementation of BIRD. > >>>> > >>>> > >>>> It is not 'linux' implementation. LDP itself is cross-platform. > >>>> The most tricky place here is control plane. > >>>> However=2C making _fast_ MPLS switching is tricky too=2C since it re= quires > >>>> chages in our netisr/ethernet > >>>> handling code. > >>> > >>> > >>> Can you explain what changes you think are necessary and why? > > > >> > >> > >> We definitely need ability to dispatch chain of mbufs - this was alrea= dy > >> discussed in intel rx ring lock thread in -net. > > > > > > Actually I'm not so convinced of that. Packet handling is a tradeoff > > between > > doing process-to-completion on each packet and doing context switches o= n > > batches > > of packets. > > > > Every few years the balance tilts forth and back between > > process-to-completion > > and batch processing. DragonFly went with a batch-lite token-passing > > approach > > throughout their kernel. It seems it didn't work out to the extent the= y > > expected. > > Now many parts are moving back to the more traditional locking approach= . >=20 > At least=2C the per-CPU netisr and other related per-CPU network stuffs > (e.g. routing table) work quite well as we have _expected_ (the > measured bi-directional IPv4 forwarding performance w/ fastforwarding > is 5.6Mpps+=2C w/o fastforwarding 4.6Mpps+=2C w/ 4 igb(4) on i7-2600=2C > using 90% cpu time on each HT in Dfly's polling(4) mode)=3B it is _not_ > using traditional locking approach on major network paths at all and > for IPv4 forwarding Dfly is _not_ doing "process-to-completion". >=20 > And as a side note: There was a paper compared the message-based > parallelism TCP implementation=2C connection-based thread serialization > TCP implementaion (Dfly is using) and connection-based lock > serialization TCP implementation. The conclusion was connection-based > thread serialization TCP implementation (Dfly is using) had too many > scheduling cost. The paper's conclusion _no longer_ holds for Dfly > nowadays=3B we have wiped out major scheduling cost on the hot TCP > paths. So as far as I could see=2C its _not_ the problem of the model > itself sometimes=2C but how the model should be implemented. >=20 > Best Regards=2C > sephe >=20 > -- > Tomorrow Will Never Die >=20 >=20 > ------------------------------ >=20 > Message: 7 > Date: 2 Apr 2013 00:28:41 -0700 > From: nl@ecanode.com > To: freebsd-net@freebsd.org > Subject: Sea Water Electrolyzer for Electro-Chlorination > Message-ID: <20130402072949.1E486B6@hub.freebsd.org> > Content-Type: text/plain=3B charset=3D"us-ascii" >=20 >=20 > [1]If you can't view this mail click here.. >=20 > [2] >=20 > 2011111721370email.jpg > __________________________________________________________________ >=20 >=20 > [3]Unsubscribeme! > [4]Update Email Address! > This email sent to freebsd-net@freebsd.org by [5]nl@ecanode.com Powered > = by > [6][elogo= 1.jpg] >=20 > References >=20 > 1. http://www.ewhizs.com/Preview.aspx?nno=3DMTAw-T%2f3%2fcheYTl4%3d&me= m=3D14 > 2. http://www.ecanode.com/ > 3. http://www.ewhizs.com/unsubscribeme.aspx?ee=3DZnJlZWJzZC1uZXRAZnJlZ= WJzZC5vcmc%3d-hJ92ptlVoGg%3d&mem=3D14 > 4. http://www.ewhizs.com/updat.aspx?ee=3DZnJlZWJzZC1uZXRAZnJlZWJzZC5vc= mc%3d-hJ92ptlVoGg%3d&mem=3D14 > 5. mailto:%20nl@ecanode.com > 6. http://www.tiaanosoft.com/ >=20 >=20 > ------------------------------ >=20 > Message: 8 > Date: Tue=2C 2 Apr 2013 17:20:26 +0800 > From: Jean > To: freebsd-net > Subject: SFP/SFP+ =2C PCI Express Gigabit Ethernet NIC Card supplier=2C > 10G NIC=2C Server Adapter Intel chipsets > Message-ID: <2013040217202471867312@femrice.com> > Content-Type: text/plain=3B charset=3D"gb2312" >=20 > Hello=2C >=20 >=20 > I am jean and very glad to know you from Google website .Checked your web= site and maybe your customer need our=20 >=20 > products so Write to you and talk about whether we could cooperate with e= ach other in the further . >=20 >=20 > we are the manufacturer of PCI Express 1G &10G Ethernet NIC Card(Server A= dapter NIC Cards)=2CIntel chipsets=2C Our=20 >=20 > Femrice brand .CE=2CFC=2CROHS=2C Stock=2C lifetime warranty.Very good pri= ce in the market.=20 >=20 >=20 > we also supply SFP =2CSFP+=2CXFP and other special modules . >=20 >=20 > The Following one is our mainly NIC Cards: >=20 >=20 > Fiber cards : >=20 >=20 > 1. PCI Express(x4/) Dual Port Gigabit Ethernet NIC Card=2C Fiber NIC Card= =2C SFP Slot =2CLC=2C Intel82571EB Chipset controller =2C Type Number : 10= 002PF >=20 >=20 > 2. PCI Express (x4) Dual Port Gigabit Ethernet NIC Card=2C Fiber NIC Card= =2CSFP Slot =2CLC=2C Intel82576EB Chipset controller =2C Type Number : 10= 002EF >=20 >=20 > 3.PCI Express(x4) Dual Port Gigabit Ethernet NIC Card=2C Fiber NIC Card = =2CSFP Slot =2CLC=2C Intel82580DBChipset controller =2C Type Number : 1G2D= B580-SFP >=20 >=20 > 4. PCI Express (x4) Single Port Gigabit Ethernet NIC Card=2C Fiber NIC Ca= rd =2CSFP Slot =2CLC=2C Intel82572EI Chipset controller =2C Type Number : = 10001PF >=20 >=20 > 5. PCI Express (x1) Single Port Gigabit Ethernet NIC Card=2C Fiber NIC Ca= rd =2CSFP Slot =2CLC=2C Intel82583 Chipset controller =2C Type Number : 1G= PF583-SFP >=20 >=20 > 6.PCI Express (x8) Dual Port 10G Ethernet NIC Card=2C Fiber NIC Card =2CS= FP Slot =2CLC=2C Intel82599ES Chipset controller =2C Type Number : 10G2BF-= SFP+ >=20 >=20 > 7. PCI Express(x4/) Dual Port/Single Port Gigabit Ethernet NIC Card=2C Fi= ber =2C SFP Slot =2CLC=2C Intel82571EB Chipset controller =2C just Transmis= sive no=20 >=20 > receiver functions Type Number : 1G2BF571-TX (Mainly used in Uni-directio= nal GAP ) >=20 >=20 > 8.PCI Express(x4/) Dual Port/Single Port Gigabit Ethernet NIC Card=2C Fib= er =2C SFP Slot =2CLC=2C Intel82571EB Chipset controller =2C just Receiver = no=20 >=20 > transmission functions Type Number : 1G2BF571-RX (Mainly used in Uni-dire= ctional GAP ) >=20 >=20 >=20 > Plz reply to me if you are interested in our Products . >=20 >=20 > Hope we have chance to cooperate with each other in the further . >=20 >=20 > If you have Skype or MSN ID is more better =2CMy skype : Dream-fly99 >=20 >=20 > Best Regards >=20 >=20 > Jean heng >=20 >=20 > Femrice (China) Technology Co.=2C Ltd. >=20 >=20 > Tel:0086-10-51266807-813=20 >=20 >=20 > Mobile:0086-13001023615 >=20 >=20 > Fax: 0086-10-62979343 >=20 >=20 > Email: Jean@femrice.com=20 >=20 >=20 > Websites: http://www.ethernetserveradapter.com/ > www.femrice.com=20 >=20 >=20 > Skype: Dream-fly99 >=20 >=20 > MSN: Dream-fly99@Hotmail.com >=20 > ------------------------------ >=20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe=2C send any mail to "freebsd-net-unsubscribe@freebsd.org" >=20 > End of freebsd-net Digest=2C Vol 522=2C Issue 2 > ******************************************* = From owner-freebsd-net@FreeBSD.ORG Tue Apr 2 16:15:08 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CF4D8B76 for ; Tue, 2 Apr 2013 16:15:08 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.180]) by mx1.freebsd.org (Postfix) with ESMTP id 90E98DD7 for ; Tue, 2 Apr 2013 16:15:08 +0000 (UTC) Received: by mail-ve0-f180.google.com with SMTP id c13so719291vea.11 for ; Tue, 02 Apr 2013 09:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=iNwVs70K4mkPmcNJqfxyUObQunk71/r8C87saBHmU9k=; b=D6xkXoB8XwKnqZnl/98BzZkYS5+a6kvpIaqlSxthqi+Fuw9EcRH43qPLaD3T2Pw7I4 X8eroL4Lejz+0Y3eYOarTkwrB/IqjLaHx3vwHyjvfucHTC/1V1DyM7BkGB852Dg/sB89 7pDsu8DodYyz/YiILVJyfaqvIjtlK7Oq23uNi8rMsNM2KHPNSv9zWB6OwTvg/FNjr0Dp Ea9cIsR5S51jG/dAQ6y3kSxqXR5ApEXnoN3+GubO55ENLdXTVEd+Clh6QTK9CXTXXITU AMRXZviaO4LwXQUS2uuhqB4nujtiWM5Qk1sNyX607zqnhaD6kLAAnX0FtnulVEm6Xq+a REsA== MIME-Version: 1.0 X-Received: by 10.220.103.7 with SMTP id i7mr13179990vco.7.1364919301843; Tue, 02 Apr 2013 09:15:01 -0700 (PDT) Received: by 10.52.176.131 with HTTP; Tue, 2 Apr 2013 09:15:01 -0700 (PDT) In-Reply-To: <515AE933.7020806@gmail.com> References: <1355177348.71087.YahooMailClassic@web121601.mail.ne1.yahoo.com> <50C6656E.3020601@gmail.com> <20121211075853.GU48639@FreeBSD.org> <5159AB72.1050202@gmail.com> <515ADACD.8010108@gmail.com> <515AE933.7020806@gmail.com> Date: Tue, 2 Apr 2013 09:15:01 -0700 Message-ID: Subject: Re: igb and ALTQ in 9.1-rc3 From: Nick Rogers To: Karim Fodil-Lemelin Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 16:15:08 -0000 On Tue, Apr 2, 2013 at 7:20 AM, Karim Fodil-Lemelin wrote: > Hi Nick, > > You need to set the ALTQF_READY flag inside the igb driver. Make sure you > have something like this in if_igb.c: > > ifp->if_start = igb_start; > IFQ_SET_MAXLEN(&ifp->if_snd, adapter->num_tx_desc - 1); > ifp->if_snd.ifq_drv_maxlen = adapter->num_tx_desc - 1; > IFQ_SET_READY(&ifp->if_snd); > > The call to IFQ_SET_READY() is what will enable ALTQ on your device. OK, thanks. As far as I can tell the call to IFQ_SET_READY is happening. If you look at this commit Jack made: http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_igb.c?r1=248906&r2=248905&pathrev=248906 If IGB_LEGACY_TX is defined, then IFQ_SET_READY is called. In modules/igb/Makefile I have: +# IGB_LEGACY_TX will override the stack if_transmit path and +# instead use the older if_start non-multiqueue capable interface. +# This might be desireable for testing, or to enable the use of +# ALTQ. +CFLAGS += -DIGB_LEGACY_TX > > Regards, > > Karim. > > > On 02/04/2013 9:58 AM, Nick Rogers wrote: >> >> On Tuesday, April 2, 2013, Karim Fodil-Lemelin wrote: >> >>> Hi Nick, >>> >>> Can you verify that you have at least one of those options in your kernel >>> config file: >>> >>> ALTQ_CBQ >>> ALTQ_PRIQ >>> ALTQ_HFSC >> >> >> Yes I have hfsc included in the kernel. I have other machines using altq >> with em(4) interfaces and similar pf configurations on the same kernel >> that >> work fine. >> >> >>> Regards, >>> >>> Karim. >>> >>> On 01/04/2013 8:22 PM, Nick Rogers wrote: >>> >>> On Mon, Apr 1, 2013 at 8:44 AM, Karim Fodil-Lemelin >>> wrote: >>> >>> Hi Jack, >>> >>> I think this would help M. Rogers case as we have done something similar >>> here to circumvent the issue and it seems to work well. I would also add >>> that when using ALTQ we found it much more stable to set the number of >>> queues to 1: >>> >>> static int igb_num_queues = 1; >>> >>> Our approach consisted in keeping igb_start() defined and using >>> igb_mq_start_locked() inside it instead of igb_start_locked(). >>> >>> Regards, >>> >>> Karim. >>> >>> Thanks for the pointer. >>> >>> I've been working with Jack to get a fix for this in that downgrades >>> the stack to the older if_start/non-multiqueue interface. See the >>> following two commits he made to HEAD. >>> >>> http://svnweb.freebsd.org/**base/head/sys/dev/e1000/if_** >>> >>> igb.c?revision=248906&view=**markup >>> http://svnweb.freebsd.org/**base/head/sys/dev/e1000/if_** >>> >>> igb.h?revision=248908&view=**markup >>> >>> >>> I've applied these changes to latest 9.1-STABLE src and included the >>> IGB_LEGACY_TX in the e1000 Makefile. So far I am not having any luck >>> getting pfctl to think igb is supported. >>> >>> i.e. I am still getting the following when loading my PF config: >>> pfctl -f /etc/pf.conf >>> pfctl: igb0: driver does not support altq >>> >>> Can anyone comment on if the above referenced changes that Jack made >>> should be sufficient to get ALTQ working with igb? >>> >>> The error is coming from src/contrib/pf/pfctl/pfctl.c. There seems to >>> be a function that checks if the driver is supported or not but I >>> cannot figure out why the ioctl is not returning a device. >>> >>> Here is the device check code for reference: >>> >>> int >>> pfctl_add_altq(struct pfctl *pf, struct pf_altq *a) >>> { >>> if (altqsupport && >>> (loadopt & PFCTL_FLAG_ALTQ) != 0) { >>> memcpy(&pf->paltq->altq, a, sizeof(struct pf_altq)); >>> if ((pf->opts & PF_OPT_NOACTION) == 0) { >>> if (ioctl(pf->dev, DIOCADDALTQ, pf->paltq)) { >>> if (errno == ENXIO) >>> errx(1, "qtype not >>> configured"); >>> else if (errno == ENODEV) >>> errx(1, "%s: driver does not >>> support " >>> "altq", a->ifname); >>> else >>> err(1, "DIOCADDALTQ"); >>> } >>> } >>> pfaltq_store(&pf->paltq->altq)**; >>> >>> } >>> return (0); >>> } >>> >>> >>> >>> >>> >>> On 28/03/2013 7:16 PM, Jack Vogel wrote: >>> >>> Have been kept fairly busy with other matters, one thing I could do short >>> term is >>> change the defines in igb the way I did in the em driver so you could >>> still >>> define >>> the older if_start entry. Right now those are based on OS version and so >>> you will >>> automatically get if_transmit, but I could change it to be IGB_LEGACY_TX >>> or >>> so, >>> and that could be defined in the Makefile. >>> >>> Would this help? >>> >>> Jack >>> >>> >>> On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers wrote: >>> >>> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel wrote: >>> >>> On Mon, Dec 10, 2012 at 11:58 PM, Gleb Smirnoff >>> >>> wrote: >>> >>> On Mon, Dec 10, 2012 at 03:31:19PM -0800, Jack Vogel wrote: >>> J> UH, maybe asking the owner of the driver would help :) >>> J> >>> J> ... and no, I've never been aware of doing anything to stop >>> >>> supporting >>> >>> >> _______________________________________________ >> 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" > > From owner-freebsd-net@FreeBSD.ORG Tue Apr 2 16:17:23 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C37A9C38 for ; Tue, 2 Apr 2013 16:17:23 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) by mx1.freebsd.org (Postfix) with ESMTP id 849C7DF8 for ; Tue, 2 Apr 2013 16:17:23 +0000 (UTC) Received: by mail-vc0-f179.google.com with SMTP id gf12so612429vcb.38 for ; Tue, 02 Apr 2013 09:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=P4q14PpLabTUm3JaMjxNyQGp5xz4i7skEYcUImgcsCM=; b=01V0g89ifk9245+pUmyiic8odZdfFIjTwfZh2hfvKDzkYGNmtrZA76NrNKHjJy9m2n E9KxmMdhNlgjsx3fLwg72kA8NzBHB+gcMR9UMr3lIDKmfEaoDVgqmlYj8JWSOEYN+zrS 5HtyuNuDX+rWImberBDusLSqR8aGKX2q0TMdsEL8IRe28QQdGAXP4K9MfMgbXwh6SYa8 VtATpmLcvjJb5Noqup4tGrbIH6t5OeLKgUIrfhBkWulUCo2ejVyw0dEeiz3o9NVyli/S +vmRPhV6nU8o7w9+Z8G6FHMSvzxo2inp9m7d4DiKe8X//GoRpQPfqgq+TMjV53LCk9ra lqJw== MIME-Version: 1.0 X-Received: by 10.220.140.18 with SMTP id g18mr13211717vcu.54.1364919437054; Tue, 02 Apr 2013 09:17:17 -0700 (PDT) Received: by 10.52.176.131 with HTTP; Tue, 2 Apr 2013 09:17:16 -0700 (PDT) In-Reply-To: <515AEF67.4070206@gmail.com> References: <1355177348.71087.YahooMailClassic@web121601.mail.ne1.yahoo.com> <50C6656E.3020601@gmail.com> <20121211075853.GU48639@FreeBSD.org> <5159AB72.1050202@gmail.com> <515ADACD.8010108@gmail.com> <515AEF67.4070206@gmail.com> Date: Tue, 2 Apr 2013 09:17:16 -0700 Message-ID: Subject: Re: igb and ALTQ in 9.1-rc3 From: Nick Rogers To: Karim Fodil-Lemelin Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 16:17:23 -0000 On Tue, Apr 2, 2013 at 7:47 AM, Karim Fodil-Lemelin wrote: > Hi Nick, > > Unfortunately I do not have a FBSD 9 box around where I can compile and test > this so bear with me as this is pretty much straight out of looking at the > source code directly (i.e it might not even compile). > > But if your desperate please try the following (untested) patch (applied to > stable/9): Thanks for the attempt. The patch does not apply cleanly to stable/9 for me. Also I am trying to work with the latest commits Jack has made to HEAD that allow defining IGB_LEGACY_TX to disable the new multiqueue stack. It seems the gist of this is the same as what you have changed, unless I am missing something. > > diff --git a/sys/dev/e1000/if_igb.c b/sys/dev/e1000/if_igb.c > index 30bb052..3a6de2e 100644 > --- a/sys/dev/e1000/if_igb.c > +++ b/sys/dev/e1000/if_igb.c > @@ -179,13 +179,13 @@ static int igb_detach(device_t); > static int igb_shutdown(device_t); > static int igb_suspend(device_t); > static int igb_resume(device_t); > +static void igb_start(struct ifnet *); > #if __FreeBSD_version >= 800000 > static int igb_mq_start(struct ifnet *, struct mbuf *); > static int igb_mq_start_locked(struct ifnet *, struct tx_ring *); > static void igb_qflush(struct ifnet *); > static void igb_deferred_mq_start(void *, int); > #else > -static void igb_start(struct ifnet *); > static void igb_start_locked(struct tx_ring *, struct ifnet *ifp); > #endif > static int igb_ioctl(struct ifnet *, u_long, caddr_t); > @@ -377,7 +377,7 @@ SYSCTL_INT(_hw_igb, OID_AUTO, header_split, > CTLFLAG_RDTUN, &igb_header_split, 0, > ** This will autoconfigure based on > ** the number of CPUs if left at 0. > */ > -static int igb_num_queues = 0; > +static int igb_num_queues = 1; > TUNABLE_INT("hw.igb.num_queues", &igb_num_queues); > SYSCTL_INT(_hw_igb, OID_AUTO, num_queues, CTLFLAG_RDTUN, &igb_num_queues, > 0, > "Number of queues to configure, 0 indicates autoconfigure"); > @@ -926,6 +926,8 @@ igb_start_locked(struct tx_ring *txr, struct ifnet *ifp) > txr->queue_status |= IGB_QUEUE_WORKING; > } > } > + > +#endif /* __FreeBSD_version < 800000 */ > > /* > * Legacy TX driver routine, called from the > @@ -940,14 +942,17 @@ igb_start(struct ifnet *ifp) > > if (ifp->if_drv_flags & IFF_DRV_RUNNING) { > IGB_TX_LOCK(txr); > +#if __FreeBSD_version < 800000 > + igb_start_locked(txr, ifp); > +#else > + igb_mq_start_locked(ifp, txr, NULL); > +#endif > igb_start_locked(txr, ifp); > IGB_TX_UNLOCK(txr); > } > return; > } > > -#else /* __FreeBSD_version >= 800000 */ > - > /* > ** Multiqueue Transmit Entry: > ** quick turnaround to the stack > @@ -3089,12 +3094,11 @@ igb_setup_interface(device_t dev, struct adapter > *adapter) > #if __FreeBSD_version >= 800000 > ifp->if_transmit = igb_mq_start; > ifp->if_qflush = igb_qflush; > -#else > +#endif > > ifp->if_start = igb_start; > IFQ_SET_MAXLEN(&ifp->if_snd, adapter->num_tx_desc - 1); > ifp->if_snd.ifq_drv_maxlen = adapter->num_tx_desc - 1; > IFQ_SET_READY(&ifp->if_snd); > -#endif > > ether_ifattach(ifp, adapter->hw.mac.addr); > > > > > On 02/04/2013 9:58 AM, Nick Rogers wrote: >> >> On Tuesday, April 2, 2013, Karim Fodil-Lemelin wrote: >> >>> Hi Nick, >>> >>> Can you verify that you have at least one of those options in your kernel >>> config file: >>> >>> ALTQ_CBQ >>> ALTQ_PRIQ >>> ALTQ_HFSC >> >> >> Yes I have hfsc included in the kernel. I have other machines using altq >> with em(4) interfaces and similar pf configurations on the same kernel >> that >> work fine. >> >> >>> Regards, >>> >>> Karim. >>> >>> On 01/04/2013 8:22 PM, Nick Rogers wrote: >>> >>> On Mon, Apr 1, 2013 at 8:44 AM, Karim Fodil-Lemelin >>> wrote: >>> >>> Hi Jack, >>> >>> I think this would help M. Rogers case as we have done something similar >>> here to circumvent the issue and it seems to work well. I would also add >>> that when using ALTQ we found it much more stable to set the number of >>> queues to 1: >>> >>> static int igb_num_queues = 1; >>> >>> Our approach consisted in keeping igb_start() defined and using >>> igb_mq_start_locked() inside it instead of igb_start_locked(). >>> >>> Regards, >>> >>> Karim. >>> >>> Thanks for the pointer. >>> >>> I've been working with Jack to get a fix for this in that downgrades >>> the stack to the older if_start/non-multiqueue interface. See the >>> following two commits he made to HEAD. >>> >>> http://svnweb.freebsd.org/**base/head/sys/dev/e1000/if_** >>> >>> igb.c?revision=248906&view=**markup >>> http://svnweb.freebsd.org/**base/head/sys/dev/e1000/if_** >>> >>> igb.h?revision=248908&view=**markup >>> >>> >>> I've applied these changes to latest 9.1-STABLE src and included the >>> IGB_LEGACY_TX in the e1000 Makefile. So far I am not having any luck >>> getting pfctl to think igb is supported. >>> >>> i.e. I am still getting the following when loading my PF config: >>> pfctl -f /etc/pf.conf >>> pfctl: igb0: driver does not support altq >>> >>> Can anyone comment on if the above referenced changes that Jack made >>> should be sufficient to get ALTQ working with igb? >>> >>> The error is coming from src/contrib/pf/pfctl/pfctl.c. There seems to >>> be a function that checks if the driver is supported or not but I >>> cannot figure out why the ioctl is not returning a device. >>> >>> Here is the device check code for reference: >>> >>> int >>> pfctl_add_altq(struct pfctl *pf, struct pf_altq *a) >>> { >>> if (altqsupport && >>> (loadopt & PFCTL_FLAG_ALTQ) != 0) { >>> memcpy(&pf->paltq->altq, a, sizeof(struct pf_altq)); >>> if ((pf->opts & PF_OPT_NOACTION) == 0) { >>> if (ioctl(pf->dev, DIOCADDALTQ, pf->paltq)) { >>> if (errno == ENXIO) >>> errx(1, "qtype not >>> configured"); >>> else if (errno == ENODEV) >>> errx(1, "%s: driver does not >>> support " >>> "altq", a->ifname); >>> else >>> err(1, "DIOCADDALTQ"); >>> } >>> } >>> pfaltq_store(&pf->paltq->altq)**; >>> >>> } >>> return (0); >>> } >>> >>> >>> >>> >>> >>> On 28/03/2013 7:16 PM, Jack Vogel wrote: >>> >>> Have been kept fairly busy with other matters, one thing I could do short >>> term is >>> change the defines in igb the way I did in the em driver so you could >>> still >>> define >>> the older if_start entry. Right now those are based on OS version and so >>> you will >>> automatically get if_transmit, but I could change it to be IGB_LEGACY_TX >>> or >>> so, >>> and that could be defined in the Makefile. >>> >>> Would this help? >>> >>> Jack >>> >>> >>> On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers wrote: >>> >>> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel wrote: >>> >>> On Mon, Dec 10, 2012 at 11:58 PM, Gleb Smirnoff >>> >>> wrote: >>> >>> On Mon, Dec 10, 2012 at 03:31:19PM -0800, Jack Vogel wrote: >>> J> UH, maybe asking the owner of the driver would help :) >>> J> >>> J> ... and no, I've never been aware of doing anything to stop >>> >>> supporting >>> >>> >> _______________________________________________ >> 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" > > From owner-freebsd-net@FreeBSD.ORG Tue Apr 2 17:17:17 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D10513EC for ; Tue, 2 Apr 2013 17:17:17 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by mx1.freebsd.org (Postfix) with ESMTP id 9130C1B8 for ; Tue, 2 Apr 2013 17:17:17 +0000 (UTC) Received: by mail-vc0-f170.google.com with SMTP id lf10so704339vcb.29 for ; Tue, 02 Apr 2013 10:17:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jcd8BYZOO2gjMOVsFwWP+JCrQxkdo/rcSQxGe0+SkmA=; b=nmydgEO5r9IFPz+ICIp8f+t/9JOTIbntlfAQD3/w/XcOh51o2Qf8PifQrmW6iKEndf w785d83Tme/G5XpqeXfSg0aFGkjJA4dax9g8qnhwb5fXxHg7fwPdWxZYvFyN/UnCglLz gOF7OZkrm0hn1uwgkhF1CI8H1UR/hi+xVHtmx61GboCHEsW5Ge8wY5VsQB8zVACmlKHo 1+WrlNqBeEhWCIYe/a7rS+P8EJGRw2myE0gQ+pDuwdpTEQp5BaHacqJFVi8ZgSznj6f7 qwy2rREmNThCZyqCzhOjOUNl/aWK+CzesKVWOM/ReNPzZT60SlqGQLqiE2vzVDvjR8zO sIPQ== MIME-Version: 1.0 X-Received: by 10.220.151.144 with SMTP id c16mr13477841vcw.18.1364923031294; Tue, 02 Apr 2013 10:17:11 -0700 (PDT) Received: by 10.52.176.131 with HTTP; Tue, 2 Apr 2013 10:17:11 -0700 (PDT) In-Reply-To: References: <1355177348.71087.YahooMailClassic@web121601.mail.ne1.yahoo.com> <50C6656E.3020601@gmail.com> <20121211075853.GU48639@FreeBSD.org> <5159AB72.1050202@gmail.com> <515ADACD.8010108@gmail.com> <515AEF67.4070206@gmail.com> Date: Tue, 2 Apr 2013 10:17:11 -0700 Message-ID: Subject: Re: igb and ALTQ in 9.1-rc3 From: Nick Rogers To: Karim Fodil-Lemelin Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" , "jfvogel@gmail.com" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 17:17:17 -0000 On Tue, Apr 2, 2013 at 9:17 AM, Nick Rogers wrote: > On Tue, Apr 2, 2013 at 7:47 AM, Karim Fodil-Lemelin > wrote: >> Hi Nick, >> >> Unfortunately I do not have a FBSD 9 box around where I can compile and test >> this so bear with me as this is pretty much straight out of looking at the >> source code directly (i.e it might not even compile). >> >> But if your desperate please try the following (untested) patch (applied to >> stable/9): > > Thanks for the attempt. The patch does not apply cleanly to stable/9 > for me. Also I am trying to work with the latest commits Jack has made > to HEAD that allow defining IGB_LEGACY_TX to disable the new > multiqueue stack. It seems the gist of this is the same as what you > have changed, unless I am missing something. > OK, although your patch did not compile even after applying it manually, It made me understand the gist of what you were saying about "keeping igb_start() defined and using igb_mq_start_locked() inside it instead of igb_start_locked()". I was able to make my own patch that is very similar to your intention (and your patch) and it compiled, and solved my problem. ALTQ now works with igb (I am able to load my pf.conf, use PF, etc). Thanks a lot for the help. I will try and work with Jack to perhaps integrate this in a more official manner, as this is indeed a bit different than what he has changed in HEAD w.r.t IGB_LEGACY_TX configurability. Below is the diff of my changes against stable/9. Index: sys/dev/e1000/if_igb.c =================================================================== --- sys/dev/e1000/if_igb.c (revision 249024) +++ sys/dev/e1000/if_igb.c (working copy) @@ -179,13 +179,13 @@ static int igb_shutdown(device_t); static int igb_suspend(device_t); static int igb_resume(device_t); +static void igb_start(struct ifnet *); #if __FreeBSD_version >= 800000 static int igb_mq_start(struct ifnet *, struct mbuf *); static int igb_mq_start_locked(struct ifnet *, struct tx_ring *); static void igb_qflush(struct ifnet *); static void igb_deferred_mq_start(void *, int); #else -static void igb_start(struct ifnet *); static void igb_start_locked(struct tx_ring *, struct ifnet *ifp); #endif static int igb_ioctl(struct ifnet *, u_long, caddr_t); @@ -377,7 +377,7 @@ ** This will autoconfigure based on ** the number of CPUs if left at 0. */ -static int igb_num_queues = 0; +static int igb_num_queues = 1; TUNABLE_INT("hw.igb.num_queues", &igb_num_queues); SYSCTL_INT(_hw_igb, OID_AUTO, num_queues, CTLFLAG_RDTUN, &igb_num_queues, 0, "Number of queues to configure, 0 indicates autoconfigure"); @@ -926,6 +926,8 @@ txr->queue_status |= IGB_QUEUE_WORKING; } } + +#else /* __FreeBSD_version >= 800000 */ /* * Legacy TX driver routine, called from the @@ -940,13 +942,16 @@ if (ifp->if_drv_flags & IFF_DRV_RUNNING) { IGB_TX_LOCK(txr); - igb_start_locked(txr, ifp); + #if __FreeBSD_version < 800000 + igb_start_locked(txr, ifp); + #else + igb_mq_start_locked(ifp, txr); + #endif IGB_TX_UNLOCK(txr); } return; } -#else /* __FreeBSD_version >= 800000 */ /* ** Multiqueue Transmit Entry: @@ -3089,12 +3094,11 @@ #if __FreeBSD_version >= 800000 ifp->if_transmit = igb_mq_start; ifp->if_qflush = igb_qflush; -#else +#endif ifp->if_start = igb_start; IFQ_SET_MAXLEN(&ifp->if_snd, adapter->num_tx_desc - 1); ifp->if_snd.ifq_drv_maxlen = adapter->num_tx_desc - 1; IFQ_SET_READY(&ifp->if_snd); -#endif ether_ifattach(ifp, adapter->hw.mac.addr); >> >> diff --git a/sys/dev/e1000/if_igb.c b/sys/dev/e1000/if_igb.c >> index 30bb052..3a6de2e 100644 >> --- a/sys/dev/e1000/if_igb.c >> +++ b/sys/dev/e1000/if_igb.c >> @@ -179,13 +179,13 @@ static int igb_detach(device_t); >> static int igb_shutdown(device_t); >> static int igb_suspend(device_t); >> static int igb_resume(device_t); >> +static void igb_start(struct ifnet *); >> #if __FreeBSD_version >= 800000 >> static int igb_mq_start(struct ifnet *, struct mbuf *); >> static int igb_mq_start_locked(struct ifnet *, struct tx_ring *); >> static void igb_qflush(struct ifnet *); >> static void igb_deferred_mq_start(void *, int); >> #else >> -static void igb_start(struct ifnet *); >> static void igb_start_locked(struct tx_ring *, struct ifnet *ifp); >> #endif >> static int igb_ioctl(struct ifnet *, u_long, caddr_t); >> @@ -377,7 +377,7 @@ SYSCTL_INT(_hw_igb, OID_AUTO, header_split, >> CTLFLAG_RDTUN, &igb_header_split, 0, >> ** This will autoconfigure based on >> ** the number of CPUs if left at 0. >> */ >> -static int igb_num_queues = 0; >> +static int igb_num_queues = 1; >> TUNABLE_INT("hw.igb.num_queues", &igb_num_queues); >> SYSCTL_INT(_hw_igb, OID_AUTO, num_queues, CTLFLAG_RDTUN, &igb_num_queues, >> 0, >> "Number of queues to configure, 0 indicates autoconfigure"); >> @@ -926,6 +926,8 @@ igb_start_locked(struct tx_ring *txr, struct ifnet *ifp) >> txr->queue_status |= IGB_QUEUE_WORKING; >> } >> } >> + >> +#endif /* __FreeBSD_version < 800000 */ >> >> /* >> * Legacy TX driver routine, called from the >> @@ -940,14 +942,17 @@ igb_start(struct ifnet *ifp) >> >> if (ifp->if_drv_flags & IFF_DRV_RUNNING) { >> IGB_TX_LOCK(txr); >> +#if __FreeBSD_version < 800000 >> + igb_start_locked(txr, ifp); >> +#else >> + igb_mq_start_locked(ifp, txr, NULL); >> +#endif >> igb_start_locked(txr, ifp); >> IGB_TX_UNLOCK(txr); >> } >> return; >> } >> >> -#else /* __FreeBSD_version >= 800000 */ >> - >> /* >> ** Multiqueue Transmit Entry: >> ** quick turnaround to the stack >> @@ -3089,12 +3094,11 @@ igb_setup_interface(device_t dev, struct adapter >> *adapter) >> #if __FreeBSD_version >= 800000 >> ifp->if_transmit = igb_mq_start; >> ifp->if_qflush = igb_qflush; >> -#else >> +#endif >> >> ifp->if_start = igb_start; >> IFQ_SET_MAXLEN(&ifp->if_snd, adapter->num_tx_desc - 1); >> ifp->if_snd.ifq_drv_maxlen = adapter->num_tx_desc - 1; >> IFQ_SET_READY(&ifp->if_snd); >> -#endif >> >> ether_ifattach(ifp, adapter->hw.mac.addr); >> >> >> >> >> On 02/04/2013 9:58 AM, Nick Rogers wrote: >>> >>> On Tuesday, April 2, 2013, Karim Fodil-Lemelin wrote: >>> >>>> Hi Nick, >>>> >>>> Can you verify that you have at least one of those options in your kernel >>>> config file: >>>> >>>> ALTQ_CBQ >>>> ALTQ_PRIQ >>>> ALTQ_HFSC >>> >>> >>> Yes I have hfsc included in the kernel. I have other machines using altq >>> with em(4) interfaces and similar pf configurations on the same kernel >>> that >>> work fine. >>> >>> >>>> Regards, >>>> >>>> Karim. >>>> >>>> On 01/04/2013 8:22 PM, Nick Rogers wrote: >>>> >>>> On Mon, Apr 1, 2013 at 8:44 AM, Karim Fodil-Lemelin >>>> wrote: >>>> >>>> Hi Jack, >>>> >>>> I think this would help M. Rogers case as we have done something similar >>>> here to circumvent the issue and it seems to work well. I would also add >>>> that when using ALTQ we found it much more stable to set the number of >>>> queues to 1: >>>> >>>> static int igb_num_queues = 1; >>>> >>>> Our approach consisted in keeping igb_start() defined and using >>>> igb_mq_start_locked() inside it instead of igb_start_locked(). >>>> >>>> Regards, >>>> >>>> Karim. >>>> >>>> Thanks for the pointer. >>>> >>>> I've been working with Jack to get a fix for this in that downgrades >>>> the stack to the older if_start/non-multiqueue interface. See the >>>> following two commits he made to HEAD. >>>> >>>> http://svnweb.freebsd.org/**base/head/sys/dev/e1000/if_** >>>> >>>> igb.c?revision=248906&view=**markup >>>> http://svnweb.freebsd.org/**base/head/sys/dev/e1000/if_** >>>> >>>> igb.h?revision=248908&view=**markup >>>> >>>> >>>> I've applied these changes to latest 9.1-STABLE src and included the >>>> IGB_LEGACY_TX in the e1000 Makefile. So far I am not having any luck >>>> getting pfctl to think igb is supported. >>>> >>>> i.e. I am still getting the following when loading my PF config: >>>> pfctl -f /etc/pf.conf >>>> pfctl: igb0: driver does not support altq >>>> >>>> Can anyone comment on if the above referenced changes that Jack made >>>> should be sufficient to get ALTQ working with igb? >>>> >>>> The error is coming from src/contrib/pf/pfctl/pfctl.c. There seems to >>>> be a function that checks if the driver is supported or not but I >>>> cannot figure out why the ioctl is not returning a device. >>>> >>>> Here is the device check code for reference: >>>> >>>> int >>>> pfctl_add_altq(struct pfctl *pf, struct pf_altq *a) >>>> { >>>> if (altqsupport && >>>> (loadopt & PFCTL_FLAG_ALTQ) != 0) { >>>> memcpy(&pf->paltq->altq, a, sizeof(struct pf_altq)); >>>> if ((pf->opts & PF_OPT_NOACTION) == 0) { >>>> if (ioctl(pf->dev, DIOCADDALTQ, pf->paltq)) { >>>> if (errno == ENXIO) >>>> errx(1, "qtype not >>>> configured"); >>>> else if (errno == ENODEV) >>>> errx(1, "%s: driver does not >>>> support " >>>> "altq", a->ifname); >>>> else >>>> err(1, "DIOCADDALTQ"); >>>> } >>>> } >>>> pfaltq_store(&pf->paltq->altq)**; >>>> >>>> } >>>> return (0); >>>> } >>>> >>>> >>>> >>>> >>>> >>>> On 28/03/2013 7:16 PM, Jack Vogel wrote: >>>> >>>> Have been kept fairly busy with other matters, one thing I could do short >>>> term is >>>> change the defines in igb the way I did in the em driver so you could >>>> still >>>> define >>>> the older if_start entry. Right now those are based on OS version and so >>>> you will >>>> automatically get if_transmit, but I could change it to be IGB_LEGACY_TX >>>> or >>>> so, >>>> and that could be defined in the Makefile. >>>> >>>> Would this help? >>>> >>>> Jack >>>> >>>> >>>> On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers wrote: >>>> >>>> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel wrote: >>>> >>>> On Mon, Dec 10, 2012 at 11:58 PM, Gleb Smirnoff >>>> >>>> wrote: >>>> >>>> On Mon, Dec 10, 2012 at 03:31:19PM -0800, Jack Vogel wrote: >>>> J> UH, maybe asking the owner of the driver would help :) >>>> J> >>>> J> ... and no, I've never been aware of doing anything to stop >>>> >>>> supporting >>>> >>>> >>> _______________________________________________ >>> 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" >> >> From owner-freebsd-net@FreeBSD.ORG Tue Apr 2 18:33:20 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0DD2426C for ; Tue, 2 Apr 2013 18:33:20 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-ea0-x22b.google.com (mail-ea0-x22b.google.com [IPv6:2a00:1450:4013:c01::22b]) by mx1.freebsd.org (Postfix) with ESMTP id A0093EE2 for ; Tue, 2 Apr 2013 18:33:19 +0000 (UTC) Received: by mail-ea0-f171.google.com with SMTP id b15so373863eae.16 for ; Tue, 02 Apr 2013 11:33:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=qe2w0IeIxO1nRA4TVhDdQUDgG+me2flqVxfM5BHyZP0=; b=BuPwWOOjJVQbkpZeNJDeaauUMvVLLz//dbvoN0GCBVYUhfV/kLyHhPLDIJOwoftyVz sgqcnMygKxCudAR7HDHMI0CWTrm5PJt4qsRHgdo7iylzXkeVxwhY+D9NHHLT0B/+4Lz0 Sd2jRzHwcILxtjQRvWntYZFgv8ADcx+EPCQdxhDjQSRknSpgteD/dxMtBmM4ssm0+kg3 iaWzNz3uuUwgs7h7Ma6fe/HCIA1UXjygNAEY8CIHXK2cYjCiCse3vOxD3McpPkgTVIBA SH3Y/BQUQ6oFonUO2Q9wtIzqykdImFtz+mYnS6GFMLsNrQFsMO+jU1aUmMhMK6ffh89v IT3g== MIME-Version: 1.0 X-Received: by 10.14.218.71 with SMTP id j47mr51407702eep.28.1364927598816; Tue, 02 Apr 2013 11:33:18 -0700 (PDT) Received: by 10.223.61.17 with HTTP; Tue, 2 Apr 2013 11:33:18 -0700 (PDT) Date: Tue, 2 Apr 2013 11:33:18 -0700 Message-ID: Subject: Small patch in OFED/sdp From: Vijay Singh To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 18:33:20 -0000 Hi, this is based on the the understanding that the SS_NBIO is a socket state, and not a state of the socket buffer. F9@[/u/vijay/bsd/CODE/cur/sys/ofed/drivers/infiniband/ulp/sdp]# svn diff Index: sdp_main.c =================================================================== --- sdp_main.c (revision 249029) +++ sdp_main.c (working copy) @@ -1267,7 +1267,7 @@ /* Socket buffer is empty and we shall not block. */ if (sb->sb_cc == 0 && - ((sb->sb_flags & SS_NBIO) || (flags & (MSG_DONTWAIT|MSG_NBIO)))) { + ((so->so_state & SS_NBIO) || (flags & (MSG_DONTWAIT|MSG_NBIO)))) { error = EAGAIN; goto out; } @@ -1297,7 +1297,7 @@ /* Socket buffer got some data that we shall deliver now. */ if (sb->sb_cc > 0 && !(flags & MSG_WAITALL) && - ((sb->sb_flags & SS_NBIO) || + ((so->so_state & SS_NBIO) || (flags & (MSG_DONTWAIT|MSG_NBIO)) || sb->sb_cc >= sb->sb_lowat || sb->sb_cc >= uio->uio_resid || From owner-freebsd-net@FreeBSD.ORG Tue Apr 2 20:59:40 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 538BCB2F for ; Tue, 2 Apr 2013 20:59:40 +0000 (UTC) (envelope-from fodillemlinkarim@gmail.com) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 1F305A0D for ; Tue, 2 Apr 2013 20:59:40 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id e14so946306iej.2 for ; Tue, 02 Apr 2013 13:59:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=dqFSUqYH5Sf3g7bYDEC+f4Ol63O1stU68DNmE0wIoWE=; b=gjZuQSFT1wToHfGa6jZw9nRx5jAQkSOO182sYesw8Dpb2T/Qwwqp0kuZHZeXRtq+aA WRV3FZk/4YxYuGq/ghZ0X0sqLUbhwuY/2oJ0MVfMEzlB+8Me/ZQgogFeps8jdQ0tdU7u g3DD/Y7h9h/5fBSLOiP2SxDNkprasS5JwL8t075tpOM9zCx4F4iLOFNR6IRNKm1XIhJr ZY4547VHe/yDoQqjm9ARze2fVnUa1XpMWtQUfMCMwCYX+eEFxzpHuIaTFjSgzLwqBw+N TD8sCnqttgGKrRgr8oRdceYMyX2wlC9AUlp2kZcEemj2VVAkNXEsEhpMFiEdZcf0I7+o wjfQ== X-Received: by 10.50.49.66 with SMTP id s2mr751716ign.13.1364936379700; Tue, 02 Apr 2013 13:59:39 -0700 (PDT) Received: from [192.168.1.73] ([208.85.112.101]) by mx.google.com with ESMTPS id c14sm1694599ign.2.2013.04.02.13.59.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Apr 2013 13:59:38 -0700 (PDT) Message-ID: <515B46B8.5050806@gmail.com> Date: Tue, 02 Apr 2013 16:59:36 -0400 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Nick Rogers Subject: Re: igb and ALTQ in 9.1-rc3 References: <1355177348.71087.YahooMailClassic@web121601.mail.ne1.yahoo.com> <50C6656E.3020601@gmail.com> <20121211075853.GU48639@FreeBSD.org> <5159AB72.1050202@gmail.com> <515ADACD.8010108@gmail.com> <515AEF67.4070206@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , "jfvogel@gmail.com" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 20:59:40 -0000 Hi Nick, Thanks for the testing, I am glad I could help. Please note that by setting: static int igb_num_queues = 1; You are effectively only using 1 TX queue from the hardware (instead of 4 or 8) so this might not be applicable to a generic kernel without ALTQ. Best regards, Karim. On 02/04/2013 1:17 PM, Nick Rogers wrote: > On Tue, Apr 2, 2013 at 9:17 AM, Nick Rogers wrote: >> On Tue, Apr 2, 2013 at 7:47 AM, Karim Fodil-Lemelin >> wrote: >>> Hi Nick, >>> >>> Unfortunately I do not have a FBSD 9 box around where I can compile and test >>> this so bear with me as this is pretty much straight out of looking at the >>> source code directly (i.e it might not even compile). >>> >>> But if your desperate please try the following (untested) patch (applied to >>> stable/9): >> Thanks for the attempt. The patch does not apply cleanly to stable/9 >> for me. Also I am trying to work with the latest commits Jack has made >> to HEAD that allow defining IGB_LEGACY_TX to disable the new >> multiqueue stack. It seems the gist of this is the same as what you >> have changed, unless I am missing something. >> > OK, although your patch did not compile even after applying it > manually, It made me understand the gist of what you were saying about > "keeping igb_start() defined and using igb_mq_start_locked() inside it > instead of igb_start_locked()". I was able to make my own patch that > is very similar to your intention (and your patch) and it compiled, > and solved my problem. ALTQ now works with igb (I am able to load my > pf.conf, use PF, etc). Thanks a lot for the help. I will try and work > with Jack to perhaps integrate this in a more official manner, as this > is indeed a bit different than what he has changed in HEAD w.r.t > IGB_LEGACY_TX configurability. > > Below is the diff of my changes against stable/9. > > Index: sys/dev/e1000/if_igb.c > =================================================================== > --- sys/dev/e1000/if_igb.c (revision 249024) > +++ sys/dev/e1000/if_igb.c (working copy) > @@ -179,13 +179,13 @@ > static int igb_shutdown(device_t); > static int igb_suspend(device_t); > static int igb_resume(device_t); > +static void igb_start(struct ifnet *); > #if __FreeBSD_version >= 800000 > static int igb_mq_start(struct ifnet *, struct mbuf *); > static int igb_mq_start_locked(struct ifnet *, struct tx_ring *); > static void igb_qflush(struct ifnet *); > static void igb_deferred_mq_start(void *, int); > #else > -static void igb_start(struct ifnet *); > static void igb_start_locked(struct tx_ring *, struct ifnet *ifp); > #endif > static int igb_ioctl(struct ifnet *, u_long, caddr_t); > @@ -377,7 +377,7 @@ > ** This will autoconfigure based on > ** the number of CPUs if left at 0. > */ > -static int igb_num_queues = 0; > +static int igb_num_queues = 1; > TUNABLE_INT("hw.igb.num_queues", &igb_num_queues); > SYSCTL_INT(_hw_igb, OID_AUTO, num_queues, CTLFLAG_RDTUN, &igb_num_queues, 0, > "Number of queues to configure, 0 indicates autoconfigure"); > @@ -926,6 +926,8 @@ > txr->queue_status |= IGB_QUEUE_WORKING; > } > } > + > +#else /* __FreeBSD_version >= 800000 */ > > /* > * Legacy TX driver routine, called from the > @@ -940,13 +942,16 @@ > > if (ifp->if_drv_flags & IFF_DRV_RUNNING) { > IGB_TX_LOCK(txr); > - igb_start_locked(txr, ifp); > + #if __FreeBSD_version < 800000 > + igb_start_locked(txr, ifp); > + #else > + igb_mq_start_locked(ifp, txr); > + #endif > IGB_TX_UNLOCK(txr); > } > return; > } > > -#else /* __FreeBSD_version >= 800000 */ > > /* > ** Multiqueue Transmit Entry: > @@ -3089,12 +3094,11 @@ > #if __FreeBSD_version >= 800000 > ifp->if_transmit = igb_mq_start; > ifp->if_qflush = igb_qflush; > -#else > +#endif > ifp->if_start = igb_start; > IFQ_SET_MAXLEN(&ifp->if_snd, adapter->num_tx_desc - 1); > ifp->if_snd.ifq_drv_maxlen = adapter->num_tx_desc - 1; > IFQ_SET_READY(&ifp->if_snd); > -#endif > > ether_ifattach(ifp, adapter->hw.mac.addr); > > > >>> diff --git a/sys/dev/e1000/if_igb.c b/sys/dev/e1000/if_igb.c >>> index 30bb052..3a6de2e 100644 >>> --- a/sys/dev/e1000/if_igb.c >>> +++ b/sys/dev/e1000/if_igb.c >>> @@ -179,13 +179,13 @@ static int igb_detach(device_t); >>> static int igb_shutdown(device_t); >>> static int igb_suspend(device_t); >>> static int igb_resume(device_t); >>> +static void igb_start(struct ifnet *); >>> #if __FreeBSD_version >= 800000 >>> static int igb_mq_start(struct ifnet *, struct mbuf *); >>> static int igb_mq_start_locked(struct ifnet *, struct tx_ring *); >>> static void igb_qflush(struct ifnet *); >>> static void igb_deferred_mq_start(void *, int); >>> #else >>> -static void igb_start(struct ifnet *); >>> static void igb_start_locked(struct tx_ring *, struct ifnet *ifp); >>> #endif >>> static int igb_ioctl(struct ifnet *, u_long, caddr_t); >>> @@ -377,7 +377,7 @@ SYSCTL_INT(_hw_igb, OID_AUTO, header_split, >>> CTLFLAG_RDTUN, &igb_header_split, 0, >>> ** This will autoconfigure based on >>> ** the number of CPUs if left at 0. >>> */ >>> -static int igb_num_queues = 0; >>> +static int igb_num_queues = 1; >>> TUNABLE_INT("hw.igb.num_queues", &igb_num_queues); >>> SYSCTL_INT(_hw_igb, OID_AUTO, num_queues, CTLFLAG_RDTUN, &igb_num_queues, >>> 0, >>> "Number of queues to configure, 0 indicates autoconfigure"); >>> @@ -926,6 +926,8 @@ igb_start_locked(struct tx_ring *txr, struct ifnet *ifp) >>> txr->queue_status |= IGB_QUEUE_WORKING; >>> } >>> } >>> + >>> +#endif /* __FreeBSD_version < 800000 */ >>> >>> /* >>> * Legacy TX driver routine, called from the >>> @@ -940,14 +942,17 @@ igb_start(struct ifnet *ifp) >>> >>> if (ifp->if_drv_flags & IFF_DRV_RUNNING) { >>> IGB_TX_LOCK(txr); >>> +#if __FreeBSD_version < 800000 >>> + igb_start_locked(txr, ifp); >>> +#else >>> + igb_mq_start_locked(ifp, txr, NULL); >>> +#endif >>> igb_start_locked(txr, ifp); >>> IGB_TX_UNLOCK(txr); >>> } >>> return; >>> } >>> >>> -#else /* __FreeBSD_version >= 800000 */ >>> - >>> /* >>> ** Multiqueue Transmit Entry: >>> ** quick turnaround to the stack >>> @@ -3089,12 +3094,11 @@ igb_setup_interface(device_t dev, struct adapter >>> *adapter) >>> #if __FreeBSD_version >= 800000 >>> ifp->if_transmit = igb_mq_start; >>> ifp->if_qflush = igb_qflush; >>> -#else >>> +#endif >>> >>> ifp->if_start = igb_start; >>> IFQ_SET_MAXLEN(&ifp->if_snd, adapter->num_tx_desc - 1); >>> ifp->if_snd.ifq_drv_maxlen = adapter->num_tx_desc - 1; >>> IFQ_SET_READY(&ifp->if_snd); >>> -#endif >>> >>> ether_ifattach(ifp, adapter->hw.mac.addr); >>> >>> >>> >>> >>> On 02/04/2013 9:58 AM, Nick Rogers wrote: >>>> On Tuesday, April 2, 2013, Karim Fodil-Lemelin wrote: >>>> >>>>> Hi Nick, >>>>> >>>>> Can you verify that you have at least one of those options in your kernel >>>>> config file: >>>>> >>>>> ALTQ_CBQ >>>>> ALTQ_PRIQ >>>>> ALTQ_HFSC >>>> >>>> Yes I have hfsc included in the kernel. I have other machines using altq >>>> with em(4) interfaces and similar pf configurations on the same kernel >>>> that >>>> work fine. >>>> >>>> >>>>> Regards, >>>>> >>>>> Karim. >>>>> >>>>> On 01/04/2013 8:22 PM, Nick Rogers wrote: >>>>> >>>>> On Mon, Apr 1, 2013 at 8:44 AM, Karim Fodil-Lemelin >>>>> wrote: >>>>> >>>>> Hi Jack, >>>>> >>>>> I think this would help M. Rogers case as we have done something similar >>>>> here to circumvent the issue and it seems to work well. I would also add >>>>> that when using ALTQ we found it much more stable to set the number of >>>>> queues to 1: >>>>> >>>>> static int igb_num_queues = 1; >>>>> >>>>> Our approach consisted in keeping igb_start() defined and using >>>>> igb_mq_start_locked() inside it instead of igb_start_locked(). >>>>> >>>>> Regards, >>>>> >>>>> Karim. >>>>> >>>>> Thanks for the pointer. >>>>> >>>>> I've been working with Jack to get a fix for this in that downgrades >>>>> the stack to the older if_start/non-multiqueue interface. See the >>>>> following two commits he made to HEAD. >>>>> >>>>> http://svnweb.freebsd.org/**base/head/sys/dev/e1000/if_** >>>>> >>>>> igb.c?revision=248906&view=**markup >>>>> http://svnweb.freebsd.org/**base/head/sys/dev/e1000/if_** >>>>> >>>>> igb.h?revision=248908&view=**markup >>>>> >>>>> >>>>> I've applied these changes to latest 9.1-STABLE src and included the >>>>> IGB_LEGACY_TX in the e1000 Makefile. So far I am not having any luck >>>>> getting pfctl to think igb is supported. >>>>> >>>>> i.e. I am still getting the following when loading my PF config: >>>>> pfctl -f /etc/pf.conf >>>>> pfctl: igb0: driver does not support altq >>>>> >>>>> Can anyone comment on if the above referenced changes that Jack made >>>>> should be sufficient to get ALTQ working with igb? >>>>> >>>>> The error is coming from src/contrib/pf/pfctl/pfctl.c. There seems to >>>>> be a function that checks if the driver is supported or not but I >>>>> cannot figure out why the ioctl is not returning a device. >>>>> >>>>> Here is the device check code for reference: >>>>> >>>>> int >>>>> pfctl_add_altq(struct pfctl *pf, struct pf_altq *a) >>>>> { >>>>> if (altqsupport && >>>>> (loadopt & PFCTL_FLAG_ALTQ) != 0) { >>>>> memcpy(&pf->paltq->altq, a, sizeof(struct pf_altq)); >>>>> if ((pf->opts & PF_OPT_NOACTION) == 0) { >>>>> if (ioctl(pf->dev, DIOCADDALTQ, pf->paltq)) { >>>>> if (errno == ENXIO) >>>>> errx(1, "qtype not >>>>> configured"); >>>>> else if (errno == ENODEV) >>>>> errx(1, "%s: driver does not >>>>> support " >>>>> "altq", a->ifname); >>>>> else >>>>> err(1, "DIOCADDALTQ"); >>>>> } >>>>> } >>>>> pfaltq_store(&pf->paltq->altq)**; >>>>> >>>>> } >>>>> return (0); >>>>> } >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 28/03/2013 7:16 PM, Jack Vogel wrote: >>>>> >>>>> Have been kept fairly busy with other matters, one thing I could do short >>>>> term is >>>>> change the defines in igb the way I did in the em driver so you could >>>>> still >>>>> define >>>>> the older if_start entry. Right now those are based on OS version and so >>>>> you will >>>>> automatically get if_transmit, but I could change it to be IGB_LEGACY_TX >>>>> or >>>>> so, >>>>> and that could be defined in the Makefile. >>>>> >>>>> Would this help? >>>>> >>>>> Jack >>>>> >>>>> >>>>> On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers wrote: >>>>> >>>>> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel wrote: >>>>> >>>>> On Mon, Dec 10, 2012 at 11:58 PM, Gleb Smirnoff >>>>> >>>>> wrote: >>>>> >>>>> On Mon, Dec 10, 2012 at 03:31:19PM -0800, Jack Vogel wrote: >>>>> J> UH, maybe asking the owner of the driver would help :) >>>>> J> >>>>> J> ... and no, I've never been aware of doing anything to stop >>>>> >>>>> supporting >>>>> >>>>> >>>> _______________________________________________ >>>> 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" >>> > _______________________________________________ > 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" From owner-freebsd-net@FreeBSD.ORG Tue Apr 2 21:50:01 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 82587D3B for ; Tue, 2 Apr 2013 21:50:01 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-ve0-f177.google.com (mail-ve0-f177.google.com [209.85.128.177]) by mx1.freebsd.org (Postfix) with ESMTP id 426E4D98 for ; Tue, 2 Apr 2013 21:50:00 +0000 (UTC) Received: by mail-ve0-f177.google.com with SMTP id jw11so1137214veb.8 for ; Tue, 02 Apr 2013 14:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jzI6CX7liwtkwG3j8aQXAJg/HxAG3eZc0AesRZ8kaWU=; b=mlEvsJ3HpJ1ewVYprXx+KHHXJMRl5xPRiNE14eHBToBxdonisFBU63uoR6FBd3upuA atfgPK7FE5LRcXncfkakq2Bijtsh/2OK8eCl2SMIwC9E7K/iUESQBtnbdZxad4X5JLi/ 9kyR2vAyNpeRJk1PaUkSHsF1mSdDibyfMPTwMt5VPdgkykNw1sHJFUa55XmOTvVkSwNR yUAleSHlWPmajqYld2B0usgFhhA3L+gn5SaYGjxHvR8mgJxKs5I3LyYuoh6dHWfzCmo+ 2BTkm7AH8Hez5igEBzpW6xr/8PSmV6IpHALWg4OmqmH5KwCvS99DupoanViKlbP8koIr aB3w== MIME-Version: 1.0 X-Received: by 10.58.188.48 with SMTP id fx16mr14177466vec.22.1364939394699; Tue, 02 Apr 2013 14:49:54 -0700 (PDT) Received: by 10.52.176.131 with HTTP; Tue, 2 Apr 2013 14:49:54 -0700 (PDT) In-Reply-To: <515B46B8.5050806@gmail.com> References: <1355177348.71087.YahooMailClassic@web121601.mail.ne1.yahoo.com> <50C6656E.3020601@gmail.com> <20121211075853.GU48639@FreeBSD.org> <5159AB72.1050202@gmail.com> <515ADACD.8010108@gmail.com> <515AEF67.4070206@gmail.com> <515B46B8.5050806@gmail.com> Date: Tue, 2 Apr 2013 14:49:54 -0700 Message-ID: Subject: Re: igb and ALTQ in 9.1-rc3 From: Nick Rogers To: Karim Fodil-Lemelin Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 21:50:01 -0000 On Tue, Apr 2, 2013 at 1:59 PM, Karim Fodil-Lemelin wrote: > Hi Nick, > > Thanks for the testing, I am glad I could help. Please note that by setting: > > > static int igb_num_queues = 1; > > You are effectively only using 1 TX queue from the hardware (instead of 4 or > 8) so this might not be applicable to a generic kernel without ALTQ. Yes I am aware of this, thanks. Also, FWIW, the changes Jack made to e1000 in HEAD are working for me now and they should get MFCd eventually. If you set IGB_LEGACY_TX, the multiqueue stack is skipped in favor of the old stuff which enables ALTQ to work correctly again. This seems like it may be a cleaner approach than the patch you suggested. I am unsure the best way to set IGB_LEGACY_TX without adding a #define IGB_LEGACY_TX to if_igb.c. Adding this to CFLAGS in make.conf and/or the kernel conf does not seem to take effect when building the driver into the kernel (i.e., not as a module). Can anyone comment on a correct way to set this macro without modifying the driver code? > > Best regards, > > Karim. > > > On 02/04/2013 1:17 PM, Nick Rogers wrote: >> >> On Tue, Apr 2, 2013 at 9:17 AM, Nick Rogers wrote: >>> >>> On Tue, Apr 2, 2013 at 7:47 AM, Karim Fodil-Lemelin >>> wrote: >>>> >>>> Hi Nick, >>>> >>>> Unfortunately I do not have a FBSD 9 box around where I can compile and >>>> test >>>> this so bear with me as this is pretty much straight out of looking at >>>> the >>>> source code directly (i.e it might not even compile). >>>> >>>> But if your desperate please try the following (untested) patch (applied >>>> to >>>> stable/9): >>> >>> Thanks for the attempt. The patch does not apply cleanly to stable/9 >>> for me. Also I am trying to work with the latest commits Jack has made >>> to HEAD that allow defining IGB_LEGACY_TX to disable the new >>> multiqueue stack. It seems the gist of this is the same as what you >>> have changed, unless I am missing something. >>> >> OK, although your patch did not compile even after applying it >> manually, It made me understand the gist of what you were saying about >> "keeping igb_start() defined and using igb_mq_start_locked() inside it >> instead of igb_start_locked()". I was able to make my own patch that >> is very similar to your intention (and your patch) and it compiled, >> and solved my problem. ALTQ now works with igb (I am able to load my >> pf.conf, use PF, etc). Thanks a lot for the help. I will try and work >> with Jack to perhaps integrate this in a more official manner, as this >> is indeed a bit different than what he has changed in HEAD w.r.t >> IGB_LEGACY_TX configurability. >> >> Below is the diff of my changes against stable/9. >> >> Index: sys/dev/e1000/if_igb.c >> =================================================================== >> --- sys/dev/e1000/if_igb.c (revision 249024) >> +++ sys/dev/e1000/if_igb.c (working copy) >> @@ -179,13 +179,13 @@ >> static int igb_shutdown(device_t); >> static int igb_suspend(device_t); >> static int igb_resume(device_t); >> +static void igb_start(struct ifnet *); >> #if __FreeBSD_version >= 800000 >> static int igb_mq_start(struct ifnet *, struct mbuf *); >> static int igb_mq_start_locked(struct ifnet *, struct tx_ring *); >> static void igb_qflush(struct ifnet *); >> static void igb_deferred_mq_start(void *, int); >> #else >> -static void igb_start(struct ifnet *); >> static void igb_start_locked(struct tx_ring *, struct ifnet *ifp); >> #endif >> static int igb_ioctl(struct ifnet *, u_long, caddr_t); >> @@ -377,7 +377,7 @@ >> ** This will autoconfigure based on >> ** the number of CPUs if left at 0. >> */ >> -static int igb_num_queues = 0; >> +static int igb_num_queues = 1; >> TUNABLE_INT("hw.igb.num_queues", &igb_num_queues); >> SYSCTL_INT(_hw_igb, OID_AUTO, num_queues, CTLFLAG_RDTUN, >> &igb_num_queues, 0, >> "Number of queues to configure, 0 indicates autoconfigure"); >> @@ -926,6 +926,8 @@ >> txr->queue_status |= IGB_QUEUE_WORKING; >> } >> } >> + >> +#else /* __FreeBSD_version >= 800000 */ >> >> /* >> * Legacy TX driver routine, called from the >> @@ -940,13 +942,16 @@ >> >> if (ifp->if_drv_flags & IFF_DRV_RUNNING) { >> IGB_TX_LOCK(txr); >> - igb_start_locked(txr, ifp); >> + #if __FreeBSD_version < 800000 >> + igb_start_locked(txr, ifp); >> + #else >> + igb_mq_start_locked(ifp, txr); >> + #endif >> IGB_TX_UNLOCK(txr); >> } >> return; >> } >> >> -#else /* __FreeBSD_version >= 800000 */ >> >> /* >> ** Multiqueue Transmit Entry: >> @@ -3089,12 +3094,11 @@ >> #if __FreeBSD_version >= 800000 >> ifp->if_transmit = igb_mq_start; >> ifp->if_qflush = igb_qflush; >> -#else >> +#endif >> ifp->if_start = igb_start; >> IFQ_SET_MAXLEN(&ifp->if_snd, adapter->num_tx_desc - 1); >> ifp->if_snd.ifq_drv_maxlen = adapter->num_tx_desc - 1; >> IFQ_SET_READY(&ifp->if_snd); >> -#endif >> >> ether_ifattach(ifp, adapter->hw.mac.addr); >> >> >> >>>> diff --git a/sys/dev/e1000/if_igb.c b/sys/dev/e1000/if_igb.c >>>> index 30bb052..3a6de2e 100644 >>>> --- a/sys/dev/e1000/if_igb.c >>>> +++ b/sys/dev/e1000/if_igb.c >>>> @@ -179,13 +179,13 @@ static int igb_detach(device_t); >>>> static int igb_shutdown(device_t); >>>> static int igb_suspend(device_t); >>>> static int igb_resume(device_t); >>>> +static void igb_start(struct ifnet *); >>>> #if __FreeBSD_version >= 800000 >>>> static int igb_mq_start(struct ifnet *, struct mbuf *); >>>> static int igb_mq_start_locked(struct ifnet *, struct tx_ring *); >>>> static void igb_qflush(struct ifnet *); >>>> static void igb_deferred_mq_start(void *, int); >>>> #else >>>> -static void igb_start(struct ifnet *); >>>> static void igb_start_locked(struct tx_ring *, struct ifnet *ifp); >>>> #endif >>>> static int igb_ioctl(struct ifnet *, u_long, caddr_t); >>>> @@ -377,7 +377,7 @@ SYSCTL_INT(_hw_igb, OID_AUTO, header_split, >>>> CTLFLAG_RDTUN, &igb_header_split, 0, >>>> ** This will autoconfigure based on >>>> ** the number of CPUs if left at 0. >>>> */ >>>> -static int igb_num_queues = 0; >>>> +static int igb_num_queues = 1; >>>> TUNABLE_INT("hw.igb.num_queues", &igb_num_queues); >>>> SYSCTL_INT(_hw_igb, OID_AUTO, num_queues, CTLFLAG_RDTUN, >>>> &igb_num_queues, >>>> 0, >>>> "Number of queues to configure, 0 indicates autoconfigure"); >>>> @@ -926,6 +926,8 @@ igb_start_locked(struct tx_ring *txr, struct ifnet >>>> *ifp) >>>> txr->queue_status |= IGB_QUEUE_WORKING; >>>> } >>>> } >>>> + >>>> +#endif /* __FreeBSD_version < 800000 */ >>>> >>>> /* >>>> * Legacy TX driver routine, called from the >>>> @@ -940,14 +942,17 @@ igb_start(struct ifnet *ifp) >>>> >>>> if (ifp->if_drv_flags & IFF_DRV_RUNNING) { >>>> IGB_TX_LOCK(txr); >>>> +#if __FreeBSD_version < 800000 >>>> + igb_start_locked(txr, ifp); >>>> +#else >>>> + igb_mq_start_locked(ifp, txr, NULL); >>>> +#endif >>>> igb_start_locked(txr, ifp); >>>> IGB_TX_UNLOCK(txr); >>>> } >>>> return; >>>> } >>>> >>>> -#else /* __FreeBSD_version >= 800000 */ >>>> - >>>> /* >>>> ** Multiqueue Transmit Entry: >>>> ** quick turnaround to the stack >>>> @@ -3089,12 +3094,11 @@ igb_setup_interface(device_t dev, struct adapter >>>> *adapter) >>>> #if __FreeBSD_version >= 800000 >>>> ifp->if_transmit = igb_mq_start; >>>> ifp->if_qflush = igb_qflush; >>>> -#else >>>> +#endif >>>> >>>> ifp->if_start = igb_start; >>>> IFQ_SET_MAXLEN(&ifp->if_snd, adapter->num_tx_desc - 1); >>>> ifp->if_snd.ifq_drv_maxlen = adapter->num_tx_desc - 1; >>>> IFQ_SET_READY(&ifp->if_snd); >>>> -#endif >>>> >>>> ether_ifattach(ifp, adapter->hw.mac.addr); >>>> >>>> >>>> >>>> >>>> On 02/04/2013 9:58 AM, Nick Rogers wrote: >>>>> >>>>> On Tuesday, April 2, 2013, Karim Fodil-Lemelin wrote: >>>>> >>>>>> Hi Nick, >>>>>> >>>>>> Can you verify that you have at least one of those options in your >>>>>> kernel >>>>>> config file: >>>>>> >>>>>> ALTQ_CBQ >>>>>> ALTQ_PRIQ >>>>>> ALTQ_HFSC >>>>> >>>>> >>>>> Yes I have hfsc included in the kernel. I have other machines using >>>>> altq >>>>> with em(4) interfaces and similar pf configurations on the same kernel >>>>> that >>>>> work fine. >>>>> >>>>> >>>>>> Regards, >>>>>> >>>>>> Karim. >>>>>> >>>>>> On 01/04/2013 8:22 PM, Nick Rogers wrote: >>>>>> >>>>>> On Mon, Apr 1, 2013 at 8:44 AM, Karim Fodil-Lemelin >>>>>> wrote: >>>>>> >>>>>> Hi Jack, >>>>>> >>>>>> I think this would help M. Rogers case as we have done something >>>>>> similar >>>>>> here to circumvent the issue and it seems to work well. I would also >>>>>> add >>>>>> that when using ALTQ we found it much more stable to set the number of >>>>>> queues to 1: >>>>>> >>>>>> static int igb_num_queues = 1; >>>>>> >>>>>> Our approach consisted in keeping igb_start() defined and using >>>>>> igb_mq_start_locked() inside it instead of igb_start_locked(). >>>>>> >>>>>> Regards, >>>>>> >>>>>> Karim. >>>>>> >>>>>> Thanks for the pointer. >>>>>> >>>>>> I've been working with Jack to get a fix for this in that downgrades >>>>>> the stack to the older if_start/non-multiqueue interface. See the >>>>>> following two commits he made to HEAD. >>>>>> >>>>>> http://svnweb.freebsd.org/**base/head/sys/dev/e1000/if_** >>>>>> >>>>>> >>>>>> igb.c?revision=248906&view=**markup >>>>>> http://svnweb.freebsd.org/**base/head/sys/dev/e1000/if_** >>>>>> >>>>>> >>>>>> igb.h?revision=248908&view=**markup >>>>>> >>>>>> >>>>>> I've applied these changes to latest 9.1-STABLE src and included the >>>>>> IGB_LEGACY_TX in the e1000 Makefile. So far I am not having any luck >>>>>> getting pfctl to think igb is supported. >>>>>> >>>>>> i.e. I am still getting the following when loading my PF config: >>>>>> pfctl -f /etc/pf.conf >>>>>> pfctl: igb0: driver does not support altq >>>>>> >>>>>> Can anyone comment on if the above referenced changes that Jack made >>>>>> should be sufficient to get ALTQ working with igb? >>>>>> >>>>>> The error is coming from src/contrib/pf/pfctl/pfctl.c. There seems to >>>>>> be a function that checks if the driver is supported or not but I >>>>>> cannot figure out why the ioctl is not returning a device. >>>>>> >>>>>> Here is the device check code for reference: >>>>>> >>>>>> int >>>>>> pfctl_add_altq(struct pfctl *pf, struct pf_altq *a) >>>>>> { >>>>>> if (altqsupport && >>>>>> (loadopt & PFCTL_FLAG_ALTQ) != 0) { >>>>>> memcpy(&pf->paltq->altq, a, sizeof(struct >>>>>> pf_altq)); >>>>>> if ((pf->opts & PF_OPT_NOACTION) == 0) { >>>>>> if (ioctl(pf->dev, DIOCADDALTQ, pf->paltq)) >>>>>> { >>>>>> if (errno == ENXIO) >>>>>> errx(1, "qtype not >>>>>> configured"); >>>>>> else if (errno == ENODEV) >>>>>> errx(1, "%s: driver does >>>>>> not >>>>>> support " >>>>>> "altq", a->ifname); >>>>>> else >>>>>> err(1, "DIOCADDALTQ"); >>>>>> } >>>>>> } >>>>>> pfaltq_store(&pf->paltq->altq)**; >>>>>> >>>>>> } >>>>>> return (0); >>>>>> } >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 28/03/2013 7:16 PM, Jack Vogel wrote: >>>>>> >>>>>> Have been kept fairly busy with other matters, one thing I could do >>>>>> short >>>>>> term is >>>>>> change the defines in igb the way I did in the em driver so you could >>>>>> still >>>>>> define >>>>>> the older if_start entry. Right now those are based on OS version and >>>>>> so >>>>>> you will >>>>>> automatically get if_transmit, but I could change it to be >>>>>> IGB_LEGACY_TX >>>>>> or >>>>>> so, >>>>>> and that could be defined in the Makefile. >>>>>> >>>>>> Would this help? >>>>>> >>>>>> Jack >>>>>> >>>>>> >>>>>> On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers >>>>>> wrote: >>>>>> >>>>>> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel >>>>>> wrote: >>>>>> >>>>>> On Mon, Dec 10, 2012 at 11:58 PM, Gleb Smirnoff >>>>>> >>>>>> wrote: >>>>>> >>>>>> On Mon, Dec 10, 2012 at 03:31:19PM -0800, Jack Vogel wrote: >>>>>> J> UH, maybe asking the owner of the driver would help :) >>>>>> J> >>>>>> J> ... and no, I've never been aware of doing anything to stop >>>>>> >>>>>> supporting >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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" >>>> >>>> >> _______________________________________________ >> 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" > > From owner-freebsd-net@FreeBSD.ORG Tue Apr 2 22:40:04 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5DCD6B99 for ; Tue, 2 Apr 2013 22:40:04 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by mx1.freebsd.org (Postfix) with ESMTP id E6F51FF5 for ; Tue, 2 Apr 2013 22:40:03 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id c11so1020552wgh.20 for ; Tue, 02 Apr 2013 15:39:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=q+lBEzVhY3wC6z+5KMOvZbIUr3NeZMHlUFo3HZHri9k=; b=ILhABWhUPg39JhLjf0QEvqliDjFCCkhiyf5vwUK3ggxCGwUmIu9ov/a3CxnDA2mBwV 493igxRuAFbvg7O6bEaY6dmVnlDCwhOgQU2UO8nCpE9dbww5IvyFuRrQm8v9HqlGs8ww xMYWSHtD29bVm6Tw1kR1Xj6gUmyQ7qNUt/7oQeYcKIG04sQkg5kXABrMO83EqnIrQowc NZgJ/1kqdyoznTBxkodDDhgaiBvivCptzErAimJHusGXPTm4PS7BkuIXznLtfEOKYUuc S5c/4PlMnmksAuf5SbPYSzbcdeMWs0bMdvGWzl38MI8YBnk33BZBSgxlruOy4Jj+N2I2 1JDQ== MIME-Version: 1.0 X-Received: by 10.181.11.164 with SMTP id ej4mr19268550wid.29.1364942397515; Tue, 02 Apr 2013 15:39:57 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Tue, 2 Apr 2013 15:39:57 -0700 (PDT) In-Reply-To: References: <1355177348.71087.YahooMailClassic@web121601.mail.ne1.yahoo.com> <50C6656E.3020601@gmail.com> <20121211075853.GU48639@FreeBSD.org> <5159AB72.1050202@gmail.com> <515ADACD.8010108@gmail.com> <515AEF67.4070206@gmail.com> <515B46B8.5050806@gmail.com> Date: Tue, 2 Apr 2013 15:39:57 -0700 X-Google-Sender-Auth: K7jxr03iN2FV0FJf_kkkBSys7YQ Message-ID: Subject: Re: igb and ALTQ in 9.1-rc3 From: Adrian Chadd To: Nick Rogers Content-Type: text/plain; charset=ISO-8859-1 Cc: Karim Fodil-Lemelin , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 22:40:04 -0000 Yes: * you need to add it to conf/options - see if there's an opt_igb.h to add it to, otherwise you'll need to add one; * Make sure the driver code includes opt_igb.h; * Then make sure you make kernel modules using either make buildkernel KERNCONF=X, or you set the environment appropriately so the build scripts can find your kernel build directory (where it populates all the opt_xxx.h includes) and it'll have this module set. Hopefully Jack will do this. Yes, we need a better queue management discipline API in the kernel. Jacks' just falling afoul of the fact we don't have one. It's not his fault. adrian From owner-freebsd-net@FreeBSD.ORG Tue Apr 2 22:54:03 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BBD58F77; Tue, 2 Apr 2013 22:54:03 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-vb0-x22d.google.com (mail-vb0-x22d.google.com [IPv6:2607:f8b0:400c:c02::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 67E431A3; Tue, 2 Apr 2013 22:54:03 +0000 (UTC) Received: by mail-vb0-f45.google.com with SMTP id w15so9784vbf.32 for ; Tue, 02 Apr 2013 15:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=hWQj+2hcBLhjiOtJ7Kgh0lvd8oGfNE5bKeM5WgYWPiw=; b=zeCcPS+jnjuqZjTWyWB0aJTdGa4U6oAk3RrkksQ+msSV8XiKlTQWgc8Jycpgi65iJP qS9KV1Q5RX5WbGzJZC02O8MfwKJiff9jITo0scpRkv3wIHY7wVEQ5k+Lg3j1wFEw9+VN M60BUkd51ujC5EZPJ3aO/Lyi0a9I2fNvSJIO8gNgmnbTq2BV14W6z8UyDrtdhfQ6erZy ZM1W7mlHnshbaiA8bzM9oggTxZFXjvfzUylsbG7SuVTgzfRP9goWm2AlRxtli06/Ut6T KQWHhALong5EaOBmuXSIt95e3ZGSijKldd/DOrvIfrHo17P2rwQzxmP8XfpTcGzJRKu3 BQ7A== MIME-Version: 1.0 X-Received: by 10.52.177.163 with SMTP id cr3mr12166804vdc.94.1364943242923; Tue, 02 Apr 2013 15:54:02 -0700 (PDT) Received: by 10.52.176.131 with HTTP; Tue, 2 Apr 2013 15:54:02 -0700 (PDT) In-Reply-To: References: <1355177348.71087.YahooMailClassic@web121601.mail.ne1.yahoo.com> <50C6656E.3020601@gmail.com> <20121211075853.GU48639@FreeBSD.org> <5159AB72.1050202@gmail.com> <515ADACD.8010108@gmail.com> <515AEF67.4070206@gmail.com> <515B46B8.5050806@gmail.com> Date: Tue, 2 Apr 2013 15:54:02 -0700 Message-ID: Subject: Re: igb and ALTQ in 9.1-rc3 From: Nick Rogers To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: Karim Fodil-Lemelin , "freebsd-net@freebsd.org" , "jfvogel@gmail.com" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 22:54:03 -0000 On Tue, Apr 2, 2013 at 3:39 PM, Adrian Chadd wrote: > Yes: > > * you need to add it to conf/options - see if there's an opt_igb.h to > add it to, otherwise you'll need to add one; > * Make sure the driver code includes opt_igb.h; > * Then make sure you make kernel modules using either make buildkernel > KERNCONF=X, or you set the environment appropriately so the build > scripts can find your kernel build directory (where it populates all > the opt_xxx.h includes) and it'll have this module set. Thanks, I figured as much. > > Hopefully Jack will do this. This should probably be done for EM_MULTIQUEUE and IGB_LEGACY_TX options. > > Yes, we need a better queue management discipline API in the kernel. > Jacks' just falling afoul of the fact we don't have one. It's not his > fault. No blame from me... He's been very helpful so far as always. > > > > adrian From owner-freebsd-net@FreeBSD.ORG Tue Apr 2 23:25:59 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C83245D6 for ; Tue, 2 Apr 2013 23:25:59 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id A129B34A for ; Tue, 2 Apr 2013 23:25:59 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id r32NPwi2089265 for ; Tue, 2 Apr 2013 16:25:58 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <515B6906.7000305@rawbw.com> Date: Tue, 02 Apr 2013 16:25:58 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130327 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Is it possible to slow down the network interface? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 23:25:59 -0000 For the testing purposes, I would like to be able to control the maximum speed of the interface. There is this command 'ifconfig re0 media 10baseT/UTP' that is supposed to lower the speed to 10Mbps. However, it makes interface unusable on my system. All connections are broken, even the router had to be rebooted. Maybe this is the router issue. Is there any other, "soft" way to change maximum interface speed to a particular value? When somebody sends data too fast, OS sends back ICMP notifications that connection is jammed. My question is, is it possible to impose such condition artificially? Is 'ifconfig re0 media 10baseT/UTP' actually supposed to work transparently, or disconnects are to be expected? Yuri From owner-freebsd-net@FreeBSD.ORG Tue Apr 2 23:27:43 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 53AE8686 for ; Tue, 2 Apr 2013 23:27:43 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 46729361 for ; Tue, 2 Apr 2013 23:27:43 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 136871A3C30; Tue, 2 Apr 2013 16:27:42 -0700 (PDT) Message-ID: <515B6963.8010400@mu.org> Date: Tue, 02 Apr 2013 16:27:31 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Yuri Subject: Re: Is it possible to slow down the network interface? References: <515B6906.7000305@rawbw.com> In-Reply-To: <515B6906.7000305@rawbw.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 23:27:43 -0000 On 4/2/13 4:25 PM, Yuri wrote: > For the testing purposes, I would like to be able to control the > maximum speed of the interface. > There is this command 'ifconfig re0 media 10baseT/UTP' that is > supposed to lower the speed to 10Mbps. However, it makes interface > unusable on my system. All connections are broken, even the router had > to be rebooted. Maybe this is the router issue. > > Is there any other, "soft" way to change maximum interface speed to a > particular value? > When somebody sends data too fast, OS sends back ICMP notifications > that connection is jammed. My question is, is it possible to impose > such condition artificially? > Is 'ifconfig re0 media 10baseT/UTP' actually supposed to work > transparently, or disconnects are to be expected? > try dummynet, it lets you simulate slow or otherwise special networks. man 4 dummynet -Alfred From owner-freebsd-net@FreeBSD.ORG Tue Apr 2 23:31:45 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2297976E for ; Tue, 2 Apr 2013 23:31:45 +0000 (UTC) (envelope-from pprocacci@datapipe.com) Received: from EXFESMQ04.datapipe-corp.net (exfesmq04.datapipe.com [64.27.120.68]) by mx1.freebsd.org (Postfix) with ESMTP id DD887388 for ; Tue, 2 Apr 2013 23:31:44 +0000 (UTC) Received: from nat.myhome (192.168.128.103) by EXFESMQ04.datapipe-corp.net (192.168.128.29) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 2 Apr 2013 19:30:34 -0400 Date: Tue, 2 Apr 2013 18:30:32 -0500 From: "Paul A. Procacci" To: Yuri Subject: Re: Is it possible to slow down the network interface? Message-ID: <20130402233032.GB21122@nat.myhome> References: <515B6906.7000305@rawbw.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <515B6906.7000305@rawbw.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [192.168.128.103] Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 23:31:45 -0000 On Tue, Apr 02, 2013 at 04:25:58PM -0700, Yuri wrote: > For the testing purposes, I would like to be able to control the maximum > speed of the interface. ipfw (pf too?) can artifically control speeds via dummynet. There are man pages describing all of the above and should be a good starting place for you. ~Paul ________________________________ This message may contain confidential or privileged information. If you are= not the intended recipient, please advise us immediately and delete this m= essage. See http://www.datapipe.com/legal/email_disclaimer/ for further inf= ormation on confidentiality and the risks of non-secure electronic communic= ation. If you cannot access these links, please notify us by reply message = and we will send the contents to you. From owner-freebsd-net@FreeBSD.ORG Wed Apr 3 00:15:44 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 04785D84 for ; Wed, 3 Apr 2013 00:15:44 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-gh0-f173.google.com (mail-gh0-f173.google.com [209.85.160.173]) by mx1.freebsd.org (Postfix) with ESMTP id BA9536CE for ; Wed, 3 Apr 2013 00:15:43 +0000 (UTC) Received: by mail-gh0-f173.google.com with SMTP id g16so163425ghb.18 for ; Tue, 02 Apr 2013 17:15:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=//1jSGNXtjOGAx12SocS9wvjySZVEPmuyxoY1aUnzSY=; b=Q2rByz7/L0+Vh6zi1152bTI/kh2Red7i3NDO1KBgEp7z1OXQT7P+XxXNS0zxJ0FLuC BSifoI/lYF8cABcr0P6L0WazvGOFT3bTEWLjC5I2lpZ3xEoMzSBI8HAnf+qq8oNv3up7 gQ7003KgI+quO4kVIVHjBocWoTH6xWDOqNHjI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=//1jSGNXtjOGAx12SocS9wvjySZVEPmuyxoY1aUnzSY=; b=S3BV1RAnpIzu3Xk/JgL4hXeS9wCU3KS8v+B5Wo++EdcMuZS0fXQPrRuaUB6S5joJ5h dZEK/b4CpTCe1QTDOdnVhhtHraF6Tv/KqS3tcMt2Y++c8CaZEDzm9GVxvl6GvBfOJELF LddErd6eI19W01ZAYXwB1Jto6t68hfPbUXC0iNnUUc3WG/UXKsUKmMVkTSJv86BFJz2i NiJwltMCdLVjoWhu5pVKtPlTzylnz7uganTEzPtDvgWgGZYBiB6tVRo7nSEjFcg/ELjk uLUo0S0NWI7dH5GF1jBTc4Y7zQg5+kur9TMd/Ej9b5snw80kcuD6/O25JDtj3QDV2ZUn Qbvw== X-Received: by 10.236.124.200 with SMTP id x48mr17222549yhh.180.1364948136823; Tue, 02 Apr 2013 17:15:36 -0700 (PDT) Received: from [10.24.132.116] (h96-60-216-253.wyngmi.dedicated.static.tds.net. [96.60.216.253]) by mx.google.com with ESMTPS id o31sm6563006yhh.21.2013.04.02.17.15.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Apr 2013 17:15:35 -0700 (PDT) References: <515B6906.7000305@rawbw.com> Mime-Version: 1.0 (1.0) In-Reply-To: <515B6906.7000305@rawbw.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <4B9E361F-D9E7-4A58-A3C1-4E31E3BAF445@DataIX.net> X-Mailer: iPhone Mail (10B146) From: Jason Hellenthal Subject: Re: Is it possible to slow down the network interface? Date: Tue, 2 Apr 2013 20:15:28 -0400 To: Yuri X-Gm-Message-State: ALoCoQn3M6vtn/OeApT3NsTOvicpNwpQR2KQ7MofCG6e0jzVNOfLRs1okLBDyGYWTMqssDKj5nll Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 00:15:44 -0000 Bandwidth limiting via pf or ipfw ? ipfw may be more forward to use since its usually easier to comprehend the s= yntax and type it directly on the command line. --=20 Jason Hellenthal JJH448-ARIN - (2^(N-1)) On Apr 2, 2013, at 19:25, Yuri wrote: > For the testing purposes, I would like to be able to control the maximum s= peed of the interface. > There is this command 'ifconfig re0 media 10baseT/UTP' that is supposed to= lower the speed to 10Mbps. However, it makes interface unusable on my syste= m. All connections are broken, even the router had to be rebooted. Maybe thi= s is the router issue. >=20 > Is there any other, "soft" way to change maximum interface speed to a part= icular value? > When somebody sends data too fast, OS sends back ICMP notifications that c= onnection is jammed. My question is, is it possible to impose such condition= artificially? > Is 'ifconfig re0 media 10baseT/UTP' actually supposed to work transparentl= y, or disconnects are to be expected? >=20 > Yuri > _______________________________________________ > 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" From owner-freebsd-net@FreeBSD.ORG Wed Apr 3 01:23:37 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 289E0843; Wed, 3 Apr 2013 01:23:37 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mx1.freebsd.org (Postfix) with ESMTP id 44E379CA; Wed, 3 Apr 2013 01:23:35 +0000 (UTC) Received: by mail-lb0-f172.google.com with SMTP id u10so1077525lbi.31 for ; Tue, 02 Apr 2013 18:23:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=YF7qJn1qjTsNSl8Q2rB/VetKdlPHtNL/w28KyhOzY/w=; b=jNMOPJ4ey8E90dTDVzSxMQV2upqa4R2f2ZrqEPp5ckvfUCh9jX6EbBO9MmMWmY9Bdr DSCVEeb72fsUSfTu7e9ovbAU+R5zbIBgknZbSpPJOEDs/ngTmnA68TJuYLdF9EJ01+7t 75rqz/uWN3TAflxxjo2K5ncIRjPZVlkX/rBtC6FFW+O3eBJZivyUj0nq6DuDipyMbJWP 0RBu7HB++n5gx2E1c49mBzxb18vyCCRBIA07lYNTHHKRWxoYRK45QXvocO8xL2oAhD9b QK9JNpkFJqhRYfGbz9Pi6DVKCbZoJv2fYGiVz6ZeXTVuyfm0Lw2qhqQ2319SDDeRbYxW 0rvQ== MIME-Version: 1.0 X-Received: by 10.112.6.234 with SMTP id e10mr61890lba.46.1364952214688; Tue, 02 Apr 2013 18:23:34 -0700 (PDT) Received: by 10.114.48.102 with HTTP; Tue, 2 Apr 2013 18:23:34 -0700 (PDT) In-Reply-To: References: <5146121B.5080608@FreeBSD.org> <514649A5.4090200@freebsd.org> <3659B942-7C37-431F-8945-C8A5BCD8DC67@ipfw.ru> <51471974.3090300@freebsd.org> Date: Wed, 3 Apr 2013 09:23:34 +0800 Message-ID: Subject: Re: MPLS From: Sepherosa Ziehau To: Sami Halabi Content-Type: text/plain; charset=ISO-8859-1 Cc: "Alexander V. Chernikov" , Andre Oppermann , "Alexander V. Chernikov" , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 01:23:37 -0000 On Tue, Apr 2, 2013 at 9:01 PM, Sami Halabi wrote: >>At least, the per-CPU netisr and other related per-CPU network stuffs >>(e.g. routing table) work quite well as we have _expected_ (the >>measured bi-directional IPv4 forwarding performance w/ fastforwarding >>is 5.6Mpps+, w/o fastforwarding 4.6Mpps+ > are you talking about the work Luigi did with Netmap? or performance out of > the box in GENERIC? This is what I have measured on DragonFly (we have not yet imported netmap). Best Regards, sephe -- Tomorrow Will Never Die From owner-freebsd-net@FreeBSD.ORG Wed Apr 3 08:41:33 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AC21AFA8 for ; Wed, 3 Apr 2013 08:41:33 +0000 (UTC) (envelope-from artemrts@ukr.net) Received: from ffe8.ukr.net (ffe8.ukr.net [195.214.192.88]) by mx1.freebsd.org (Postfix) with ESMTP id 66898D30 for ; Wed, 3 Apr 2013 08:41:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Date:Message-Id:From:To:References:In-Reply-To:Subject:Content-Type:Content-Transfer-Encoding:MIME-Version; bh=P3KBiA3DBuW8lQvOblsVbJFBeuf44SHjJm2MW+a32qY=; b=qBX742VXZ6x5163ZbNeMTgL+MLTnmWnu8BqSt/CQQvWzeAtaPRtGgMZN4pxrpAhNYIV3VHkKIGl0ZE5ehsRUqmE2yqBdnlJD9n8nFv/yU3+dYm1y8FLdZkOhn6UqICucOQ6+egYk4HLjm9u9X7OznbORSkYgl4K7ZIuZb8UNgkE=; Received: from mail by ffe8.ukr.net with local ID 1UNJG1-0004hX-F2 for freebsd-net@freebsd.org; Wed, 03 Apr 2013 11:41:25 +0300 MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: binary Content-Type: text/plain; charset="windows-1251" Subject: Re[2]: Is it possible to slow down the network interface? In-Reply-To: <4B9E361F-D9E7-4A58-A3C1-4E31E3BAF445@DataIX.net> References: <515B6906.7000305@rawbw.com> <4B9E361F-D9E7-4A58-A3C1-4E31E3BAF445@DataIX.net> To: freebsd-net@freebsd.org From: "wishmaster" X-Mailer: freemail.ukr.net 4.0 Message-Id: <11798.1364978485.4558429568794034176@ffe8.ukr.net> Date: Wed, 03 Apr 2013 11:41:25 +0300 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 08:41:33 -0000 --- Original message --- From: "Jason Hellenthal" Date: 3 April 2013, 03:16:11 > Bandwidth limiting via pf or ipfw ? IPFW for this task is the best choice since PF has ALTQ which is 1990s technology. For the experimental/testing tasks IPFW has another advantage: this is possibility use as bandwidth limitation as well as delay. From owner-freebsd-net@FreeBSD.ORG Wed Apr 3 14:51:54 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AB1D3849 for ; Wed, 3 Apr 2013 14:51:54 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by mx1.freebsd.org (Postfix) with ESMTP id 7E28F691 for ; Wed, 3 Apr 2013 14:51:54 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id k1so1598905oag.19 for ; Wed, 03 Apr 2013 07:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=4V2L6EtO7bpXpNJ8whmLzG+zkxRC6Pd+A77jTdeOGIw=; b=KR1CYed7ctN/VEw2ou4VoPBax9Lsj/P82t7Fsa/EDBcCtC7vvXzxHk/GoIVw1cajXn TsLGgOvq8Kcqu8VL/7TdNxjxheULp/TU4sfOhvKBHWUznH/j4VI8eC+Y4TP9XCm7TIsd xOuRsZZs9JTg5HvojG5jakjb/VNJPPl/cj4pyFhNOsAucnsoVlncf2sYUQo+pfpjRlYi FemxYrc2neSB6OjX/OItvYjn8oZ4TfmAa6S6Wz5DZFffiZJ0PhpXOys0QFVcj5Ll2G4Y 98L7mm8TpjKJBNbTF145qz8S/l0VI6SYJWUMqXaWvdmsDUhwdRBEG4bFgY9+EthaPpRY r0ww== MIME-Version: 1.0 X-Received: by 10.182.24.10 with SMTP id q10mr1296947obf.12.1365000713733; Wed, 03 Apr 2013 07:51:53 -0700 (PDT) Received: by 10.76.122.81 with HTTP; Wed, 3 Apr 2013 07:51:53 -0700 (PDT) Date: Wed, 3 Apr 2013 16:51:53 +0200 Message-ID: Subject: gre tunnel woes From: Andreas Nilsson To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 14:51:54 -0000 Hello, I'm struggling a fair bit with gre tunnels today: Woe 1: I'm trying to incorporate my gre tunnels into rc.conf, like cloned_interfaces="gre1" ifconfig_gre1="inet 10.0.0.1/30 10.0.0.2 tunnel a.b.c.d e.f.g.h" but after boot I get: gre1: flags=9011 metric 0 mtu 1476 tunnel inet a.b.c.d --> e.f.g.h inet 10.0.0.1 --> 10.0.0.2 netmask 0xfffffffc nd6 options=29 ie, the tunnel is down. Both "ifconfig gre1 up" and "service netif restart gre1" brings the tunnel up: gre1: flags=9051 metric 0 mtu 1476 tunnel inet a.b.c.d --> e.f.g.h inet 10.0.0.1 --> 10.0.0.2 netmask 0xfffffffc nd6 options=29 Adding "up" to the interface ifconfig line in rc.conf makes no difference. So, how do I get the tunnel(s) to start automatically at boot? Woe 2: Is there no other way than successfully pinging the remote endpoint to tell if the tunnel is "up and running" as it should? Quite often I get gre interfaces that tell me both UP and RUNNING flags from ifconfig, but tunnel is still down. Woe 3: After doing ifconfig greX destroy ; ifconfig greX create , the interface comes up with the old configuration. Is that really the expected behavior? I noticed that lagg interfaces does exactly the same thing. Best regards Andreas Nilsson From owner-freebsd-net@FreeBSD.ORG Wed Apr 3 15:21:42 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CB3B6733 for ; Wed, 3 Apr 2013 15:21:42 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by mx1.freebsd.org (Postfix) with ESMTP id 9BBCE901 for ; Wed, 3 Apr 2013 15:21:42 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id k14so1608542oag.25 for ; Wed, 03 Apr 2013 08:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=j51j4w7gYFD0F3B8b6pLywZm3mvPbUTsWHku97Vl+Xs=; b=CTqCZcZkxYcx+kxdFoaj0Mg7Lg5CuGTlCwtcbiZBt+RH+xdkmHBpCkJNuYtZxar21E vQoRaJ1KrdN3hanL4y9IwC0VokgfJFsXPo2JgAp5hRdq600b8/obl8yllGixsaveqxdu gYujx7z0OmAekhH/u4TOUC89JCQ22wsQ4Xw4c9dFej/s4aMoKbF5KCJ7RLGt80sYWujQ 98pMc7rK7bxplOVl14unoELgfmg27s9+xs9QDeWffOB1Udagkegp6A+3AizAi4k+7POE XvMmadIlHxF4P83uBSqYMw/Ty26cGC8RIfgOzzL7ICsr4qpu6OVxQhUAVqkkTv93woe0 LIVw== MIME-Version: 1.0 X-Received: by 10.60.31.15 with SMTP id w15mr1462362oeh.0.1365002501791; Wed, 03 Apr 2013 08:21:41 -0700 (PDT) Received: by 10.76.122.81 with HTTP; Wed, 3 Apr 2013 08:21:41 -0700 (PDT) In-Reply-To: <20130403150053.GC5100@calendar.blacquiere.nl> References: <20130403150053.GC5100@calendar.blacquiere.nl> Date: Wed, 3 Apr 2013 17:21:41 +0200 Message-ID: Subject: Re: gre tunnel woes From: Andreas Nilsson To: Robert Blacquiere Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 15:21:42 -0000 On Wed, Apr 3, 2013 at 5:00 PM, Robert Blacquiere wrote: > On Wed, Apr 03, 2013 at 04:51:53PM +0200, Andreas Nilsson wrote: > > Hello, > > > > I'm struggling a fair bit with gre tunnels today: > > > > Woe 1: > > > > I'm trying to incorporate my gre tunnels into rc.conf, like > > > > cloned_interfaces="gre1" > > ifconfig_gre1="inet 10.0.0.1/30 10.0.0.2 tunnel a.b.c.d e.f.g.h" > > I have "up" at the end of the ifconfig_gre0 statements and tunnels work > also after reboot. > > For the other problems you are seeing I have no answer. There is no keep > alive for as i know to change tunnel to down if tunnel fails. > > Regards > > Robert > Thanks, good to know there is hope. Unfortunately adding up directive at the end of the ifconfig-line makes no difference :( I should also have mentioned that this is on 9.1-RELEASE. The host is multihomed, so the tunnels needs a route installed to "go the right way", ie they should not go over the default route. Maybe I should just add the NOAUTO keyword and create a local rc.d service that start all tunnels... Best regards Andreas From owner-freebsd-net@FreeBSD.ORG Wed Apr 3 15:30:01 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6C031C3F for ; Wed, 3 Apr 2013 15:30:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 5E06E9B3 for ; Wed, 3 Apr 2013 15:30:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r33FU1xp097999 for ; Wed, 3 Apr 2013 15:30:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r33FU1AY097998; Wed, 3 Apr 2013 15:30:01 GMT (envelope-from gnats) Date: Wed, 3 Apr 2013 15:30:01 GMT Message-Id: <201304031530.r33FU1AY097998@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Gleb Smirnoff Subject: Re: misc/177456: An error of calculating TCP sequence number will resault in the machine to restart X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Gleb Smirnoff List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 15:30:01 -0000 The following reply was made to PR kern/177456; it has been noted by GNATS. From: Gleb Smirnoff To: ?????? Cc: bug-followup@FreeBSD.org Subject: Re: misc/177456: An error of calculating TCP sequence number will resault in the machine to restart Date: Wed, 3 Apr 2013 19:21:12 +0400 Hi! On Wed, Apr 03, 2013 at 07:52:42AM +0800, ?????? wrote: ?> I mean there is a bug in FreeBSD's tcp code. I'm trying to describe it by pictuer. Pelease see the attachments?? I am trying to model what you are describing in the picture by special crafted code. I intentionally model memory allocation failure on first two packets for a connection that has special socket option. I'm modelling allocation failure at tcp_output.c near line 900: Index: tcp_output.c =================================================================== --- tcp_output.c (revision 249051) +++ tcp_output.c (working copy) @@ -898,6 +898,13 @@ send: else TCPSTAT_INC(tcps_sndwinup); + /* Fail allocating first 2 packets. */ + if (tp->t_flags & TF_ZHOPA && tp->t_zhopa < 2) { + tp->t_zhopa++; + m = NULL; + error = ENOBUFS; + goto out; + } else m = m_gethdr(M_NOWAIT, MT_DATA); if (m == NULL) { error = ENOBUFS; I have no success in reproducing your problems. With above code, first 2 packets are failing to allocate, but third retransmission succeeds and connection is established with no problems. May be I incorrectly understand your description :( Please don't give up and try to explain again. A modelling code that demonstrates problem would be appreciated. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Wed Apr 3 15:35:04 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EFF63178 for ; Wed, 3 Apr 2013 15:35:04 +0000 (UTC) (envelope-from robert@blacquiere.nl) Received: from mail.blacquiere.nl (mail.blacquiere.nl [78.47.62.196]) by mx1.freebsd.org (Postfix) with ESMTP id AA917A3F for ; Wed, 3 Apr 2013 15:35:04 +0000 (UTC) Received: from calendar.blacquiere.nl ([192.168.201.5] helo=shell.blacquiere.nl) by mail.blacquiere.nl with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1UNPAQ-000DLc-3s; Wed, 03 Apr 2013 17:00:02 +0200 Date: Wed, 3 Apr 2013 17:00:53 +0200 From: Robert Blacquiere To: FreeBSD Net Message-ID: <20130403150053.GC5100@calendar.blacquiere.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: 192.168.201.5 X-SA-Exim-Mail-From: robert@blacquiere.nl X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail.blacquiere.nl X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 Subject: Re: gre tunnel woes X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail.blacquiere.nl) Cc: Andreas Nilsson X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 15:35:05 -0000 On Wed, Apr 03, 2013 at 04:51:53PM +0200, Andreas Nilsson wrote: > Hello, > > I'm struggling a fair bit with gre tunnels today: > > Woe 1: > > I'm trying to incorporate my gre tunnels into rc.conf, like > > cloned_interfaces="gre1" > ifconfig_gre1="inet 10.0.0.1/30 10.0.0.2 tunnel a.b.c.d e.f.g.h" I have "up" at the end of the ifconfig_gre0 statements and tunnels work also after reboot. For the other problems you are seeing I have no answer. There is no keep alive for as i know to change tunnel to down if tunnel fails. Regards Robert From owner-freebsd-net@FreeBSD.ORG Wed Apr 3 16:17:49 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E50C2972 for ; Wed, 3 Apr 2013 16:17:49 +0000 (UTC) (envelope-from freebsd-net@dino.sk) Received: from mailhost.netlab.sk (mailhost.netlab.sk [84.245.65.10]) by mx1.freebsd.org (Postfix) with ESMTP id 77903DBA for ; Wed, 3 Apr 2013 16:17:49 +0000 (UTC) Received: from zeta.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: LOGIN milan, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by mailhost.netlab.sk with ESMTPSA; Wed, 03 Apr 2013 18:18:06 +0200 id 0066121C.515C563E.00011C4D Date: Wed, 3 Apr 2013 18:17:47 +0200 From: Milan Obuch To: Andreas Nilsson Subject: Re: gre tunnel woes Message-ID: <20130403181747.0fa7677e@zeta.dino.sk> In-Reply-To: References: <20130403150053.GC5100@calendar.blacquiere.nl> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.17; amd64-portbld-freebsd9.1) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEX+/v7++v6YOTrq8PCcuIX989UvOSj++v0BNCbpAAAAB3RJTUUHsQwfFzs7RBhzUQAAAhJJREFUOI1dU8GOqzAMNKIoV1bvwD1i0ysqrHplIdBrVSX7ATSbd03VVvn9tQNtQy0hjAdn7LED4AAcPtWm9RV+MPSfxhBLx9ajd6X/ngB6/mTwnRSZua7i7Ca+0ctZKo4Qmz+JY13X6I3nFZBxIYW1PbgfQ5RP8g0XlltEWGf3cV03joYpRnFbvYDKbXjZlXyyhEZA4lI+cN3NaVXE4VKjSwTExO10eTEkkJVqIAD5z0nUBQJluQDRSQjcrBiHAJxZlAH5CUMBMC7OcJ4LMQNnxhZ1HYPscMc6J4UlWRMNwzOpCcAHKSICd1EDn83abdREIbXsHkD1OinP1aCUCOEVRaa1lMcvywUWdYgk13JQUpYNKmvXQ8Kw5ML9YI5h8SakctBc7E/IYuLhYd/zZIk+1gM1vNweQBvHE0j+oYah3sMqAytQYlZk6+ANaaawJdu3OFzYGMZ3iGpa3qMlq9ZH0VZTgrCtw/ngdYkEIIpSbP1bWQAdFdX9vocBdkH2qVjVmuMu3gI5rjs814EUdrCZgWlPaxZZ3RiLFUtr+ud0PXwp2dnQSNXgePt6AZpBj6UMJ7VQkzN4utVeaSW1Dhn/kblGrKeMvNGnzwX4zuEDarYz1KdPtR60Gul0Gued+515SJXhCsl+Tx/3kY/UDvicPll9mfu50t3tvQ/thZpJYgeuwdSKNJ6tCD98MCgoxLDaPxbwqqwPWaWiAAAAAElFTkSuQmCC X-Face: ak5rwz4-aUa>hPFZlcg,bXxn.(TN}e9DGFrKU\.i_'B[&5=pAd9o"j)5VSUYW:BRQG#^42Ev$Il|; Ztn=,C X-Operating-System: FreeBSD/amd64 8.2-STABLE Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Robert Blacquiere , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 16:17:50 -0000 On Wed, 3 Apr 2013 17:21:41 +0200 Andreas Nilsson wrote: > On Wed, Apr 3, 2013 at 5:00 PM, Robert Blacquiere > > wrote: > > > On Wed, Apr 03, 2013 at 04:51:53PM +0200, Andreas Nilsson wrote: > > > Hello, > > > > > > I'm struggling a fair bit with gre tunnels today: > > > > > > Woe 1: > > > > > > I'm trying to incorporate my gre tunnels into rc.conf, like > > > > > > cloned_interfaces="gre1" > > > ifconfig_gre1="inet 10.0.0.1/30 10.0.0.2 tunnel a.b.c.d e.f.g.h" > > > > I have "up" at the end of the ifconfig_gre0 statements and tunnels > > work also after reboot. > > > > For the other problems you are seeing I have no answer. There is no > > keep alive for as i know to change tunnel to down if tunnel fails. > > > > Regards > > > > Robert > > > > Thanks, > > good to know there is hope. Unfortunately adding up directive at the > end of the ifconfig-line makes no difference :( > > I should also have mentioned that this is on 9.1-RELEASE. The host is > multihomed, so the tunnels needs a route installed to "go the right > way", ie they should not go over the default route. Maybe I should > just add the NOAUTO keyword and create a local rc.d service that > start all tunnels... > > Best regards > Andreas > Well, I am struggling with this too, and now I just use /etc/rc.local containing #!/bin/sh ifconfig gre0 up ifconfig gre1 up to bring tunnels to real life. Maybe not that nice, but simple and working. Milan From owner-freebsd-net@FreeBSD.ORG Wed Apr 3 16:45:15 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F3EB8310 for ; Wed, 3 Apr 2013 16:45:14 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (unknown [IPv6:2001:470:1f09:14c0::2]) by mx1.freebsd.org (Postfix) with ESMTP id A6A4AF45 for ; Wed, 3 Apr 2013 16:45:14 +0000 (UTC) Received: from [192.168.248.34] ([192.168.248.34]) by elf.hq.norma.perm.ru (8.14.5/8.14.5) with ESMTP id r33Gj6vb014670 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 3 Apr 2013 22:45:07 +0600 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <515C5C8C.50708@norma.perm.ru> Date: Wed, 03 Apr 2013 22:45:00 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: gre tunnel woes References: <20130403150053.GC5100@calendar.blacquiere.nl> <20130403181747.0fa7677e@zeta.dino.sk> In-Reply-To: <20130403181747.0fa7677e@zeta.dino.sk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [192.168.3.10]); Wed, 03 Apr 2013 22:45:08 +0600 (YEKT) X-Spam-Status: No hits=-101.0 bayes=0.5 testhits ALL_TRUSTED=-1, USER_IN_WHITELIST=-100 autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 16:45:15 -0000 Hi. On 03.04.2013 22:17, Milan Obuch wrote: > Well, I am struggling with this too, and now I just use /etc/rc.local > containing > > #!/bin/sh > > ifconfig gre0 up > ifconfig gre1 up > > to bring tunnels to real life. Maybe not that nice, but simple and > working. > > It's an ancient bug; it's reported in GNATS ( http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/164475 - it was known long before the report, once I just decided to actually put it in GNATS; unfortunately, it wasn't fixed). Actually, as I can remember, this was never working since gre(4) was introduced in 4.x (for various reasons). It's somehow related with default route for the tunnel remote end, but anyway this still isn't fixed. And yeah, everyone who's using gre is using some sort of custom rc script to fix the RUNNING flag after a boot. Eugene. From owner-freebsd-net@FreeBSD.ORG Wed Apr 3 21:29:28 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2A0C16C0 for ; Wed, 3 Apr 2013 21:29:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0A18CFD6 for ; Wed, 3 Apr 2013 21:29:28 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 65C6AB968; Wed, 3 Apr 2013 17:29:27 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: Small patch in OFED/sdp Date: Wed, 3 Apr 2013 16:31:20 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201304031631.20358.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 03 Apr 2013 17:29:27 -0400 (EDT) Cc: Vijay Singh X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 21:29:28 -0000 On Tuesday, April 02, 2013 2:33:18 pm Vijay Singh wrote: > Hi, this is based on the the understanding that the SS_NBIO is a > socket state, and not a state of the socket buffer. Committed, thanks! -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Wed Apr 3 22:00:01 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 65AC1CA for ; Wed, 3 Apr 2013 22:00:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 403C5210 for ; Wed, 3 Apr 2013 22:00:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r33M01HU068898 for ; Wed, 3 Apr 2013 22:00:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r33M01EV068897; Wed, 3 Apr 2013 22:00:01 GMT (envelope-from gnats) Date: Wed, 3 Apr 2013 22:00:01 GMT Message-Id: <201304032200.r33M01EV068897@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: dfilter@FreeBSD.ORG (dfilter service) Subject: Re: kern/177384: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 22:00:01 -0000 The following reply was made to PR kern/177384; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/177384: commit references a PR Date: Wed, 3 Apr 2013 21:55:27 +0000 (UTC) Author: sbruno Date: Wed Apr 3 21:55:19 2013 New Revision: 249070 URL: http://svnweb.freebsd.org/changeset/base/249070 Log: Update man page for igb(4) with a little bit of information about hw.igb.num_queues for those so inclined. PR: kern/177384 Submitted by: hiren.panchasara@gmail.com Reviewed by: sbruno@ Approved by: jfv@ Obtained from: Yahoo! Inc. MFC after: 2 weeks Modified: head/share/man/man4/igb.4 head/sys/dev/e1000/if_igb.c Modified: head/share/man/man4/igb.4 ============================================================================== --- head/share/man/man4/igb.4 Wed Apr 3 21:34:35 2013 (r249069) +++ head/share/man/man4/igb.4 Wed Apr 3 21:55:19 2013 (r249070) @@ -31,7 +31,7 @@ .\" .\" $FreeBSD$ .\" -.Dd May 12, 2012 +.Dd March 25, 2013 .Dt IGB 4 .Os .Sh NAME @@ -160,6 +160,11 @@ The minimum is 80, and the maximum is 40 .It Va hw.igb.enable_aim If set to 1, enable Adaptive Interrupt Moderation. The default is to enable Adaptive Interrupt Moderation. +.It Va hw.igb.num_queues +Numer of queues used for data transfer. +If set to 0, number of queues will be configured +automatically based on number of CPUs and max +supported MSI-X messages on the device. .It Va kern.ipc.nmbclusters The maximum number of mbuf clusters allowed. If the system has more than one igb card or jumbo frames are Modified: head/sys/dev/e1000/if_igb.c ============================================================================== --- head/sys/dev/e1000/if_igb.c Wed Apr 3 21:34:35 2013 (r249069) +++ head/sys/dev/e1000/if_igb.c Wed Apr 3 21:55:19 2013 (r249070) @@ -375,7 +375,8 @@ SYSCTL_INT(_hw_igb, OID_AUTO, header_spl /* ** This will autoconfigure based on -** the number of CPUs if left at 0. +** the number of CPUs and max supported MSI-X messages +** if left at 0. */ static int igb_num_queues = 0; TUNABLE_INT("hw.igb.num_queues", &igb_num_queues); _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Apr 4 11:24:28 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 24287728 for ; Thu, 4 Apr 2013 11:24:28 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by mx1.freebsd.org (Postfix) with ESMTP id 0DB2F81B for ; Thu, 4 Apr 2013 11:24:25 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.87,408,1363158000"; d="scan'208";a="37012270" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 04 Apr 2013 04:24:19 -0700 Received: from vmwexceht05-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.77.35]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r34BOJPD002176 for ; Thu, 4 Apr 2013 04:24:19 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.218]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0342.003; Thu, 4 Apr 2013 04:24:19 -0700 From: "Eggert, Lars" To: "freebsd-net@freebsd.org" Subject: enable tcpdump GUESS_TSO flag? Thread-Topic: enable tcpdump GUESS_TSO flag? Thread-Index: AQHOMSbyh8pfApUoREqP7JnSG2Yuog== Date: Thu, 4 Apr 2013 11:24:18 +0000 Message-ID: <0A5ED929-C148-45C3-8576-C31D2C05AB04@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 11:24:28 -0000 Hi, I wonder whether it'd be a good idea to enable tcpdump's GUESS_TSO flag by = default? It enables a heuristic that lets tcpdump understand pcaps that inc= lude segments generated by TCP TSO (which otherwise show up as "IP bad-len = 0".) See the dicussion at http://www.mail-archive.com/tcpdump-workers@lists.tcpd= ump.org/msg01051.html for details. Lars diff --git a/usr.sbin/tcpdump/tcpdump/Makefile b/usr.sbin/tcpdump/tcpdump/M= akefile index ca8ec4c..5fd73a1 100644 --- a/usr.sbin/tcpdump/tcpdump/Makefile +++ b/usr.sbin/tcpdump/tcpdump/Makefile @@ -45,6 +45,10 @@ CFLAGS+=3D -I${.CURDIR} -I${TCPDUMP_DISTDIR} CFLAGS+=3D -DHAVE_CONFIG_H CFLAGS+=3D -D_U_=3D"__attribute__((unused))" =20 +# Enable tcpdump heuristic to identify TSO-generated packets; see +# http://www.mail-archive.com/tcpdump-workers@lists.tcpdump.org/msg01051.h= tml +CFLAGS+=3D -DGUESS_TSO + .if ${MK_INET6_SUPPORT} !=3D "no" SRCS+=3D print-ip6.c print-ip6opts.c print-mobility.c print-ripng.c \ print-icmp6.c print-babel.c print-frag6.c print-rt6.c print-ospf6.c \ From owner-freebsd-net@FreeBSD.ORG Thu Apr 4 13:24:44 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BF24C7F7 for ; Thu, 4 Apr 2013 13:24:44 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm28-vm1.bullet.mail.ne1.yahoo.com (nm28-vm1.bullet.mail.ne1.yahoo.com [98.138.91.35]) by mx1.freebsd.org (Postfix) with ESMTP id 58E58A1 for ; Thu, 4 Apr 2013 13:24:44 +0000 (UTC) Received: from [98.138.90.50] by nm28.bullet.mail.ne1.yahoo.com with NNFMP; 04 Apr 2013 13:22:49 -0000 Received: from [98.138.89.167] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 04 Apr 2013 13:22:49 -0000 Received: from [127.0.0.1] by omp1023.mail.ne1.yahoo.com with NNFMP; 04 Apr 2013 13:22:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 750812.47253.bm@omp1023.mail.ne1.yahoo.com Received: (qmail 24560 invoked by uid 60001); 4 Apr 2013 13:22:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1365081769; bh=ym804P0oRea/mnU5rCUWcDRnG8BpcjanuJEy92Zvh5Q=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=JZL0SiJJB4hLVJ0TOg9FRRV8d/DvaS23++Z0JtpNn8PWaHrdSsVTQeuKusg4Eo9s48Fg+i+mocpg92wlu7igOqZMXF7h/NN6WQu5bMcQxJbuNy4Sp+2uj2nwsAYoJjQ8+sFZ9wIxIDnK8SCwNuzBbzg4YgPKwtGcdZld1xla2Zw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ZnluK0njS/Zkx/5zD/W+BwSmfRzAmpoD5gqoMsamzjbkRjC919WwTAai/OnTCgVnAQPsA8/O3XvNpO7vpO7ObmDk60+Owyae6A6/5tiSA4ijieahOqYakIgI3LLSfS9yt7bPYzdxuDefhddU+CJfNWb+HpWXniN6NJnSabhdLnc=; X-YMail-OSG: 3XwEZSUVM1kTjZVSJk9IlcMgQCyxPk6fdUGAx1c5j1CwWDC E3O61xKwAT8aoL8sqS1v8WzI0eKzxWeNtHq5eBkwsQ3EJ8i3DUkV3NUcWVE2 dmTRPFeK7kUpJxRAPuLhdAwNGPy8hDXV46mGQW46UopdQfyuJ1q8J8t0xCyP QKLJzd8km1dKYWWtqqveBkRXfWGASuWkQKXItwHWZ5gG0lN.46VmKLSUVxNT LVAdjIW4yBCDl0B8PRVIbGOJabTrQcbPKiPXwyS_0q6cQVeizLWg3iAKk5OJ YcNfgYJ0aguGjYoItgvuVVj.Z4_pqf8pKQJvFyjptirCLpvkZ9_Zmn8PtDOw Nlux3ly1ITBirFaGYw_izZeXB8hape4rFS8hSdNsx6QMdRxdPxzyXPNK.ci4 E0KUr207H6eyZmJjM_RW2fmoLNFDTmtHjySoq91i.U1_yUSSJJ.VePJYjk7O YAGRKGcaahzxua8BUfOA7Da4x48IwCQm9tlsBBS38MPM5.eqgl0yQGYJXAZX 20LDhml4f4L2QVhVF.C.sl2Lkz.3M4g-- Received: from [98.203.118.124] by web121604.mail.ne1.yahoo.com via HTTP; Thu, 04 Apr 2013 06:22:49 PDT X-Rocket-MIMEInfo: 002.001, Rmlyc3RseSwgbXkgT1Agd2FzIG5vdCBpbnRlbmRlZCB0byBoYXZlIGFueXRoaW5nIHRvIGRvIHdpdGggSmFjay4gCkZyYW5rbHksIGhlJ3MganVzdCBhIG1lY2hhbmljYWwgcHJvZ3JhbW1lciBhbmQgbm90IGEgZGVzaWduZXIsIHNvIGl0cyAKb3RoZXJzIHRoYXQgc2hvdWxkIGJlIHJlc3BvbnNpYmxlIGZvciBndWlkaW5nIGhpbS4gVGhlcmUgKnNob3VsZCogYmUKc29tZW9uZSBhdCBGcmVlQlNEIHdobyBpcyByZXNwb25zaWJsZSBmb3IgdGFraW5nIG1lY2hhbmljYWxseSBzb3VuZCBkcml2ZXJzCmFuZCBvcHQBMAEBAQE- X-Mailer: YahooMailClassic/15.1.7 YahooMailWebService/0.8.140.532 Message-ID: <1365081769.21825.YahooMailClassic@web121604.mail.ne1.yahoo.com> Date: Thu, 4 Apr 2013 06:22:49 -0700 (PDT) From: Barney Cordoba Subject: Re: igb and ALTQ in 9.1-rc3 To: Adrian Chadd In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jeffrey EPieper , Nick Rogers , "Clement Hermann \(nodens\)" , Jack Vogel , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 13:24:44 -0000 Firstly, my OP was not intended to have anything to do with Jack. Frankly, he's just a mechanical programmer and not a designer, so its others that should be responsible for guiding him. There *should* be someone at FreeBSD who is responsible for taking mechanically sound drivers and optimizing them. But in the open source world, that function doesn't usually exist. But the idea that the FreeBSD community refuses to point out that some things just don't work well hurts people in the community. The portrayal of every feature in FreeBSD as being equally useful and well done doesn't provide the information that users need to make decisions about what to use to run their businesses. It also hurts people that you've made IGB worse in FreeBSD 9. There's *some* expectation that it should be better in 9 than 7 or 8, and that it should have fewer bugs. But in an effort to force in a rickety implementation of multi-queue, you've converted the driver into something that is guaranteed to rob any system of cpu cycles. I wrote a multiqueue driver for 7 for igb that works very well, and I'd hoped to be able to use igb in 9 without having to port it, even if it wasn't as good. But it's not just not as good; it's unusable in a heavy production environment. While it's noble (and convenient) for you folks who have jobs where you get paid to write open source code to rip others for "not contributing", Im sure that some of you with real jobs know that when someone pays you a lot of money to write code, you're not free to share the code or even the specific techniques publicly. After all, technique is the difference between a good and a bad driver. I try to drop hints, but Jack's lack of curiosity as to how to make the driver better is particularly troubling. So I just have to recommend that igb cards not be used for production flows, because there is little hope that it will improve any time soon. BC --- On Sun, 3/31/13, Adrian Chadd wrote: > From: Adrian Chadd > Subject: Re: igb and ALTQ in 9.1-rc3 > To: "Barney Cordoba" > Cc: "Jeffrey EPieper" , "Nick Rogers" , "Clement Hermann (nodens)" , "Jack Vogel" , "freebsd-net@freebsd.org" > Date: Sunday, March 31, 2013, 2:48 PM > Barney, > > As much as we'd like it, Jack's full time job involves other > things > besides supporting FreeBSD. > > If you want to see it done better, please work with the > FreeBSD > developer community and improve the intel driver. No-one is > stopping > you from stepping in. > > In fact, this would be _beneficial_ to Jack's work inside > Intel with > FreeBSD. If there is more of an active community > participating with > the intel drivers and more companies choosing intel hardware > for > FreeBSD network services, Intel will likely dump more effort > into > FreeBSD. > > So please, stop your non-constructive trolling and > complaining and put > your skills to use for the greater good. > > Sheesh. Intel have supplied a very thorough, detailed driver > as well > as programming and errata datasheets for their chips. We > aren't in the > dark here. There's more than enough rope to hang ourselves > with. > Please focus on making it better. > > > Adrian > > > On 31 March 2013 05:35, Barney Cordoba > wrote: > > The reason that Jack is a no better programmer now than > he was in 2009 might have something to do with the fact that > he hides when his work is criticized. > > Why not release the benchmarks you did while designing > the igb driver, Jack? Say what,you didn't do any > benchmarking? How does the default driver perform, say in a > firewall,with 1000 user load? What's the optimum number of > queues to use in such a system?What's the effect of CPU > binding? What's the effect with multiple cards when you > havemore queues than you have physical cpus? > > What made you decide to use buf_ring? Something new to > play with? > > I'm guessing that you have no idea. > > BC--- On Fri, 3/29/13, Jack Vogel > wrote: > > > > From: Jack Vogel > > Subject: Re: igb and ALTQ in 9.1-rc3 > > To: "Pieper, Jeffrey E" > > Cc: "Barney Cordoba" , > "Nick Rogers" , > "freebsd-net@freebsd.org" > , > "Clement Hermann (nodens)" > > Date: Friday, March 29, 2013, 12:36 PM > > > > Fortunately, Barney doesn't speak for me, or for Intel, > and I've long ago realized its pointless to > > attempt anything like a fair conversation with him. The > only thing he's ever contributed is slander > > > > and pseudo-critique... another poison thread I'm done > with. > > > > Jack > > > > > > > > On Fri, Mar 29, 2013 at 8:45 AM, Pieper, Jeffrey E > > wrote: > > > > > > > > > > > > -----Original Message----- > > > > From: owner-freebsd-net@freebsd.org > [mailto:owner-freebsd-net@freebsd.org] > On Behalf Of Barney Cordoba > > > > Sent: Friday, March 29, 2013 5:51 AM > > > > To: Jack Vogel; Nick Rogers > > > > Cc: freebsd-net@freebsd.org; > Clement Hermann (nodens) > > > > Subject: Re: igb and ALTQ in 9.1-rc3 > > > > > > > > > > > > > > > > --- On Thu, 3/28/13, Nick Rogers > wrote: > > > > > > > >> From: Nick Rogers > > > >> Subject: Re: igb and ALTQ in 9.1-rc3 > > > >> To: "Jack Vogel" > > > >> Cc: "Barney Cordoba" , > "Clement Hermann (nodens)" , > "freebsd-net@freebsd.org" > > > > > > >> Date: Thursday, March 28, 2013, 9:29 PM > > > >> On Thu, Mar 28, 2013 at 4:16 PM, Jack > > > >> Vogel > > > >> wrote: > > > >> > Have been kept fairly busy with other matters, > one > > > >> thing I could do short > > > >> > term is > > > >> > change the defines in igb the way I did in the > em > > > >> driver so you could still > > > >> > define > > > >> > the older if_start entry. Right now those are > based on > > > >> OS version and so you > > > >> > will > > > >> > automatically get if_transmit, but I could > change it to > > > >> be IGB_LEGACY_TX or > > > >> > so, > > > >> > and that could be defined in the Makefile. > > > >> > > > > >> > Would this help? > > > >> > > > >> I'm currently using ALTQ successfully with the em > driver, so > > > >> if igb > > > >> behaved the same with respect to using if_start > instead of > > > >> if_transmit > > > >> when ALTQ is in play, that would be great. I do > not > > > >> completely > > > >> understand the change you propose as I am not very > familiar > > > >> with the > > > >> driver internals. Any kind of patch or extra > > > >> Makefile/make.conf > > > >> definition that would allow me to build a 9-STABLE > kernel > > > >> with an igb > > > >> driver that works again with ALTQ, ASAP, would be > much > > > >> appreciated. > > > >> > > > >> > > > > >> > Jack > > > >> > > > > >> > > > > >> > > > > >> > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers > > > > >> wrote: > > > >> >> > > > >> >> On Tue, Dec 11, 2012 at 1:09 AM, Jack > Vogel > > > >> wrote: > > > >> >> > On Mon, Dec 10, 2012 at 11:58 PM, > Gleb > > > >> Smirnoff > > > >> >> > wrote: > > > >> >> > > > > >> >> >> On Mon, Dec 10, 2012 at > 03:31:19PM -0800, > > > >> Jack Vogel wrote: > > > >> >> >> J> UH, maybe asking the owner > of the > > > >> driver would help :) > > > >> >> >> J> > > > >> >> >> J> ... and no, I've never been > aware of > > > >> doing anything to stop > > > >> >> >> supporting > > > >> >> >> altq > > > >> >> >> J> so you wouldn't see any > commits. If > > > >> there's something in the altq > > > >> >> >> code > > > >> >> >> or > > > >> >> >> J> support (which I have > nothing to do > > > >> with) that caused this no-one > > > >> >> >> informed > > > >> >> >> J> me. > > > >> >> >> > > > >> >> >> Switching from if_start to > if_transmit > > > >> effectively disables ALTQ > > > >> >> >> support. > > > >> >> >> > > > >> >> >> AFAIR, there is some magic > implemented in > > > >> other drivers that makes them > > > >> >> >> modern (that means using > if_transmit), but > > > >> still capable to switch to > > > >> >> >> queueing > > > >> >> >> mode if SIOCADDALTQ was casted > upon them. > > > >> >> >> > > > >> >> >> > > > >> >> > Oh, hmmm, I'll look into the matter > after my > > > >> vacation. > > > >> >> > > > > >> >> > Jack > > > >> >> > > > >> >> Has there been any progress on resolving > this > > > >> issue? I recently ran > > > >> >> into this problem upgrading my servers > from 8.3 to > > > >> 9.1-RELEASE and am > > > >> >> wondering what the latest recommendation > is. I've > > > >> used ALTQ and igb > > > >> >> successfully for years and it is > unfortunate it no > > > >> longer works. > > > >> >> Appreciate any advice. > > > >> >> > > > >> > > > >>Do yourself a favor and either get a cheap dual port > 82571 card or > > > >>2 cards and disable the IGB ports. The igb driver is > defective, and until > > > >>they back out the new, untested multi-queue stuff > you're just neutering > > > >>your system trying to use it. > > > >> > > > >>Frankly this project made a huge mistake by moving > forward with multi > > > >>queue just for the sake of saying that you support > it; without having > > > >>any credible plan for implementing it. That nonsense > that Bill Macy did > > > >>should have been tarballed up and deposited in the > trash folder. The > > > >>biggest mess in programming history. > > > >> > > > >>That being said, the solution is not to hack the igb > driver; its to make > > > >>ALTQ if_transmit compatible, which shouldn't be all > that difficult. > > > >> > > > >>BC > > > > > > > > I may be misunderstanding what you are saying, but if > the solution is, as you say "not to hack the igb driver", > then how is it defective in this case? Or are you just > directing vitriol toward Intel? Multi-queue is working fine > in igb. > > > > > > > > > > Jeff > > > > > > > > _______________________________________________ > > > > 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" > > > > _______________________________________________ > > > > 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" > > > > > > > > _______________________________________________ > > 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" > _______________________________________________ > 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" > From owner-freebsd-net@FreeBSD.ORG Thu Apr 4 13:41:37 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A6A812F9 for ; Thu, 4 Apr 2013 13:41:37 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm11-vm2.bullet.mail.ne1.yahoo.com (nm11-vm2.bullet.mail.ne1.yahoo.com [98.138.90.159]) by mx1.freebsd.org (Postfix) with ESMTP id 173B7216 for ; Thu, 4 Apr 2013 13:41:36 +0000 (UTC) Received: from [98.138.226.176] by nm11.bullet.mail.ne1.yahoo.com with NNFMP; 04 Apr 2013 13:39:14 -0000 Received: from [98.138.89.196] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 04 Apr 2013 13:39:14 -0000 Received: from [127.0.0.1] by omp1054.mail.ne1.yahoo.com with NNFMP; 04 Apr 2013 13:39:14 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 617566.31629.bm@omp1054.mail.ne1.yahoo.com Received: (qmail 61347 invoked by uid 60001); 4 Apr 2013 13:39:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1365082754; bh=I6Zs/WujGx7BqMNxTw84g+lMob65cQXOysd9JbuPhGM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=WGFOnyq6C5yot59iSB4LHVDt7gZJgKYZY5SmATpRiPqNyfLM401fNJMzm1cTGgbvNUnYh76u8iWKokYdeOlzESdwdS+qR5ab06IkkGJUd1R152g4hmPfam6DtJVKZeLA/e6Yen2xi4tqan2Ww4lSUE8q0IwMaWqBNY8lH2dZJl0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=FnG45bUlLihMBFOflWaC3C9BDNE+UzLG94GC+UI4CBCKz2OZqay4kVGBLI33fnrzyVFUv5FkgS8l4yOBdxfKDtaFdtjZrZF+8DFLwhdRJydVmuOvkb5aYkjxv2BNkTYnvrbgLl07AFV020wXttpzPhYf7uf9fm+WQPrxaMb6gz8=; X-YMail-OSG: N2H5J0gVM1nr6vKncrBKCZm5o1YGet3oRnMSzVddYkO8Tez EoeOSTX4v.DjsERm2menC1Cu4Z5TGECEfUMNKdO49FlVh6GPU4xQ.75MRvqq Y3CeftCgWKurfB0p28W3cl2MsqDqNXGkPxQfEJjNIGR7_mkOz3YG7xjyi9dy PdXHn0m7.o9B5IhXjGf.5lXU7qTuOO1wHNqoMnaf7sqjAKS_AlLITYtd0cp1 uQyuOgZ.OaDQOPgZBdG4Z9oM0Trx7obRU5x8IVRQdLI8_WsLYoVZEpLW.Apf zYjxplbkGUuFsMOemy2vIxPkiHXqVSc6QmDYdFGC4YVSVesqM9vErdXxOvgM CQflH63n6LojVhsO58l0mEmXlg5lGsm1VxDo1cYppQMLDs3mdpUohBxVzUgi piu2MTGRFWhSPLlIsWGV2Wx8NewPm1_UhpcsqJRaE15t11ezNH.lipFKmHxV L87tmLEhZcEBHwRPHAyXSnJrtSuYCvPOi8VP0N7lKKBEJAWFynF7nBfS6Qhu 7AWF.72GQJYikV8j82XMsJDjf4xkWkg-- Received: from [98.203.118.124] by web121606.mail.ne1.yahoo.com via HTTP; Thu, 04 Apr 2013 06:39:10 PDT X-Rocket-MIMEInfo: 002.001, CgotLS0gT24gVHVlLCA0LzIvMTMsIEFkcmlhbiBDaGFkZCA8YWRyaWFuQGZyZWVic2Qub3JnPiB3cm90ZToKCj4gRnJvbTogQWRyaWFuIENoYWRkIDxhZHJpYW5AZnJlZWJzZC5vcmc.Cj4gU3ViamVjdDogUmU6IGlnYiBhbmQgQUxUUSBpbiA5LjEtcmMzCj4gVG86ICJOaWNrIFJvZ2VycyIgPG5jcm9nZXJzQGdtYWlsLmNvbT4KPiBDYzogIkthcmltIEZvZGlsLUxlbWVsaW4iIDxmb2RpbGxlbWxpbmthcmltQGdtYWlsLmNvbT4sICJmcmVlYnNkLW5ldEBmcmVlYnNkLm9yZyIgPGZyZWVic2QtbmV0QGZyZWVic2QBMAEBAQE- X-Mailer: YahooMailClassic/15.1.7 YahooMailWebService/0.8.140.532 Message-ID: <1365082750.44226.YahooMailClassic@web121606.mail.ne1.yahoo.com> Date: Thu, 4 Apr 2013 06:39:10 -0700 (PDT) From: Barney Cordoba Subject: Re: igb and ALTQ in 9.1-rc3 To: Nick Rogers , Adrian Chadd In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Karim Fodil-Lemelin , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 13:41:37 -0000 --- On Tue, 4/2/13, Adrian Chadd wrote: > From: Adrian Chadd > Subject: Re: igb and ALTQ in 9.1-rc3 > To: "Nick Rogers" > Cc: "Karim Fodil-Lemelin" , "freebsd-net@freebsd.org" > Date: Tuesday, April 2, 2013, 6:39 PM > Yes: > > * you need to add it to conf/options - see if there's an > opt_igb.h to > add it to, otherwise you'll need to add one; > * Make sure the driver code includes opt_igb.h; > * Then make sure you make kernel modules using either make > buildkernel > KERNCONF=X, or you set the environment appropriately so the > build > scripts can find your kernel build directory (where it > populates all > the opt_xxx.h includes) and it'll have this module set. > > Hopefully Jack will do this. > > Yes, we need a better queue management discipline API in the > kernel. > Jacks' just falling afoul of the fact we don't have one. > It's not his > fault. That's not true at all. For a bridged system running a firewall or doing filtering, virtually all of the proper design can be done in the ethernet driver. Or course if you have 2 different drivers then you need a different scheme, but if the input and the output is the same driver you can manage virtually all of the contention. You can't just randomly do things; you have to design to minimize lock contention. Drivers that seem to work fine at low volume blow up quickly as contention increases. BC From owner-freebsd-net@FreeBSD.ORG Thu Apr 4 15:20:05 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6D049C8F; Thu, 4 Apr 2013 15:20:05 +0000 (UTC) (envelope-from sbruno@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 496899A8; Thu, 4 Apr 2013 15:20:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r34FK5vJ006176; Thu, 4 Apr 2013 15:20:05 GMT (envelope-from sbruno@freefall.freebsd.org) Received: (from sbruno@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r34FK4ak006174; Thu, 4 Apr 2013 15:20:04 GMT (envelope-from sbruno) Date: Thu, 4 Apr 2013 15:20:04 GMT Message-Id: <201304041520.r34FK4ak006174@freefall.freebsd.org> To: hiren.panchasara@gmail.com, sbruno@FreeBSD.org, freebsd-net@FreeBSD.org, sbruno@FreeBSD.org From: sbruno@FreeBSD.org Subject: Re: kern/177384: [igb] [patch] Updating igb manpage/code with info about num_queues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 15:20:05 -0000 Synopsis: [igb] [patch] Updating igb manpage/code with info about num_queues State-Changed-From-To: open->closed State-Changed-By: sbruno State-Changed-When: Thu Apr 4 15:17:58 UTC 2013 State-Changed-Why: This has been resolved on current and will be sent to stable/8 and stable/9 via MFC Responsible-Changed-From-To: freebsd-net->sbruno Responsible-Changed-By: sbruno Responsible-Changed-When: Thu Apr 4 15:17:58 UTC 2013 Responsible-Changed-Why: This has been resolved on current and will be sent to stable/8 and stable/9 via MFC http://www.freebsd.org/cgi/query-pr.cgi?pr=177384 From owner-freebsd-net@FreeBSD.ORG Thu Apr 4 17:06:16 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 53E1D1A6; Thu, 4 Apr 2013 17:06:16 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6B353175; Thu, 4 Apr 2013 17:06:14 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA11401; Thu, 04 Apr 2013 20:06:13 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <515DB305.70908@FreeBSD.org> Date: Thu, 04 Apr 2013 20:06:13 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130313 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-net@FreeBSD.org, FreeBSD Hackers Subject: Re: close(2) while accept(2) is blocked References: <515475C7.6010404@FreeBSD.org> <20130329235431.32D7FB82A@mail.bitblocks.com> <20130330161434.GG76354@funkthat.com> In-Reply-To: <20130330161434.GG76354@funkthat.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 17:06:16 -0000 on 30/03/2013 18:14 John-Mark Gurney said the following: > As someone else pointed out in this thread, if a userland program > depends upon this behavior, it has a race condition in it... > > Thread 1 Thread 2 Thread 3 > enters routine to read > enters routine to close > calls close(3) > open() returns 3 > does read(3) for orignal fd > > How can the original threaded program ensure that thread 2 doesn't > create a new fd in between? So even if you use a lock, this won't > help, because as far as I know, there is no enter read and unlock > mutex call yet... > > I decided long ago that this is only solvable by proper use of locking > and ensuring that if you call close (the syscall), that you do not have > any other thread that may use the fd. It's the close routine's (not > syscall) function to make sure it locks out other threads and all other > are out of the code path that will use the fd before it calls close.. > > If someone could describe how this new eject a person from read could > be done in a race safe way, then I'd say go ahead w/ it... Otherwise > we're just moving the race around, and letting people think that they > have solved the problem when they haven't... > > I think I remeber another thread about this from a year or two ago, > but I couldn't find it... If someone finds it, posting a link would > be nice.. > I wish to abstract as much as possible from how an application may use, misuse or even abuse the close+xxxx interaction. But I think that the behavior that provides more information / capabilities is preferable over the behavior that does not. E.g. your example above does not apply to a utility that has only two threads. The "three threads" problem can also be solved if all the threads cooperate. But as I've said. -- Andriy Gapon From owner-freebsd-net@FreeBSD.ORG Thu Apr 4 17:43:21 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F2387D5F; Thu, 4 Apr 2013 17:43:20 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A4B85331; Thu, 4 Apr 2013 17:43:19 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA11825; Thu, 04 Apr 2013 20:43:18 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <515DBBB5.70505@FreeBSD.org> Date: Thu, 04 Apr 2013 20:43:17 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130313 Thunderbird/17.0.4 MIME-Version: 1.0 To: John Baldwin Subject: Re: close(2) while accept(2) is blocked References: <515475C7.6010404@FreeBSD.org> <201304011122.13101.jhb@freebsd.org> In-Reply-To: <201304011122.13101.jhb@freebsd.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, office@FreeBSD.org, FreeBSD Hackers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 17:43:21 -0000 on 01/04/2013 18:22 John Baldwin said the following: > I think you need to split the 'struct file' reference count into two different > counts similar to the how we have vref/vrele vs vhold/vdrop for vnodes. The > fget for accept and probably most other system calls should probably be equivalent > to vhold, whereas things like open/dup (and storing an fd in a cmsg) should be > more like vref. close() should then be a vrele(). This model makes perfect sense. Unfortunately, ENOTIME to work on this. Meanwhile I am using the following patch specific to local domain sockets, accept(2) and shutdown(2). Turns out that the problematic application does both shutdown(RDWR) and close(2), but that doesn't help on FreeBSD. BTW, this is the application: http://thread.gmane.org/gmane.os.freebsd.devel.office/1754 The patch does help. Author: Andriy Gapon Date: Thu Mar 28 20:08:13 2013 +0200 [test!] uipc_shutdown: use soisdisconnected instead of socantsendmore So that in addition to disabling sends we also wake up threads blocked in accept (on so_timeo in general). diff --git a/sys/kern/uipc_usrreq.c b/sys/kern/uipc_usrreq.c index 9b60eab..e93d46c 100644 --- a/sys/kern/uipc_usrreq.c +++ b/sys/kern/uipc_usrreq.c @@ -1074,7 +1074,7 @@ uipc_shutdown(struct socket *so) UNP_LINK_WLOCK(); UNP_PCB_LOCK(unp); - socantsendmore(so); + soisdisconnected(so); unp_shutdown(unp); UNP_PCB_UNLOCK(unp); UNP_LINK_WUNLOCK(); -- Andriy Gapon From owner-freebsd-net@FreeBSD.ORG Thu Apr 4 21:52:33 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0D1B0744; Thu, 4 Apr 2013 21:52:33 +0000 (UTC) (envelope-from kevin@your.org) Received: from mail.your.org (mail.your.org [IPv6:2001:4978:1:2::cc09:3717]) by mx1.freebsd.org (Postfix) with ESMTP id DBD44F48; Thu, 4 Apr 2013 21:52:32 +0000 (UTC) Received: from mail.your.org (chi02.mail.your.org [204.9.55.23]) by mail.your.org (Postfix) with ESMTP id 61E4BF06C69; Thu, 4 Apr 2013 21:52:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=your.org; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=A8dajdB6OHx+NmbD+UhNhP4TyC8=; b=jPI0RBNXXjNjc2ZBIa 8zYxIXVVgNAqCyJ4kORqRu05C3a61YgAv9ZoRkN8s4aUbGPM2l03iTjU8QZlVyXK H9gYXJrvLXBch3pIjwZErV0QQ0N9VR45SqFZ7SahY7uU7BS1JFWrhZ2YSx6r9jwL nCUzrR+ym5nBVEWcBlSMEnJsM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=your.org; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=MHv/eqGENWOIudaV2OBJ+ry/5TOmG0FlrLw7uinpxQhugtM63QO hq7tIhTy5ToUmIiJ7GwSv+b1e2e5A4fYW5QmbeEaLB3m1AxTfQ6OhwGpf6GrBy5O DpThSnEKPK5hJt72AsbZnN7CEQPIxCXUBBoC+Uk/tkfI5YBldeGtA2eU= Received: from vpn132.rw1.your.org (vpn132.rw1.your.org [204.9.51.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.your.org (Postfix) with ESMTPSA id 2CEFCF06C5D; Thu, 4 Apr 2013 21:52:31 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Syncookies break with Windows 8 From: Kevin Day In-Reply-To: <510C4B17.4040509@freebsd.org> Date: Thu, 4 Apr 2013 16:52:31 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3DABEC7E-78B8-49DE-9F76-0B96019E8424@your.org> References: <510C4424.4030701@networx.ch> <510C4B17.4040509@freebsd.org> To: Andre Oppermann X-Mailer: Apple Mail (2.1503) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 21:52:33 -0000 On Feb 1, 2013, at 5:09 PM, Andre Oppermann wrote: >=20 > I'm working on a solution. Have to make sure that the chance to > crack a reduced cookie during its 30 seconds lifetime isn't too > high. That means involving our resident crypto experts for > verification. Hey, Andre! I know the security people have been pretty busy, but has there been any = progress on this? We're still running into the occasional complaint with = this issue. -- Kevin From owner-freebsd-net@FreeBSD.ORG Thu Apr 4 22:33:11 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BDD213A5 for ; Thu, 4 Apr 2013 22:33:11 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 8928F153 for ; Thu, 4 Apr 2013 22:33:11 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEAIf+XVGDaFvO/2dsb2JhbABDFoMmgyi9YYEbdIIfAQEoBIEFAgINGQJfiCcMoEeOUpJEgSONRIJogRMDlm6BIIhVhxiDJyCBbA X-IronPort-AV: E=Sophos;i="4.87,411,1363147200"; d="scan'208";a="22510910" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 04 Apr 2013 18:33:10 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id BF39EB402B for ; Thu, 4 Apr 2013 18:33:10 -0400 (EDT) Date: Thu, 4 Apr 2013 18:33:10 -0400 (EDT) From: Rick Macklem To: FreeBSD Net Message-ID: <1043692819.529554.1365114790772.JavaMail.root@erie.cs.uoguelph.ca> Subject: panic in tcp_do_segment() MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2692) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 22:33:11 -0000 Hi, When pho@ was doing some NFS testing, he got the following crash, which I can't figure out. (As far as I can see, INP_WLOCK() is always held when tp->t_state = TCPS_CLOSED and it is held from before the test for TCPS_CLOSED in tcp_input() up until the tcp_do_segment() call. As such, I don't see how tp->t_state can be TCPS_CLOSED, but that seems to be what causes the panic?) The "umount -f" will result in: soshutdown(so, SHUT_WR); soclose(so); being done by the krpc on the socket. Anyone have any ideas on this? pho@ wrote: > I continued running the NFS tests and got this "panic: tcp_do_segment: > TCPS_LISTEN". It's the second time I get this panic with the same test > scenario, so it seems to be reproducible. The scenario is "umount -f" > of a mount point that is very active. > > http://people.freebsd.org/~pho/stress/log/kostik555.txt Thanks in advance for any help, rick From owner-freebsd-net@FreeBSD.ORG Fri Apr 5 08:49:38 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 241EB706 for ; Fri, 5 Apr 2013 08:49:38 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8F73B911 for ; Fri, 5 Apr 2013 08:49:37 +0000 (UTC) Received: (qmail 14186 invoked from network); 5 Apr 2013 09:57:49 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 5 Apr 2013 09:57:49 -0000 Message-ID: <515E901A.9010304@freebsd.org> Date: Fri, 05 Apr 2013 10:49:30 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Kevin Day Subject: Re: Syncookies break with Windows 8 References: <510C4424.4030701@networx.ch> <510C4B17.4040509@freebsd.org> <3DABEC7E-78B8-49DE-9F76-0B96019E8424@your.org> In-Reply-To: <3DABEC7E-78B8-49DE-9F76-0B96019E8424@your.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 08:49:38 -0000 On 04.04.2013 23:52, Kevin Day wrote: > > On Feb 1, 2013, at 5:09 PM, Andre Oppermann wrote: >> >> I'm working on a solution. Have to make sure that the chance to >> crack a reduced cookie during its 30 seconds lifetime isn't too >> high. That means involving our resident crypto experts for >> verification. > > > Hey, Andre! > > I know the security people have been pretty busy, but has there been > any progress on this? We're still running into the occasional complaint > with this issue. Yes, there has been progress on a good fix for the issue. I've also got excellent feedback from a couple of people on the cryptographic properties of the new cookie approach. I shall be able to post a patch for testing in the next days. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Apr 5 08:52:08 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0C1B994F for ; Fri, 5 Apr 2013 08:52:08 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 77E93933 for ; Fri, 5 Apr 2013 08:52:06 +0000 (UTC) Received: (qmail 14215 invoked from network); 5 Apr 2013 10:00:20 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 5 Apr 2013 10:00:20 -0000 Message-ID: <515E90B1.2070205@freebsd.org> Date: Fri, 05 Apr 2013 10:52:01 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Rick Macklem Subject: Re: panic in tcp_do_segment() References: <1043692819.529554.1365114790772.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1043692819.529554.1365114790772.JavaMail.root@erie.cs.uoguelph.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 08:52:08 -0000 On 05.04.2013 00:33, Rick Macklem wrote: > Hi, > > When pho@ was doing some NFS testing, he got the > following crash, which I can't figure out. (As far > as I can see, INP_WLOCK() is always held when > tp->t_state = TCPS_CLOSED and it is held from before > the test for TCPS_CLOSED in tcp_input() up until > the tcp_do_segment() call. As such, I don't see how > tp->t_state can be TCPS_CLOSED, but that seems to > be what causes the panic?) > > The "umount -f" will result in: > soshutdown(so, SHUT_WR); > soclose(so); > being done by the krpc on the socket. > > Anyone have any ideas on this? Interesting triggering of the assertion... I can have a look in the afternoon. -- Andre > pho@ wrote: >> I continued running the NFS tests and got this "panic: tcp_do_segment: >> TCPS_LISTEN". It's the second time I get this panic with the same test >> scenario, so it seems to be reproducible. The scenario is "umount -f" >> of a mount point that is very active. >> >> http://people.freebsd.org/~pho/stress/log/kostik555.txt > > Thanks in advance for any help, rick > _______________________________________________ > 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" > > From owner-freebsd-net@FreeBSD.ORG Fri Apr 5 11:10:11 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D969A704 for ; Fri, 5 Apr 2013 11:10:11 +0000 (UTC) (envelope-from mattmiller1@gmail.com) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) by mx1.freebsd.org (Postfix) with ESMTP id 945D4F41 for ; Fri, 5 Apr 2013 11:10:11 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id bs12so225749qab.7 for ; Fri, 05 Apr 2013 04:10:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=P0XF3gA8p2gUDjQiUF8a6w2xZBAwrZB68fA8QedzUxc=; b=nwxPycMw+fgvH9MPK5SB6/KtuhgwdMQC0jTyT3FxEp1IKNXn9MrS72diEWg0iPIKfi gqKoFtZUnco9tRQM/6v7R9t9o9xeqHax0ARr+p2QTCSruS0nKT5CPgirypTqmOa+2NwV 01vnKMajizCJpqDQEaZF2ty5Lunki6g25lGvNsK6BMtGsXjV1z9TcBli6cvlCwAY3Obd KoEiJfrtyPh6PFN5krWK0uRFIVWSUCPj+mrE3ugoDeL8ckXy2Y9bw5pGPVAsYtfErWGe J3PZZLEPDnMDUS+hzfkHf71/mp/qvNZ7hcg25smx+3qHJsPXspRCIJIZy9gcvMehWzAA x8cQ== X-Received: by 10.224.39.80 with SMTP id f16mr7822613qae.11.1365160205660; Fri, 05 Apr 2013 04:10:05 -0700 (PDT) MIME-Version: 1.0 Sender: mattmiller1@gmail.com Received: by 10.49.116.196 with HTTP; Fri, 5 Apr 2013 04:09:24 -0700 (PDT) In-Reply-To: <1043692819.529554.1365114790772.JavaMail.root@erie.cs.uoguelph.ca> References: <1043692819.529554.1365114790772.JavaMail.root@erie.cs.uoguelph.ca> From: Matt Miller Date: Fri, 5 Apr 2013 07:09:24 -0400 X-Google-Sender-Auth: 2IfXUrI5gKRzgSWRYq6T8396-Gg Message-ID: Subject: Re: panic in tcp_do_segment() To: Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Net , Juan Mojica X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 11:10:11 -0000 Hey Rick, I believe Juan and I have root caused this crash recently. The t_state = 0x1, TCPS_LISTEN, in the link provided at the time of the assertion. In tcp_input(), if we're in TCPS_LISTEN, SO_ACCEPTCONN should be set on the socket and we should never enter tcp_do_segment() for this state. I think if you look in your corefile, you'll see the socket *doesn't* have this flag set in your case. 1043 /* 1044 * When the socket is accepting connections (the INPCB is in LISTEN 1045 * state) we look into the SYN cache if this is a new connection 1046 * attempt or the completion of a previous one. Because listen 1047 * sockets are never in TCPS_ESTABLISHED, the V_tcbinfo lock will be 1048 * held in this case. 1049 */ 1050 if (so->so_options & SO_ACCEPTCONN) { 1051 struct in_conninfo inc; 1052 1053 KASSERT(tp->t_state == TCPS_LISTEN, ("%s: so accepting but " 1054 "tp not listening", __func__)); ... 1356 syncache_add(&inc, &to, th, inp, &so, m, NULL, NULL); 1357 /* 1358 * Entry added to syncache and mbuf consumed. 1359 * Everything already unlocked by syncache_add(). 1360 */ 1361 INP_INFO_UNLOCK_ASSERT(&V_tcbinfo); 1362 return; 1363 } ... 1384 /* 1385 * Segment belongs to a connection in SYN_SENT, ESTABLISHED or later 1386 * state. tcp_do_segment() always consumes the mbuf chain, unlocks 1387 * the inpcb, and unlocks pcbinfo. 1388 */ 1389 tcp_do_segment(m, th, so, tp, drop_hdrlen, tlen, iptos, ti_locked); I think this has to do with this patch in soclose() where SO_ACCEPTCONN is being turned off in soclose(). I suspect if you look at the other threads in your corefile, you'll see one at this point in soclose() operating on the same socket as the one in the tcp_do_segment() thread. http://svnweb.freebsd.org/base?view=revision&revision=243627 817 /* 818 * Prevent new additions to the accept queues due 819 * to ACCEPT_LOCK races while we are draining them. 820 */ 821 so->so_options &= ~SO_ACCEPTCONN; 822 while ((sp = TAILQ_FIRST(&so->so_incomp)) != NULL) { 823 TAILQ_REMOVE(&so->so_incomp, sp, so_list); 824 so->so_incqlen--; 825 sp->so_qstate &= ~SQ_INCOMP; 826 sp->so_head = NULL; 827 ACCEPT_UNLOCK(); 828 soabort(sp); 829 ACCEPT_LOCK(); 830 } Juan had evaluated this code path and it seemed safe to just drop the packet in this case: + /* + * In closing down the socket, the SO_ACCEPTCONN flag is removed to + * prevent new connections from being established. This means that + * any frames in that were in the midst of being processed could + * make it here. Need to just drop the frame. + */ + if (TCPS_LISTEN == tp->t_state) { + TCPSTAT_INC(tcps_rcvwhileclosing); + goto drop; + } KASSERT(tp->t_state > TCPS_LISTEN, ("%s: TCPS_LISTEN", __func__)); Or, if there's someone more familiar with the locking in these paths, they may be able to come up with a way to restructure the locks and logic to close this window. -Matt On Thu, Apr 4, 2013 at 6:33 PM, Rick Macklem wrote: > Hi, > > When pho@ was doing some NFS testing, he got the > following crash, which I can't figure out. (As far > as I can see, INP_WLOCK() is always held when > tp->t_state = TCPS_CLOSED and it is held from before > the test for TCPS_CLOSED in tcp_input() up until > the tcp_do_segment() call. As such, I don't see how > tp->t_state can be TCPS_CLOSED, but that seems to > be what causes the panic?) > > The "umount -f" will result in: > soshutdown(so, SHUT_WR); > soclose(so); > being done by the krpc on the socket. > > Anyone have any ideas on this? > pho@ wrote: > > I continued running the NFS tests and got this "panic: tcp_do_segment: > > TCPS_LISTEN". It's the second time I get this panic with the same test > > scenario, so it seems to be reproducible. The scenario is "umount -f" > > of a mount point that is very active. > > > > http://people.freebsd.org/~pho/stress/log/kostik555.txt > > Thanks in advance for any help, rick > _______________________________________________ > 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" > From owner-freebsd-net@FreeBSD.ORG Fri Apr 5 15:20:11 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1C3A94A1 for ; Fri, 5 Apr 2013 15:20:11 +0000 (UTC) (envelope-from jmojica@gmail.com) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by mx1.freebsd.org (Postfix) with ESMTP id 97B9CE11 for ; Fri, 5 Apr 2013 15:20:10 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id c10so705790wiw.7 for ; Fri, 05 Apr 2013 08:20:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=l5QEFPzyqPb89nGjcBf9XN4gOs06HeZMgTKb6LVYCw8=; b=cn0gUtoLjvsXfgZjYBIaWANS1crn/ylQhElt1AI8xNbY+Ldbgrq8U+Ix+zH1L07ZhD /dj4t12qgnb9O66Wko8vSeY3l/h2NYtM1JXeOZb1xiACjFgAMQ1o/BwmCJJW8TVOAyh+ SA6Ftv4LRlVe2wZIRiZIMHmoP6tPfggXW3RxJQ0DVHYl46m1x7YdG5AFQcSU48asmjoA GtUCzyG8TYnwgTS0UPaT0npfJZTncqY2cGVVXdybcX491iF3uTiwm4L8kpyfqotcj2/f eoje34WBbiTcD3XG29QN4XzRoAlQJsJ5VIsA0AVsCUp3nZp9nMKvZ8Or2VJBbOfS3nFH Yoxw== MIME-Version: 1.0 X-Received: by 10.180.97.132 with SMTP id ea4mr5077346wib.23.1365175209156; Fri, 05 Apr 2013 08:20:09 -0700 (PDT) Received: by 10.194.122.73 with HTTP; Fri, 5 Apr 2013 08:20:09 -0700 (PDT) In-Reply-To: References: <1043692819.529554.1365114790772.JavaMail.root@erie.cs.uoguelph.ca> Date: Fri, 5 Apr 2013 11:20:09 -0400 Message-ID: Subject: Re: panic in tcp_do_segment() From: Juan Mojica To: Matt Miller Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Net , Rick Macklem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 15:20:11 -0000 Agree with Matt. Whenever there is an UNLOCK/LOCK like is present in soclose(), there is a window to allow something through. Unsetting SO_ACCEPTCONN was put in place because the LOCK/UNLOCK in soclose let a new socket to be added to the so_incomp list causing a different ASSERT to be hit - and memory to be leaked. As far as I can tell, because of the upcall performed in soabort(), we can't just hold the ACCEPT lock all the way through the close. The simplest thing to do in this case seemed to be to just drop the TCP segment - the connection is being closed anyway. Or like Matt said, having someone look at the lock logic and see if there is something there that can be exploited to prevent this would also help. -Juan On Fri, Apr 5, 2013 at 7:09 AM, Matt Miller wrote: > Hey Rick, > > I believe Juan and I have root caused this crash recently. The t_state = > 0x1, TCPS_LISTEN, in the link provided at the time of the assertion. > > In tcp_input(), if we're in TCPS_LISTEN, SO_ACCEPTCONN should be set on > the socket and we should never enter tcp_do_segment() for this state. I > think if you look in your corefile, you'll see the socket *doesn't* have > this flag set in your case. > > 1043 /* > 1044 * When the socket is accepting connections (the INPCB is in > LISTEN > 1045 * state) we look into the SYN cache if this is a new > connection > 1046 * attempt or the completion of a previous one. Because > listen > 1047 * sockets are never in TCPS_ESTABLISHED, the V_tcbinfo lock > will be > 1048 * held in this case. > 1049 */ > 1050 if (so->so_options & SO_ACCEPTCONN) { > 1051 struct in_conninfo inc; > 1052 > 1053 KASSERT(tp->t_state == TCPS_LISTEN, ("%s: so > accepting but " > 1054 "tp not listening", __func__)); > ... > 1356 syncache_add(&inc, &to, th, inp, &so, m, NULL, NULL); > 1357 /* > 1358 * Entry added to syncache and mbuf consumed. > 1359 * Everything already unlocked by syncache_add(). > 1360 */ > 1361 INP_INFO_UNLOCK_ASSERT(&V_tcbinfo); > 1362 return; > 1363 } > ... > 1384 /* > 1385 * Segment belongs to a connection in SYN_SENT, ESTABLISHED > or later > 1386 * state. tcp_do_segment() always consumes the mbuf chain, > unlocks > 1387 * the inpcb, and unlocks pcbinfo. > 1388 */ > 1389 tcp_do_segment(m, th, so, tp, drop_hdrlen, tlen, iptos, > ti_locked); > > I think this has to do with this patch in soclose() where SO_ACCEPTCONN is > being turned off in soclose(). I suspect if you look at the other threads > in your corefile, you'll see one at this point in soclose() operating on > the same socket as the one in the tcp_do_segment() thread. > > http://svnweb.freebsd.org/base?view=revision&revision=243627 > > 817 /* > 818 * Prevent new additions to the accept queues due > 819 * to ACCEPT_LOCK races while we are draining them. > 820 */ > 821 so->so_options &= ~SO_ACCEPTCONN; > 822 while ((sp = TAILQ_FIRST(&so->so_incomp)) != NULL) { > 823 TAILQ_REMOVE(&so->so_incomp, sp, so_list); > 824 so->so_incqlen--; > 825 sp->so_qstate &= ~SQ_INCOMP; > 826 sp->so_head = NULL; > 827 ACCEPT_UNLOCK(); > 828 soabort(sp); > 829 ACCEPT_LOCK(); > 830 } > > Juan had evaluated this code path and it seemed safe to just drop the > packet in this case: > > + /* > + * In closing down the socket, the SO_ACCEPTCONN flag is removed to > + * prevent new connections from being established. This means that > + * any frames in that were in the midst of being processed could > + * make it here. Need to just drop the frame. > + */ > + if (TCPS_LISTEN == tp->t_state) { > + TCPSTAT_INC(tcps_rcvwhileclosing); > + goto drop; > + } > KASSERT(tp->t_state > TCPS_LISTEN, ("%s: TCPS_LISTEN", > __func__)); > > Or, if there's someone more familiar with the locking in these paths, they > may be able to come up with a way to restructure the locks and logic to > close this window. > > -Matt > > > > > On Thu, Apr 4, 2013 at 6:33 PM, Rick Macklem wrote: > >> Hi, >> >> When pho@ was doing some NFS testing, he got the >> following crash, which I can't figure out. (As far >> as I can see, INP_WLOCK() is always held when >> tp->t_state = TCPS_CLOSED and it is held from before >> the test for TCPS_CLOSED in tcp_input() up until >> the tcp_do_segment() call. As such, I don't see how >> tp->t_state can be TCPS_CLOSED, but that seems to >> be what causes the panic?) >> >> The "umount -f" will result in: >> soshutdown(so, SHUT_WR); >> soclose(so); >> being done by the krpc on the socket. >> >> Anyone have any ideas on this? >> pho@ wrote: >> > I continued running the NFS tests and got this "panic: tcp_do_segment: >> > TCPS_LISTEN". It's the second time I get this panic with the same test >> > scenario, so it seems to be reproducible. The scenario is "umount -f" >> > of a mount point that is very active. >> > >> > http://people.freebsd.org/~pho/stress/log/kostik555.txt >> >> Thanks in advance for any help, rick >> _______________________________________________ >> 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" >> > > -- Juan Mojica Email: jmojica@gmail.com From owner-freebsd-net@FreeBSD.ORG Fri Apr 5 20:32:25 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4A8399FC; Fri, 5 Apr 2013 20:32:25 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 12FD8C14; Fri, 5 Apr 2013 20:32:25 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 0D1703592EE; Fri, 5 Apr 2013 22:32:23 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id DF9DE2848C; Fri, 5 Apr 2013 22:32:22 +0200 (CEST) Date: Fri, 5 Apr 2013 22:32:22 +0200 From: Jilles Tjoelker To: Andriy Gapon Subject: Re: close(2) while accept(2) is blocked Message-ID: <20130405203222.GB10840@stack.nl> References: <515475C7.6010404@FreeBSD.org> <201304011122.13101.jhb@freebsd.org> <515DBBB5.70505@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <515DBBB5.70505@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org, office@FreeBSD.org, John Baldwin , FreeBSD Hackers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 20:32:25 -0000 On Thu, Apr 04, 2013 at 08:43:17PM +0300, Andriy Gapon wrote: > on 01/04/2013 18:22 John Baldwin said the following: > > I think you need to split the 'struct file' reference count into two > > different counts similar to the how we have vref/vrele vs > > vhold/vdrop for vnodes. The fget for accept and probably most other > > system calls should probably be equivalent to vhold, whereas things > > like open/dup (and storing an fd in a cmsg) should be more like > > vref. close() should then be a vrele(). > This model makes perfect sense. > Unfortunately, ENOTIME to work on this. This looks like it can work but I don't know whether it's worth the trouble. > Meanwhile I am using the following patch specific to local domain > sockets, accept(2) and shutdown(2). Turns out that the problematic > application does both shutdown(RDWR) and close(2), but that doesn't > help on FreeBSD. > BTW, this is the application: > http://thread.gmane.org/gmane.os.freebsd.devel.office/1754 > The patch does help. > Author: Andriy Gapon > Date: Thu Mar 28 20:08:13 2013 +0200 > > [test!] uipc_shutdown: use soisdisconnected instead of socantsendmore > > So that in addition to disabling sends we also wake up threads blocked > in accept (on so_timeo in general). > > diff --git a/sys/kern/uipc_usrreq.c b/sys/kern/uipc_usrreq.c > index 9b60eab..e93d46c 100644 > --- a/sys/kern/uipc_usrreq.c > +++ b/sys/kern/uipc_usrreq.c > @@ -1074,7 +1074,7 @@ uipc_shutdown(struct socket *so) > > UNP_LINK_WLOCK(); > UNP_PCB_LOCK(unp); > - socantsendmore(so); > + soisdisconnected(so); > unp_shutdown(unp); > UNP_PCB_UNLOCK(unp); > UNP_LINK_WUNLOCK(); I think this patch makes shutdown(SHUT_WR) on unix domain sockets act like shutdown(SHUT_RDWR), i.e. receives are incorrectly denied. The below patch also makes shutdown(SHUT_RDWR) abort a blocking accept on a unix domain socket, but it should work for all domains: Index: sys/kern/uipc_socket.c =================================================================== --- sys/kern/uipc_socket.c (revision 248873) +++ sys/kern/uipc_socket.c (working copy) @@ -2428,9 +2428,11 @@ soshutdown(struct socket *so, int how) sorflush(so); if (how != SHUT_RD) { error = (*pr->pr_usrreqs->pru_shutdown)(so); + wakeup(&so->so_timeo); CURVNET_RESTORE(); return (error); } + wakeup(&so->so_timeo); CURVNET_RESTORE(); return (0); } A blocking accept (and some other operations) is waiting on &so->so_timeo. Once it wakes up, it will detect the SBS_CANTRCVMORE bit. A spurious wakeup on so->so_timeo appears harmless (sleep retried) except when lingering on close (SO_LINGER) so this should be fairly safe. -- Jilles Tjoelker From owner-freebsd-net@FreeBSD.ORG Sat Apr 6 00:07:38 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4520F6B2 for ; Sat, 6 Apr 2013 00:07:38 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from abby.lhr1.as41113.net (hosted.mx.as41113.net [91.208.177.22]) by mx1.freebsd.org (Postfix) with ESMTP id 14605338 for ; Sat, 6 Apr 2013 00:07:36 +0000 (UTC) Received: from [172.16.9.23] (bella.stf.rewt.org.uk [91.208.177.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by abby.lhr1.as41113.net (Postfix) with ESMTPSA id 3ZjJ9r2Tgvz3X for ; Sat, 6 Apr 2013 01:07:28 +0100 (BST) Message-ID: <515F6734.2040302@rewt.org.uk> Date: Sat, 06 Apr 2013 01:07:16 +0100 From: Joe Holden User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: rarpd Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 00:07:38 -0000 Hi guys, I'm trying to make rarpd behave, but it doesn't seem to want to listen on vlan interfaces, or at least not mine: The machine is a router with two interaces: vr0 - routable ip address that pf performs nat on vr1 - several vlan interfaces of which I want rarpd to listen on one, vr1.9 (I've tried renaming it to no avail) If I use rarpd vr1.9 (or vr1, or anything other than vr0) it exits, output from truss: connect(3,{ AF_UNIX "/var/run/logpriv" },106) = 0 (0x0) sendto(3,"<27>Apr 6 01:05:13 rarpd[40520]"...,47,0x0,NULL,0x0) = 47 (0x2f) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) process exit, rval = 1 Whereas specifying vr0 outputs: connect(4,{ AF_UNIX "/var/run/logpriv" },106) = 0 (0x0) sendto(4,"<31>Apr 6 01:05:41 rarpd[40522]"...,77,0x0,NULL,0x0) = 77 (0x4d) ioctl(3,BIOCGBLEN,0xbfbfe6c0) = 0 (0x0) I can't see any mention of this in the manpage, is this a known issue because well, reverse arp is entirely irrelevant in 2013 or something I can easily fix (nfs booting an OpenBSD machine, why they can't use dhcp/bootp like everyone else I don't know) Cheers, Joe From owner-freebsd-net@FreeBSD.ORG Sat Apr 6 10:04:27 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4F157BF0; Sat, 6 Apr 2013 10:04:27 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 9FE77819; Sat, 6 Apr 2013 10:04:26 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id fn20so680195lab.32 for ; Sat, 06 Apr 2013 03:04:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=F5ED1KxTfDI1gtBVP7cfi16YA8oPNV5wcJzjOrw34Zk=; b=TvSo5mUqR2BuwO903X9RvIxFF0sS+Vekh69hGGEeGh4IiBJKjf/6ngvT6eOnl61Ls6 WYV8Lby+a1JRr1iglRe+4IOfvFjdWuatc+35zvOZcvA3Te6p0MVR99fL0U0VXn/o3Rnm cvRzpZpbUFpQOr6lENWGIOA3crQKJbCt7CM5W5Mvq9wTYWGZQgYvbXaNMVIcgZ7XtW4x 0YQMmJZpzlrvEH3YLgx6ngfkBB900MlwSJ3Y0cLYGqd/MvL0esdWgbRxOCRMXt9dEBLg i60DXxAp9tA9d4FRD8NEOhCd7fk8AUs5cfR6y1lmWFcr8UGI1B8JwGUQB7jsPMDJz+ti OKmw== MIME-Version: 1.0 X-Received: by 10.112.76.39 with SMTP id h7mr6600035lbw.118.1365242665503; Sat, 06 Apr 2013 03:04:25 -0700 (PDT) Received: by 10.114.48.102 with HTTP; Sat, 6 Apr 2013 03:04:25 -0700 (PDT) In-Reply-To: <201304031530.r33FU1AY097998@freefall.freebsd.org> References: <201304031530.r33FU1AY097998@freefall.freebsd.org> Date: Sat, 6 Apr 2013 18:04:25 +0800 Message-ID: Subject: Re: misc/177456: An error of calculating TCP sequence number will resault in the machine to restart From: Sepherosa Ziehau To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 10:04:27 -0000 On Wed, Apr 3, 2013 at 11:30 PM, Gleb Smirnoff wrote: > The following reply was made to PR kern/177456; it has been noted by GNATS. > > From: Gleb Smirnoff > To: ?????? > Cc: bug-followup@FreeBSD.org > Subject: Re: misc/177456: An error of calculating TCP sequence number will > resault in the machine to restart > Date: Wed, 3 Apr 2013 19:21:12 +0400 > > Hi! > > On Wed, Apr 03, 2013 at 07:52:42AM +0800, ?????? wrote: > ?> I mean there is a bug in FreeBSD's tcp code. I'm trying to describe it by pictuer. Pelease see the attachments?? > > I am trying to model what you are describing in the picture by > special crafted code. > > I intentionally model memory allocation failure on first two > packets for a connection that has special socket option. > > I'm modelling allocation failure at tcp_output.c near line 900: > > Index: tcp_output.c > =================================================================== > --- tcp_output.c (revision 249051) > +++ tcp_output.c (working copy) > @@ -898,6 +898,13 @@ send: > else > TCPSTAT_INC(tcps_sndwinup); > > + /* Fail allocating first 2 packets. */ > + if (tp->t_flags & TF_ZHOPA && tp->t_zhopa < 2) { > + tp->t_zhopa++; > + m = NULL; > + error = ENOBUFS; > + goto out; > + } else > m = m_gethdr(M_NOWAIT, MT_DATA); > if (m == NULL) { > error = ENOBUFS; > > > I have no success in reproducing your problems. With above code, > first 2 packets are failing to allocate, but third retransmission > succeeds and connection is established with no problems. > > May be I incorrectly understand your description :( Please don't > give up and try to explain again. > > A modelling code that demonstrates problem would be appreciated. Hope the following analysis helps; IMHO, the reporter probably had hit the same bug: http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/1ff9b7d322dc5a26f7173aa8c38ecb79da80e419 Best Regards, sephe -- Tomorrow Will Never Die On Wed, Apr 3, 2013 at 11:30 PM, Gleb Smirnoff wrote: > The following reply was made to PR kern/177456; it has been noted by GNATS. > > From: Gleb Smirnoff > To: ?????? > Cc: bug-followup@FreeBSD.org > Subject: Re: misc/177456: An error of calculating TCP sequence number will > resault in the machine to restart > Date: Wed, 3 Apr 2013 19:21:12 +0400 > > Hi! > > On Wed, Apr 03, 2013 at 07:52:42AM +0800, ?????? wrote: > ?> I mean there is a bug in FreeBSD's tcp code. I'm trying to describe it by pictuer. Pelease see the attachments?? > > I am trying to model what you are describing in the picture by > special crafted code. > > I intentionally model memory allocation failure on first two > packets for a connection that has special socket option. > > I'm modelling allocation failure at tcp_output.c near line 900: > > Index: tcp_output.c > =================================================================== > --- tcp_output.c (revision 249051) > +++ tcp_output.c (working copy) > @@ -898,6 +898,13 @@ send: > else > TCPSTAT_INC(tcps_sndwinup); > > + /* Fail allocating first 2 packets. */ > + if (tp->t_flags & TF_ZHOPA && tp->t_zhopa < 2) { > + tp->t_zhopa++; > + m = NULL; > + error = ENOBUFS; > + goto out; > + } else > m = m_gethdr(M_NOWAIT, MT_DATA); > if (m == NULL) { > error = ENOBUFS; > > > I have no success in reproducing your problems. With above code, > first 2 packets are failing to allocate, but third retransmission > succeeds and connection is established with no problems. > > May be I incorrectly understand your description :( Please don't > give up and try to explain again. > > A modelling code that demonstrates problem would be appreciated. > > -- > Totus tuus, Glebius. > _______________________________________________ > 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" -- Tomorrow Will Never Die From owner-freebsd-net@FreeBSD.ORG Sat Apr 6 18:11:55 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B6A5D523; Sat, 6 Apr 2013 18:11:55 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id 8C3A29BC; Sat, 6 Apr 2013 18:11:55 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r36IBluH064656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Apr 2013 11:11:48 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r36IBlIm064655; Sat, 6 Apr 2013 11:11:47 -0700 (PDT) (envelope-from jmg) Date: Sat, 6 Apr 2013 11:11:47 -0700 From: John-Mark Gurney To: Bakul Shah Subject: Re: close(2) while accept(2) is blocked Message-ID: <20130406181147.GJ76354@funkthat.com> Mail-Followup-To: Bakul Shah , freebsd-net@freebsd.org, Carl Shapiro , Andriy Gapon , FreeBSD Hackers References: <515475C7.6010404@FreeBSD.org> <20130329235431.32D7FB82A@mail.bitblocks.com> <20130330161434.GG76354@funkthat.com> <20130330202249.F218BB82A@mail.bitblocks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130330202249.F218BB82A@mail.bitblocks.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 06 Apr 2013 11:11:48 -0700 (PDT) Cc: freebsd-net@freebsd.org, Carl Shapiro , Andriy Gapon , FreeBSD Hackers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 18:11:55 -0000 Bakul Shah wrote this message on Sat, Mar 30, 2013 at 13:22 -0700: > On Sat, 30 Mar 2013 09:14:34 PDT John-Mark Gurney wrote: > > > > As someone else pointed out in this thread, if a userland program > > depends upon this behavior, it has a race condition in it... > > > > Thread 1 Thread 2 Thread 3 > > enters routine to read > > enters routine to close > > calls close(3) > > open() returns 3 > > does read(3) for orignal fd > > > > How can the original threaded program ensure that thread 2 doesn't > > create a new fd in between? So even if you use a lock, this won't > > help, because as far as I know, there is no enter read and unlock > > mutex call yet... > > It is worse. Consider: > > fd = open(file,...); > read(fd, ...); > > No guarantee read() gets data from the same opened file! > Another thread could've come along, closed fd and pointed it > to another file. So nothing is safe. Might as well stop using > threads, right?! Nope, you need your threads to cooperate w/ either locks or some ownership mechanism like token passing... As long as only one thread own the fd, you won't have troubles... > We are talking about cooperative threads where you don't have > to assume the worst case. Here not being notified on a close Multiple people have said when threads cooperate without locks, but no one has given a good example where they do... The cases you list below are IMO special (and extreme) cases... We were talking about "cooperating" threads in a general purpose langage like Java where you can not depend upon your other threads doing limited amount of work... > event can complicate things. As an example, I have done > something like this in the past: A frontend process validating > TCP connections and then passing on valid TCP connections to > another process for actual service (via sendmsg() over a unix > domain). All the worker threads in service process can do a > recvmsg() on the same fd. They process whatever tcp connection > they get. Now what happens when the frontend process is > restarted for some reason? All the worker threads need to > eventually reconnect to a new unix domain posted by the new > frontend process. You can handle this multiple ways but > terminating all the blocking syscalls on the now invalid fd is > the simplest solution from a user perspective. This'd make an interesting race... Not sure if it could happen, but close(), closes the receiving fd, but another thread is in the process of receiving an fd and puts the new fd in the close of the now closed unix domain socket... I can draw a more detailed diagram if you want.. > > I decided long ago that this is only solvable by proper use of locking > > and ensuring that if you call close (the syscall), that you do not have > > any other thread that may use the fd. It's the close routine's (not > > syscall) function to make sure it locks out other threads and all other > > are out of the code path that will use the fd before it calls close.. > > If you lock before close(), you have to lock before every > other syscall on that fd. That complicates userland coding and > slows down things when this can be handled more simply in the > kernel. There is "ownership" that can be passed, such as via kqueue _ONESHOT w/ multiple threads which allows you to avoid locking and only one thread ever owns the fd... > Another usecase is where N worker threads all accept() on the > same fd. Single threading using a lock defeats any performance > gain. In this case you still need to do something special since what happens if one of the worker threads opens a file and/or listen/accept socket as part of it's work? Thread 1 Thread 2 Thread 3 about to call accept but after flag check sets flag that close is going to be called accept connect process connection close listen'd socket open socket as part of processing gets same fd calls listen on socket calls accept on socket And there we have it, a race condition... You can't always guarantee what your worker threads do, if you can, it's good, but we need to make sure that beginner programs don't get into traps like these... They can easily make the mistake of saying, well, since close kicks all my threads out, I'll just do that instead of making sure that they don't have a race condition... > > If someone could describe how this new eject a person from read could > > be done in a race safe way, then I'd say go ahead w/ it... Otherwise > > we're just moving the race around, and letting people think that they > > have solved the problem when they haven't... > > In general it just makes sense to notify everyone waiting on > something that the situation has changed and they are going to > have to wait forever. The kernel should already have the > necessary information about which threads are sleeping on a > fd. Wake them all up. On being awakened they see that the fd > is no longer valid and all return with a count of data already > read or -1 and EBADF. Doing the equivalent in userland is > complicated. > > Carl has pointed out how BSD and Linux have required a > workaround compared to Solaris and OS X (in Java and IIRC, the > Go runtime). Seems like we have a number of usecases and this > is something worth fixing. I would like to know how a general purpose high level language like Java can avoid all the races that I brought up w/o locking the fd and, as you basicly said earlier, w/o the threads cooperating... To me it doesn't seem possible... Now if someone could explain it, I'd love to be proved wrong as it'd improve my knowlege of concurent systems... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Sat Apr 6 20:54:52 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 32330F94; Sat, 6 Apr 2013 20:54:52 +0000 (UTC) (envelope-from artemrts@ukr.net) Received: from ffe16.ukr.net (ffe16.ukr.net [195.214.192.51]) by mx1.freebsd.org (Postfix) with ESMTP id E2D969C; Sat, 6 Apr 2013 20:54:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Date:Message-Id:From:To:Subject:Cc:Content-Type:Content-Transfer-Encoding:MIME-Version; bh=ow8wf/SxFBYVLzwwVH0q9Z76TYRH5uA/dOQP7D8/BNw=; b=Wc6l0rDBfD5ih0K5eoqYYkksWKCyBWXuwa3170L1TCzsGNsqDaPCe+BvjryhPA+GfJ/jXynghVzjV6xyaVkR+QWjqlVI/nyNKE8nuqObeNhznBU77BUBjmT0Zd4Ruhlc7c4W2kEfjC16B49fnKoA+k44K/kVd6xq1iAAqHdljRk=; Received: from mail by ffe16.ukr.net with local ID 1UOZon-000Izc-VI ; Sat, 06 Apr 2013 23:34:33 +0300 MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: binary Content-Type: text/plain; charset="windows-1251" Subject: Problems with network on host with jail. To: freebsd-jail@freebsd.org From: "wishmaster" X-Mailer: freemail.ukr.net 4.0 Message-Id: <65534.1365280473.6122751498602086400@ffe16.ukr.net> Date: Sat, 06 Apr 2013 23:34:33 +0300 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 20:54:52 -0000 Hi. Since I setuped Jail for www stuff in server there are network problems. Router has 3 NIC's in bridge with aliases. cloned_interfaces="bridge0" ifconfig_bridge0="addm rl1 addm rl2 addm rl3 up" ifconfig_rl1="up -wol" ifconfig_rl2="up -wol" ifconfig_rl3="up -wol" ifconfig_bridge0_alias0="inet 10.11.1.1 netmask 255.255.255.0" ifconfig_bridge0_alias1="inet 10.12.1.1 netmask 255.255.255.0" ifconfig_bridge0_alias2="inet 10.13.1.1 netmask 255.255.255.0" ifconfig_bridge0_alias3="inet 10.14.1.1 netmask 255.255.255.192" ifconfig_bridge0_alias4="inet 10.15.1.1 netmask 255.255.255.0" Also I use PF for filtering traffic. There are a lot of rules. In two words: it is unable to reach any host in LAN and also any IP addresses on router, allowed access to Internet only. In other words Jail in original DMZ zone with IP 10.15.1.1. In random time (about one incident per-(2|3)days) the strange situations is occur: I am unable to ping/ftp/http from jail or from LAN any host in Internet. From/to router - it's ok. Restarting PF and jail seems to have no effect, only router's reboot. >From pftop I see traffic, coming from jail or LAN but in the other way - no. Anybody can give me some help in debugging this situation and figure out the problem? OS: FreeBSD 9.1-STABLE #0: Fri Feb 22 20:51:16 EET 2013 i386 Cheers, Vitaliy