From owner-freebsd-net@FreeBSD.ORG Sun May 12 00:15: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 7F70315D for ; Sun, 12 May 2013 00:15:43 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm33-vm2.bullet.mail.ne1.yahoo.com (nm33-vm2.bullet.mail.ne1.yahoo.com [98.138.229.66]) by mx1.freebsd.org (Postfix) with ESMTP id 32AD8E1 for ; Sun, 12 May 2013 00:15:42 +0000 (UTC) Received: from [98.138.226.178] by nm33.bullet.mail.ne1.yahoo.com with NNFMP; 12 May 2013 00:15:35 -0000 Received: from [98.138.89.171] by tm13.bullet.mail.ne1.yahoo.com with NNFMP; 12 May 2013 00:15:35 -0000 Received: from [127.0.0.1] by omp1027.mail.ne1.yahoo.com with NNFMP; 12 May 2013 00:15:35 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 950744.29547.bm@omp1027.mail.ne1.yahoo.com Received: (qmail 50045 invoked by uid 60001); 12 May 2013 00:15:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1368317735; bh=NmLpg1FuCFPQBUqo2WX/m6cDJdsoxjsYOornAiJmEXs=; 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=a0+kZ89acSsbyI2bXxIGdxHVwMDurpXp09Xct4PI2VtIj3Y03N3zBrbPuhctKaDdVhFgz78V7uV0tzhrX8ThMVq6pL97K8Djy3ITsi7z2qdIF5CxLPL79+0vUw/ffS2ZjeQ20MWMtUFycgK9wADWy/UTtBJj7kJ5QcUoed5QvXI= 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=m6WzRkwBsz4Wr9QpfUACzNh218UFdt8KbHD5w52ozkCNhIANFn4EupDuQGlx6WLZmzWbzYTFkleoe9LydN8A/IyhvfCzrIcjzPJ2Iv2zP+lnHPUaVWweqhVL+SX7oUXcYz5KlHPeySggwJ7f2Dm2km2NlbKfPfNfRgykbUF0/xM=; X-YMail-OSG: bBh59x4VM1k5jgzl6USm5zbnL1l_6tCpcY3VfyR8P2rZLJW 7UOZQa_.MYOR0jWVMrL6HVApyQjxZLDmKi2LtZ5UrA0w.AJSC2gLLM1yDK73 jZjusVCXMLLEwnVxNAd2oJ6RI3OtA2gKt8oOQRCoCYZmCXgMuhRHzzSuvVXk nVuUFH168Ey3peZS_ga_J6.If8ykF1geITeNWLjB.t62GaBAii1kNcSEnQsW M4hNQ66cldiKZOrl1ckWIB4ZjulMt0vFR.e7MXphOztK5NRwJpp2zA4hYDUm IWVthCAVYESoXgR0uKvi49CW6_mC95QXijzkD_Vvalav9SXa00YMy0hALTkI PMLyTm4eEnbZFOOmUQW7PTg9v8TzRM21sCu_imE0Y8TJqNKhJCmndDC6j9zq XAcXVHAfBl3KzSjoUUDl5W_5KBelmt499dIrDcGHYfEe.ycmIJs0XpHx4TmT 5s0LfJ783MuREjQN.gKRR4P3pbeQwukdx9KF2RtUTzNp4iqEIXjEJGP5Se9_ tUln8pihfQt9HRn23uwQqTi7X3MKozUeX6_uA83SgUw-- Received: from [98.203.118.124] by web121603.mail.ne1.yahoo.com via HTTP; Sat, 11 May 2013 17:15:35 PDT X-Rocket-MIMEInfo: 002.001, CgotLS0gT24gU2F0LCA1LzExLzEzLCBIb29tYW4gRmF6YWVsaSA8aG9vbWFuZmF6YWVsaUBnbWFpbC5jb20.IHdyb3RlOgoKPiBGcm9tOiBIb29tYW4gRmF6YWVsaSA8aG9vbWFuZmF6YWVsaUBnbWFpbC5jb20.Cj4gU3ViamVjdDogUmU6IEhpZ2ggQ1BVIGludGVycnVwdCBsb2FkIG9uIGludGVsIEkzNTBUNCB3aXRoIGlnYiBvbiA4LjMKPiBUbzogIkJhcm5leSBDb3Jkb2JhIiA8YmFybmV5X2NvcmRvYmFAeWFob28uY29tPgo.IENjOiAiRXVnZW5lIEdyb3NiZWluIiA8ZWdyb3NiZWluQHJkdGMucnU.LCBmcmUBMAEBAQE- X-Mailer: YahooMailClassic/15.1.8 YahooMailWebService/0.8.141.536 Message-ID: <1368317735.40898.YahooMailClassic@web121603.mail.ne1.yahoo.com> Date: Sat, 11 May 2013 17:15:35 -0700 (PDT) From: Barney Cordoba Subject: Re: High CPU interrupt load on intel I350T4 with igb on 8.3 To: Hooman Fazaeli In-Reply-To: <518EA643.5010505@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, =?iso-8859-1?Q?Cl=E9ment_Hermann_=28nodens=29?= , Eugene Grosbein 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, 12 May 2013 00:15:43 -0000 =0A=0A--- On Sat, 5/11/13, Hooman Fazaeli wrote:= =0A=0A> From: Hooman Fazaeli =0A> Subject: Re: Hig= h CPU interrupt load on intel I350T4 with igb on 8.3=0A> To: "Barney Cordob= a" =0A> Cc: "Eugene Grosbein" = , freebsd-net@freebsd.org, ""Cl=E9ment Hermann (nodens)"" =0A> Date: Saturday, May 11, 2013, 4:12 PM=0A> On 5/11/2013 8:26 PM, B= arney Cordoba=0A> wrote:=0A> > Clearly you don't understand the problem. Yo= ur logic is=0A> that because other drivers are defective also; therefore it= s=0A> not a driver problem? The problem is caused by a=0A> multi-threaded d= river that=0A> > haphazardly launches tasks and that doesn't manage the=0A>= case that the rest of the system can't handle the load. It's=0A> no differ= ent than a driver that barfs when mbuf clusters are=0A> exhausted. The answ= er=0A> > isn't to increase memory or mbufs, even though that may=0A> allevi= ate the problem. The answer is to fix the driver, so=0A> that it doesn't cr= ash the system for an event that is wholly=0A> predictable. igb has=0A> > 1= ) too many locks and 2) exasperates the problem by=0A> binding to cpus, whi= ch causes it to not only have to wait=0A> for the lock to free, but also fo= r a specific cpu to become=0A> free. So it chugs along=0A> > happily until = it encounters a bottleneck, at which=0A> point it quickly blows up the enti= re system in a domino=0A> effect. It needs to manage locks more efficiently= , and also=0A> to detect when the backup is=0A> > unmanageable. Ever since = FreeBSD 5 the answer has been=0A> "it's fixed in 7, or its fixed in 9, or i= t's fixed in 10".=0A> There will always be bottlenecks, and no driver shoul= d blow=0A> up the system no matter=0A> > what intermediate code may present= a problem. Its the=0A> driver's responsibility to behave and to drop packe= ts if=0A> necessary. BC=0A> =0A> And how the driver should behave? You sugg= est dropping the=0A> packets. Even if we accept=0A> that dropping packets i= s a good strategy in all=0A> configurations (which I doubt), the driver is= =0A> definitely not the best place to implement it, since that=0A> involves= duplication of similar=0A> code between drivers. Somewhere like the Ethern= et layer is a=0A> much better choice to watch=0A> load of packets and drop = them to prevent them to eat all the=0A> cores. Furthermore, ignoring=0A> th= e fact that pf is not optimized for multi-processors and=0A> blaming driver= s for not adjusting=0A> themselves with the this pf's fault, is a bit unfai= r, I=0A> believe.=0A> =0A=0AIt's easier to make excuses than to write a rea= lly good driver. I'll=0Agrant you that.=0ABC From owner-freebsd-net@FreeBSD.ORG Sun May 12 00:58:38 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 A13C3FB7; Sun, 12 May 2013 00:58:38 +0000 (UTC) (envelope-from linimon@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 798761DD; Sun, 12 May 2013 00:58:38 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4C0wcEa048119; Sun, 12 May 2013 00:58:38 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4C0wb8J048118; Sun, 12 May 2013 00:58:37 GMT (envelope-from linimon) Date: Sun, 12 May 2013 00:58:37 GMT Message-Id: <201305120058.r4C0wb8J048118@freefall.freebsd.org> To: slashwaves@yahoo.com, linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/178071: FreeBSD unable to recongize Kontron (Industrial Computer Source / ICS Advent) DM9601 Fast Ethernet Adapter 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, 12 May 2013 00:58:38 -0000 Old Synopsis: Driver for Kontron (Industrial Computer Source / ICS Advent) DM9601 Fast Ethernet Adapter New Synopsis: FreeBSD unable to recongize Kontron (Industrial Computer Source / ICS Advent) DM9601 Fast Ethernet Adapter State-Changed-From-To: open->suspended State-Changed-By: linimon State-Changed-When: Sun May 12 00:57:29 UTC 2013 State-Changed-Why: Reclassify and assign. Mark suspended awaiting patches. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun May 12 00:57:29 UTC 2013 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=178071 From owner-freebsd-net@FreeBSD.ORG Sun May 12 05:09: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 0C90AAAF for ; Sun, 12 May 2013 05:09:50 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by mx1.freebsd.org (Postfix) with ESMTP id C8690AF0 for ; Sun, 12 May 2013 05:09:49 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id va2so101492obc.27 for ; Sat, 11 May 2013 22:09:49 -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=6Ek0ADl8AlQY9NDZ/2dlTWYeMI31Ed/xBCjqd2VLcpA=; b=WCBNc8RcUnvzJF5JsiTvEPoY8AuMxTXpgaz14SvIUtOy9nL8mVEwbcsR2LLTGPlm9N zuop+NZ3NDwx3rjDUxAipkC2jS6XTMFPdEkSPMx+KqnkOhXsKUQqriXd51Bkiszkxvwu gG0M8nh2KRcj9DfVgVZPflNihdKeRRk8/bAzRoXD1uF0AlERD3xMMmwTQNn8E3v1wHCc AEWDk7GtDUzqgE9VDgwC+YDYf35gSmant47HvePDMXSnnE7adhDMiQ/ZCJNjcN++ncgb NIVLIdorsb8lzP/B0SArUH0Rpl4JkXozxHpNXz0DD8cGEbeeOmyUIzDaAUxza5wLHEdp 0MlQ== MIME-Version: 1.0 X-Received: by 10.182.165.131 with SMTP id yy3mr2115381obb.36.1368335389366; Sat, 11 May 2013 22:09:49 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.76.182.76 with HTTP; Sat, 11 May 2013 22:09:49 -0700 (PDT) In-Reply-To: <20130509.110631.74720486.sthaug@nethelp.no> References: <518B5F51.8020804@b0rken.org> <20130509.110631.74720486.sthaug@nethelp.no> Date: Sat, 11 May 2013 22:09:49 -0700 X-Google-Sender-Auth: vqcs4-ISk9k_3aIm3mRxhkFzcxU Message-ID: Subject: Re: IPv6 tunnel MTU of 1480 not effective From: Kevin Oberman To: sthaug@nethelp.no Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: jason@b0rken.org, 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, 12 May 2013 05:09:50 -0000 On Thu, May 9, 2013 at 2:06 AM, wrote: > > However I'm only able to send IPv6 packets from my host that fit an MTU > > of 1280 even though I've set the tunnel interface and per-route MTU to > > 1480, based on the "outer" ethernet connection having an MTU of 1500. > > Hurricane Electric supports this and I've set the MTU to 1480 on their > > side as well. > > > > This issue is evident when I try to send IPv6 pings larger than 1280 > > bytes to the remote tunnel peer. The outgoing echo request is chopped > > into two fragments, while the response comes back in one fragment, as > > follows: > > > > % ping6 -c 1 -s 1432 2001:470:1f08:84f::1 > > PING6(1480=40+8+1432 bytes) 2001:470:1f09:84f::2 --> 2001:470:1f08:84f::1 > > 1440 bytes from 2001:470:1f08:84f::1, icmp_seq=0 hlim=64 time=1.514 ms > > This is a "feature" (i.e. it's documented). See the ping6 -m option: > > -m By default, ping6 asks the kernel to fragment packets to fit into > the minimum IPv6 MTU. The -m option will suppress the behavior > in the following two levels: when the option is specified once, > the behavior will be disabled for unicast packets. When the > option is more than once, it will be disabled for both unicast > and multicast packets. > > In my opinion this behavior badly breaks POLA, and should be removed > (i.e. the current -m behavior should be the default). > > I have no great hope in getting this changed, though... > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > _ > Thanks, Steiner. I complained about this at least a couple of years ago and was told by the developer (I don't recall exactly who any more) that it was right and would not be changed. I really would love to see this reconsidered before IPv6 becomes much more popular as it will simply cause confusion, but I, too, fear that it is a lost cause. Please prove me wrong! -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-net@FreeBSD.ORG Sun May 12 07:53:12 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 07AEC2EE for ; Sun, 12 May 2013 07:53:12 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by mx1.freebsd.org (Postfix) with ESMTP id DC882F3D for ; Sun, 12 May 2013 07:53:11 +0000 (UTC) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 5EAC8C9432; Sun, 12 May 2013 07:53:05 +0000 (UTC) (envelope-from jinmei@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1368345191; bh=ydLomxmMEkP7/xr87Mxf1NJQ2Ddh7rozc2Cl6yYHjK0=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=GWzRDDrSfOS+G7dj03PyPGXLmqYNJdEry09WyL3ZEC+89//W3vRZZgypk+cCG1KYx xMgo7iFndWMj2OVKrexOJJgLHtqvTh2KbgOyz6k71jRAOERaFfF0j39btSrtwTokBT ePfl0mVFGBa2BLtzKTaNe87xzKUoIMXcjOG8Sx4c= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Sun, 12 May 2013 07:53:05 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from jmb.jinmei.org (99-105-57-202.lightspeed.sntcca.sbcglobal.net [99.105.57.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 23031216C40; Sun, 12 May 2013 07:53:05 +0000 (UTC) (envelope-from jinmei@isc.org) Date: Sun, 12 May 2013 00:53:03 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Kevin Oberman Subject: Re: IPv6 tunnel MTU of 1480 not effective In-Reply-To: References: <518B5F51.8020804@b0rken.org> <20130509.110631.74720486.sthaug@nethelp.no> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-DCC--Metrics: post.isc.org; whitelist X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mx.pao1.isc.org Cc: jason@b0rken.org, sthaug@nethelp.no, 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, 12 May 2013 07:53:12 -0000 At Sat, 11 May 2013 22:09:49 -0700, Kevin Oberman wrote: > > > However I'm only able to send IPv6 packets from my host that fit an MTU > > > of 1280 even though I've set the tunnel interface and per-route MTU to > > > 1480, based on the "outer" ethernet connection having an MTU of 1500. > > > Hurricane Electric supports this and I've set the MTU to 1480 on their > > > side as well. [...] > I complained about this at least a couple of years ago and was told by the > developer (I don't recall exactly who any more) that it was right and would > not be changed. I really would love to see this reconsidered before IPv6 > becomes much more popular as it will simply cause confusion, but I, too, > fear that it is a lost cause. What's "this" (to reconsider)? That ping6 fragments outgoing packets at 1280 octets (by default)? Or, more in general whether any outgoing IPv6 packet can initially honor the interface MTU? If it's the former, I personally believe the default behavior makes more sense because IPv6 doesn't have the concept of "don't fragment bit", so any packet/fragment larger than 1280 octets could be dropped at an intermediate router. In theory, we could recover from that situation if that router sent an ICMPv6 packet too big message and the kernel performed path MTU discovery (which in my understanding is not the case for non connected sockets like the one ping6 uses), but even if PTMU discovery worked, some initial echo requests would still be lost. As a user, I wouldn't like to bother to wonder the reason for the packet loss if my main concern is reachability check (that would be my primary purpose for using ping6). The same argument applies to non connected UDP sockets, and, in fact, DNS server implementations behave exactly like ping6 in that sense (fragmenting large DNS responses at 1280 octets), and exactly for that reason. If it's the latter, I thought at least TCP (if not also for other connected sockets) honors the best possible MTU, starting from the MTU of the outgoing interface. If it doesn't, I agree with you; it should be fixed, and I don't think it's a lost cause. --- JINMEI, Tatuya Internet Systems Consortium, Inc. From owner-freebsd-net@FreeBSD.ORG Sun May 12 08:00: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 2B5B6460 for ; Sun, 12 May 2013 08:00:17 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 73F5CF71 for ; Sun, 12 May 2013 08:00:16 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.6/8.14.6) with ESMTP id r4C80Bwj028594; Sun, 12 May 2013 15:00:12 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <518F4C06.3060500@rdtc.ru> Date: Sun, 12 May 2013 15:00:06 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130415 Thunderbird/17.0.5 MIME-Version: 1.0 To: Barney Cordoba Subject: Re: High CPU interrupt load on intel I350T4 with igb on 8.3 References: <1368287797.70288.YahooMailClassic@web121603.mail.ne1.yahoo.com> In-Reply-To: <1368287797.70288.YahooMailClassic@web121603.mail.ne1.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, =?UTF-8?B?IkNsw6ltZW50IEhlcm1hbm4gKG5vZGVucyk=?= =?UTF-8?B?Ig==?= 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, 12 May 2013 08:00:17 -0000 On 11.05.2013 22:56, Barney Cordoba wrote: >> In practice, the problem is easily solved without any change >> in the igb code. >> The same problem will occur for other NIC drivers too - >> if several NICs were combined within one lagg(4). So, driver >> is not guilty and >> solution would be same - eliminate bottleneck and you will >> be fine and capable >> to spread the load on several CPU cores. >> >> Therefore, I don't care of CS theory for this particular >> case. > > Clearly you don't understand the problem. Your logic is that because > other drivers are defective also; therefore its not a driver problem? The problem is not in drivers. Driver author should make no assumption of manner packets will be processed after NIC because there are pretty many patterns. NIC driver must get packets from the NIC with minimal overhead, loading so many CPU cores as it instructed to by system settings (loader.conf/sysctl.conf/etc.) and never do voluntary packet drops. > The problem is caused by a multi-threaded driver that haphazardly launches > tasks and that doesn't manage the case that the rest of the system can't > handle the load. This is not driver author who decides how many tasks to launch and what will happen with packets later. I, as system administrator, perform driver and system tuning for my particular task and I decide that, using system settings. > It's no different than a driver that barfs when mbuf > clusters are exhausted. The answer isn't to increase memory or mbufs, even > though that may alleviate the problem. The answer is to fix the driver, > so that it doesn't crash the system for an event that is wholly predictable. No crashes observed due to igb(4) and it is easy to make the system predictable with some tuning. > igb has 1) too many locks and 2) exasperates the problem by binding to > cpus, which causes it to not only have to wait for the lock to free, but > also for a specific cpu to become free. I can't say for locks but CPU binding is not a problem. One always can use cpuset(1) to make bindings suitable for particular task. For example, this is rcNG script I use for my igb-based BRAS'es to change default igb bindings: #!/bin/sh # PROVIDE: cpuset-igb # REQUIRE: FILESYSTEMS # BEFORE: netif # KEYWORD: nojail case "$1" in *start) echo "Binding igb(4) IRQs to CPUs" cpus=`sysctl -n kern.smp.cpus` vmstat -ai | sed -E '/^irq.*que/!d; s/^irq([0-9]+): igb([0-9]+):que ([0-9]+).*/\1 \2 \3/' |\ while read irq igb que do cpuset -l $(( ($igb+$que) % $cpus )) -x $irq done ;; esac There is no rocket science here. Even simplier script may be used to disable CPU bindings altogether using "cpuset -l all" command. > So it chugs along happily until > it encounters a bottleneck, at which point it quickly blows up the entire > system in a domino effect. It needs to manage locks more efficiently, and > also to detect when the backup is unmanageable. > Ever since FreeBSD 5 the answer has been "it's fixed in 7, or its fixed in > 9, or it's fixed in 10". There will always be bottlenecks, and no driver > should blow up the system no matter what intermediate code may present a > problem. Its the driver's responsibility to behave and to drop packets > if necessary. Voluntary packet drops at driver level should not be permitted. That's not driver's responsibility. I, as system administrator, expect from a driver to spit packets as fast as possible. I can employ some packet buffering system if I need it or use ng_car or dummynet or something to deal with bottlenecks. Or not to deal with them for purpose. NIC driver cannot know my needs. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Sun May 12 11:03:13 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 A23414BF for ; Sun, 12 May 2013 11:03:13 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 018BF6A5 for ; Sun, 12 May 2013 11:03:12 +0000 (UTC) Received: (qmail 67690 invoked from network); 12 May 2013 11:03:04 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 12 May 2013 11:03:04 -0000 Date: Sun, 12 May 2013 13:03:04 +0200 (CEST) Message-Id: <20130512.130304.74693108.sthaug@nethelp.no> To: jinmei@isc.org Subject: Re: IPv6 tunnel MTU of 1480 not effective From: sthaug@nethelp.no In-Reply-To: References: <20130509.110631.74720486.sthaug@nethelp.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: rkoberman@gmail.com, freebsd-net@freebsd.org, jason@b0rken.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, 12 May 2013 11:03:13 -0000 > > > > However I'm only able to send IPv6 packets from my host that fit an MTU > > > > of 1280 even though I've set the tunnel interface and per-route MTU to > > > > 1480, based on the "outer" ethernet connection having an MTU of 1500. > > > > Hurricane Electric supports this and I've set the MTU to 1480 on their > > > > side as well. > [...] > > I complained about this at least a couple of years ago and was told by the > > developer (I don't recall exactly who any more) that it was right and would > > not be changed. I really would love to see this reconsidered before IPv6 > > becomes much more popular as it will simply cause confusion, but I, too, > > fear that it is a lost cause. > > What's "this" (to reconsider)? That ping6 fragments outgoing packets > at 1280 octets (by default)? Or, more in general whether any outgoing > IPv6 packet can initially honor the interface MTU? What I want to happen is: When I use ping6 *and explicitly specify a packet size using the -s option*, I want the interface MTU to be honored. I don't want to have to specify -m as a sort of extra "yes, I really really mean it". This is, in my opinion, by far the least surprising behavior for the user - and would then work the same as the IPv4 ping command. It looks like an extremely simple change to make in the ping6.c file. (Long term, I would like ping and ping6 to become *one* program with default IPv4 or IPv6 based on the destination specified, and options -4 / -6 like telnet has. Same for traceroute / traceroute6. However, this is an aside.) Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Sun May 12 20:07:19 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 188F067E for ; Sun, 12 May 2013 20:07:19 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm5.bullet.mail.bf1.yahoo.com (nm5.bullet.mail.bf1.yahoo.com [98.139.212.164]) by mx1.freebsd.org (Postfix) with SMTP id BD47BCB9 for ; Sun, 12 May 2013 20:07:18 +0000 (UTC) Received: from [98.139.215.142] by nm5.bullet.mail.bf1.yahoo.com with NNFMP; 12 May 2013 20:07:12 -0000 Received: from [98.139.213.3] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 12 May 2013 20:07:12 -0000 Received: from [127.0.0.1] by smtp103.mail.bf1.yahoo.com with NNFMP; 12 May 2013 20:07:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1368389232; bh=8cnjSct0A2fEeelDAsYYYYdV9ZYLAUU6urWY6ma1sSw=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=Dkss36bvIQ70ezFiKlVeJARiJ7eZRCXDfLPsG0PbgPPxtWKXB80VKhtvZnQolnsQP1tvKzteLkC8PG+gHIiSvmFsXbd3bcilkcMUAJX3QJOrH5qKzxV+jj/KdvdG2cm9p4EPV6Pm9WGakU8uXnHI+c2GssslhcliNhz7qENp4ng= X-Yahoo-Newman-Id: 486807.98641.bm@smtp103.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: kImT08MVM1k_d7ogQ.BQ8syxtMU_crY5RL3UzzcdqjIi4es N4T9x2mLjiQiRpElfTDsOJcdN_d45cDSUaZoyDnyuuy6CKlWGfHqWYvKpXMj my4hj0T9oEIFCuc18FCMt7uaL1hkHJNNX8_lEgzlpwWvinr_A2EvS9Goblcv nt1Y0uUx1kys6fAvrTbi.6NFWmyVF7jac2wDHGsLC.3qIT.kxfU6l_FeNwST NM0ScpLOYwz_8zpbaO.eZ7Gk.ZAJrOJgYKf7M6OzskrvI0_4JWJeKP7GaTv7 wukjywuSk5t2rC5jm1JPv_oXDN0HYp5Ewj1pExt3eN9NNcUPPBdfuHqURRFF H.ViT.eY4wJebQe3IKXzh_hqV9jCe6pgAdHG1Z_4vEffTzfL4GBWLwYpbd9j YXUi1D.dx_3ca9R3gC5WTHFOrgEs_W.Rsz.ihzTZAzwdDAGkSLY6tlSzZomD 1P67y__mM0M5hnA-- X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- X-Rocket-Received: from [192.168.254.206] (scott4long@168.103.85.57 with ) by smtp103.mail.bf1.yahoo.com with SMTP; 12 May 2013 13:07:12 -0700 PDT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: High CPU interrupt load on intel I350T4 with igb on 8.3 From: Scott Long In-Reply-To: <518EA643.5010505@gmail.com> Date: Sun, 12 May 2013 14:07:11 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <195AF945-C1C9-4EE8-9A8E-A196E4658184@yahoo.com> References: <1368287797.70288.YahooMailClassic@web121603.mail.ne1.yahoo.com> <518EA643.5010505@gmail.com> To: Hooman Fazaeli X-Mailer: Apple Mail (2.1503) Cc: freebsd-net@freebsd.org, =?iso-8859-1?Q?=22Cl=E9ment_Hermann_=28nodens=29=22?= , Eugene Grosbein 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, 12 May 2013 20:07:19 -0000 On May 11, 2013, at 2:12 PM, Hooman Fazaeli = wrote: > On 5/11/2013 8:26 PM, Barney Cordoba wrote: >> Clearly you don't understand the problem. Your logic is that because = other drivers are defective also; therefore its not a driver problem? = The problem is caused by a multi-threaded driver that >> haphazardly launches tasks and that doesn't manage the case that the = rest of the system can't handle the load. It's no different than a = driver that barfs when mbuf clusters are exhausted. The answer >> isn't to increase memory or mbufs, even though that may alleviate the = problem. The answer is to fix the driver, so that it doesn't crash the = system for an event that is wholly predictable. igb has >> 1) too many locks and 2) exasperates the problem by binding to cpus, = which causes it to not only have to wait for the lock to free, but also = for a specific cpu to become free. So it chugs along >> happily until it encounters a bottleneck, at which point it quickly = blows up the entire system in a domino effect. It needs to manage locks = more efficiently, and also to detect when the backup is >> unmanageable. Ever since FreeBSD 5 the answer has been "it's fixed in = 7, or its fixed in 9, or it's fixed in 10". There will always be = bottlenecks, and no driver should blow up the system no matter >> what intermediate code may present a problem. Its the driver's = responsibility to behave and to drop packets if necessary. BC >=20 > And how the driver should behave? You suggest dropping the packets. = Even if we accept > that dropping packets is a good strategy in all configurations (which = I doubt), the driver is > definitely not the best place to implement it, since that involves = duplication of similar > code between drivers. Somewhere like the Ethernet layer is a much = better choice to watch > load of packets and drop them to prevent them to eat all the cores. = Furthermore, ignoring > the fact that pf is not optimized for multi-processors and blaming = drivers for not adjusting > themselves with the this pf's fault, is a bit unfair, I believe. >=20 Fortunately I no longer receive Barney's emails, but it still distresses = me to see him trolling the list. It should be a pretty big hint that Barney has nothing to offer the = conversation when he suggests on a technical level that dropping packets is an acceptable = policy for drivers. The conversation is also over when he resorts to the ad hominem attacks = and the blanket "driver X sucks and you all are too lazy to follow my brilliance = in fixing it" tripe. Can we all just put him on ignore and move on? A brief search of the PR = database shows no contributions from him. A brief search of the mailing lists = shows only inflamed diatribes and insults from him, with a brief smattering here = and there of benign but content-free posts. On the other hand, if the consensus here is to keep on baiting and = feeding him for our own amusement, I applaud the effort but ask for a bit more subtlety = =3D-) Thanks! Scott From owner-freebsd-net@FreeBSD.ORG Sun May 12 20:30: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 9CF6BA3E for ; Sun, 12 May 2013 20:30:08 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by mx1.freebsd.org (Postfix) with ESMTP id 6BC36D68 for ; Sun, 12 May 2013 20:30:08 +0000 (UTC) Received: by mail-oa0-f48.google.com with SMTP id i4so6641256oah.7 for ; Sun, 12 May 2013 13:30:02 -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=9+a2Up1gCOXpBJGSEERWQ/O2Ttyzh1wJP/XkFD1yuZM=; b=mIqDoAmUEEqCNyp3Az23qV3KSmEy59ahCvor38gWDXsiITMRw32VKgy5sdPwZdLNpE mNTDoaYJ37iNqcaftHS1uU9FI5YyIe9Vgmcw4az2Rr+nk3ptQmeD2bYJSmCnTGEMvu1t AeBjDk7JqtTw0NlE8VpZ86sdmnxiQHuLxPlNfYl3NGC+inryoBBAUSvHOEHqcTh/tEjz bu/akk65qGzDC6v1yewwmRcQtQj/ZE1etEHzdI+JP2tNRq5JADZmE52Vh/Q/34lORy3q PNb+pDLN01E3zVsvDITe8x9YDAIOa8OvkxGLhjwV8BlUastSy4vPgg06rO/juGq6LR++ g7lQ== MIME-Version: 1.0 X-Received: by 10.182.109.229 with SMTP id hv5mr11327534obb.61.1368390602758; Sun, 12 May 2013 13:30:02 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.76.182.76 with HTTP; Sun, 12 May 2013 13:30:02 -0700 (PDT) In-Reply-To: <20130512.130304.74693108.sthaug@nethelp.no> References: <20130509.110631.74720486.sthaug@nethelp.no> <20130512.130304.74693108.sthaug@nethelp.no> Date: Sun, 12 May 2013 13:30:02 -0700 X-Google-Sender-Auth: RruHzxSaANIWSP9o_rPpSE7Q1NA Message-ID: Subject: Re: IPv6 tunnel MTU of 1480 not effective From: Kevin Oberman To: sthaug@nethelp.no Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: jason@b0rken.org, jinmei@isc.org, 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, 12 May 2013 20:30:08 -0000 On Sun, May 12, 2013 at 4:03 AM, wrote: > > > > > However I'm only able to send IPv6 packets from my host that fit > an MTU > > > > > of 1280 even though I've set the tunnel interface and per-route > MTU to > > > > > 1480, based on the "outer" ethernet connection having an MTU of > 1500. > > > > > Hurricane Electric supports this and I've set the MTU to 1480 on > their > > > > > side as well. > > [...] > > > I complained about this at least a couple of years ago and was told by > the > > > developer (I don't recall exactly who any more) that it was right and > would > > > not be changed. I really would love to see this reconsidered before > IPv6 > > > becomes much more popular as it will simply cause confusion, but I, > too, > > > fear that it is a lost cause. > > > > What's "this" (to reconsider)? That ping6 fragments outgoing packets > > at 1280 octets (by default)? Or, more in general whether any outgoing > > IPv6 packet can initially honor the interface MTU? > > What I want to happen is: When I use ping6 *and explicitly specify a > packet size using the -s option*, I want the interface MTU to be > honored. I don't want to have to specify -m as a sort of extra "yes, > I really really mean it". > > This is, in my opinion, by far the least surprising behavior for the > user - and would then work the same as the IPv4 ping command. > > It looks like an extremely simple change to make in the ping6.c file. > > (Long term, I would like ping and ping6 to become *one* program with > default IPv4 or IPv6 based on the destination specified, and options > -4 / -6 like telnet has. Same for traceroute / traceroute6. However, > this is an aside.) > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > Sorry to be so hackneyed, but... +1 Sorry that I was unclear (and may have been last time, too). -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-net@FreeBSD.ORG Mon May 13 00:12:16 2013 Return-Path: Delivered-To: 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 25E4683B for ; Mon, 13 May 2013 00:12:16 +0000 (UTC) (envelope-from nourimane21@gmail.com) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by mx1.freebsd.org (Postfix) with ESMTP id B7001846 for ; Mon, 13 May 2013 00:12:15 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id b13so5872766wgh.30 for ; Sun, 12 May 2013 17:12:14 -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:content-type; bh=VXD0qkt8kZVCoaIwFGCS14SYkWAn9DiDJwD8TOLCXLI=; b=0XOpGXB8FifzYrnicfAWeIhl9qJN/eBJ1rGLj8MMWoeCq3hcJZ0eZ7axWmL/xjjf2N QrqVAKO3DAGWr+0K3ccwOcDXTHsetqNO665qobDM3IAZx2x02tW48lBQRgtME/27V7Sj 44lzmNP5/MtTaQVdd1LNQus71PWPPSbZ/xZ1ONyaniEXt8HwmRSgK7ZRyHj9LY0x4Vl/ toYM6FT4SGRKSAChK+gnmFYGkqR4PxHL+OFJZHxdp5h4JkcgGY3M64KlaBYT3Fbb2Ccl /DInlmvZszsLKDPbPGPdgJIJmurqHk7yf3Wwr2Ga8v5/mEj85hzdB5nQhB1KnnIyuPqq a8Cw== MIME-Version: 1.0 X-Received: by 10.180.88.162 with SMTP id bh2mr15275267wib.3.1368403934792; Sun, 12 May 2013 17:12:14 -0700 (PDT) Received: by 10.227.0.80 with HTTP; Sun, 12 May 2013 17:12:14 -0700 (PDT) In-Reply-To: References: Date: Mon, 13 May 2013 00:12:14 +0000 Message-ID: Subject: Re: mipv6 From: Ouyahia Nourimane To: net@freebsd.org 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: Mon, 13 May 2013 00:12:16 -0000 i'm not used to work with freebsd. so i will be so thankful if someone help me by giving me the best version with kame configuration(with details) ... i want to configure a home agent and a mobile node to test MIPV6 in freebsd ... thanks On Thu, May 9, 2013 at 1:51 AM, Ouyahia Nourimane wrote: > hello, i'm a student > i have a project about mipv6 and i wish that you can help me > i want to test mipv6 with freebsd but i didn't realize how to configure > kame > which is the last version that support kame and can you give me iso image > of this version with kame ... > i'm waiting your answer > thanks > From owner-freebsd-net@FreeBSD.ORG Mon May 13 05:30: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 D41B4365 for ; Mon, 13 May 2013 05:30:08 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 9D01A6D9 for ; Mon, 13 May 2013 05:30:08 +0000 (UTC) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) by lauren.room52.net (Postfix) with ESMTPSA id 984EA7E81E; Mon, 13 May 2013 15:30:06 +1000 (EST) Message-ID: <51907A5E.2040202@freebsd.org> Date: Mon, 13 May 2013 15:30:06 +1000 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130314 Thunderbird/17.0.4 MIME-Version: 1.0 To: Ouyahia Nourimane Subject: Re: mipv6 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net 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, 13 May 2013 05:30:08 -0000 On 05/09/13 11:51, Ouyahia Nourimane wrote: > hello, i'm a student > i have a project about mipv6 and i wish that you can help me > i want to test mipv6 with freebsd but i didn't realize how to configure > kame > which is the last version that support kame and can you give me iso image > of this version with kame ... > i'm waiting your answer I was involved in some experimental research with the KAME MIPv6 code many years ago [1]: L. Stewart, M. Banh, G, Armitage, "Implementing an IPv6 and Mobile IPv6 testbedusing FreeBSD 4.9 and KAME," CAIA Technical Report 040331A, March 2004 The code stopped being developed around that time so I'm guessing the FreeBSD 4.x series and 5.x series are the most recent FreeBSD versions you would be able to easily get the KAME code running on. Cheers, Lawrence http://caia.swin.edu.au/reports/040331A/CAIA-TR-040331A.pdf From owner-freebsd-net@FreeBSD.ORG Mon May 13 08:40:01 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 EE72FF2B for ; Mon, 13 May 2013 08:40: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 E03F1EA7 for ; Mon, 13 May 2013 08:40:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4D8e1Rb046907 for ; Mon, 13 May 2013 08:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4D8e1Ie046903; Mon, 13 May 2013 08:40:01 GMT (envelope-from gnats) Date: Mon, 13 May 2013 08:40:01 GMT Message-Id: <201305130840.r4D8e1Ie046903@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Mitya Subject: Re: kern/120304: [netgraph] [patch] netgraph source assumes 32-bit timeval on AMD64 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Mitya List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 08:40:02 -0000 The following reply was made to PR kern/120304; it has been noted by GNATS. From: Mitya To: bug-followup@FreeBSD.org, mcn@EnGarde.com Cc: Subject: Re: kern/120304: [netgraph] [patch] netgraph source assumes 32-bit timeval on AMD64 Date: Mon, 13 May 2013 11:01:20 +0300 This is a multi-part message in MIME format. --------------000802080404020703030804 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit This is a more accuracy patch --------------000802080404020703030804 Content-Type: text/plain; charset=UTF-8; name="ng_source.c.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ng_source.c.diff" LS0tIG5nX3NvdXJjZS5jLm9yaWcJMjAxMS0wOS0yMyAwMzo1MTozNy4wMDAwMDAwMDAgKzAz MDAKKysrIG5nX3NvdXJjZS5jCTIwMTMtMDUtMDMgMTQ6MTg6MTguMDAwMDAwMDAwICswMzAw CkBAIC0xMjYsOCArMTI2LDE2IEBACiAKIC8qIFBhcnNlIHR5cGUgZm9yIHRpbWV2YWwgKi8K IHN0YXRpYyBjb25zdCBzdHJ1Y3QgbmdfcGFyc2Vfc3RydWN0X2ZpZWxkIG5nX3NvdXJjZV90 aW1ldmFsX3R5cGVfZmllbGRzW10gPSB7CisjaWYgZGVmaW5lZChfX0xQNjRfXykgfHwgZGVm aW5lZChfX2FybV9fKSB8fCBkZWZpbmVkKF9fbWlwc19fKQorCXsgInR2X3NlYyIsCQkmbmdf cGFyc2VfaW50NjRfdHlwZQl9LAorI2Vsc2UKIAl7ICJ0dl9zZWMiLAkJJm5nX3BhcnNlX2lu dDMyX3R5cGUJfSwKKyNlbmRpZgorI2lmIGRlZmluZWQoX19MUDY0X18pCisJeyAidHZfdXNl YyIsCQkmbmdfcGFyc2VfaW50NjRfdHlwZQl9LAorI2Vsc2UKIAl7ICJ0dl91c2VjIiwJCSZu Z19wYXJzZV9pbnQzMl90eXBlCX0sCisjZW5kaWYKIAl7IE5VTEwgfQogfTsKIGNvbnN0IHN0 cnVjdCBuZ19wYXJzZV90eXBlIG5nX3NvdXJjZV90aW1ldmFsX3R5cGUgPSB7Cg== --------------000802080404020703030804-- From owner-freebsd-net@FreeBSD.ORG Mon May 13 11:06: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 AC27E9AD for ; Mon, 13 May 2013 11:06:48 +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 9E50684B for ; Mon, 13 May 2013 11:06:48 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4DB6mOq075942 for ; Mon, 13 May 2013 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4DB6mIn075940 for freebsd-net@FreeBSD.org; Mon, 13 May 2013 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 13 May 2013 11:06:48 GMT Message-Id: <201305131106.r4DB6mIn075940@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, 13 May 2013 11:06:48 -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/178472 net [ip6] [patch] make return code consistent with IPv4 co o kern/178116 net [ipfilter] [panic] Kernel panic: general protection fa s kern/178071 net FreeBSD unable to recongize Kontron (Industrial Comput o kern/177905 net [xl] [panic] ifmedia_set when pluging CardBus LAN card o kern/177618 net [bridge] Problem with bridge firewall with trunk ports 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/177366 net [ieee80211] negative malloc(9) statistics for 80211nod f kern/177362 net [netinet] [patch] Wrong control used to return TOS o kern/177194 net [netgraph] Unnamed netgraph nodes for vlan interfaces 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/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/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 checksu 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] [ipfilter] ipfilter/nat NULL pointer deference p 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 [ipfilter] There is no ippool start script/ipfilter ma 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 [ipfilter] [rc.d] [patch] No good way to set ipfilter 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 [ipfilter] FreeBSD 6.1+VPN+ipnat+ipf: port mapping doe 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 [ipfilter] [panic] Kernel Panic Trap No 12 Page Fault 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 [ipfilter] [patch] ipfilter drops OOW packets under 6. 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 [ipfilter] [patch] wrong behaviour with skip rule insi 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 [ipfilter] [panic] using ipfilter "auth" keyword leads 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 [ipfilter] 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 [ipfilter] [patch] ipfilter ioctl SIOCGNATL does not m 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 [ipfilter] ipfilter ipnat problem with h323 proxy supp 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 [ipfilter] [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 [ipfilter] [ppp] Interactive use of user PPP and ipfil 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 May 13 17:00:50 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 CB5707DD for ; Mon, 13 May 2013 17:00:50 +0000 (UTC) (envelope-from hamque@yahoo.cn) Received: from ns.easyway-group.com (ns.easyway-group.com [219.87.143.98]) by mx1.freebsd.org (Postfix) with ESMTP id 98D31928 for ; Mon, 13 May 2013 17:00:50 +0000 (UTC) Received: from BOUD-TERM (213.177.230.93.adsl.griffin.net.uk [213.177.230.93]) (Authenticated sender: albert@mail.easyway-group.com) by ns.easyway-group.com (Postfix) with ESMTP id 114E62738671 for ; Tue, 14 May 2013 00:49:30 +0800 (CST) From: "Hamidul Haque" Subject: Request for Partnership To: freebsd-net@freebsd.org MIME-Version: 1.0 Date: Mon, 13 May 2013 17:49:32 +0100 Message-Id: <20130513164931.114E62738671@ns.easyway-group.com> Content-Type: text/plain 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 Reply-To: haaque@postino.at List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 17:00:50 -0000 - This mail is in HTML. Some elements may be ommited in plain text. - My good friend, I am aware of the unsafe nature of the internet but due to the prevail= ing circumstances I don?t have any other option than to seek for partn= ership through this medium. Permit me, My Name is Mr Hamidul Haque, ci= tizen of Bangladesh and Managing partner with M/S &H Corporation. = I am searching for a foreign partner who will partner with me in the c= ompletion of a Multimillion Dollar transaction. This transaction has t= o do with the Asian Development Bank Financed Natural Gas Assess Impro= vement Project. The transaction is 100% risk free, financially profitable and economic= ally viable. I am open for negotiation. All arrangements will be made = under a legitimate framework. Full details will be disclosed to you on= your expression of interest. I look forward to doing good business wi= th you. Warmest Regards, Hamidul Haque From owner-freebsd-net@FreeBSD.ORG Tue May 14 01:10:41 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 AEC9D4B9 for ; Tue, 14 May 2013 01:10:41 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm19-vm3.bullet.mail.ne1.yahoo.com (nm19-vm3.bullet.mail.ne1.yahoo.com [98.138.91.149]) by mx1.freebsd.org (Postfix) with ESMTP id 7597A61C for ; Tue, 14 May 2013 01:10:41 +0000 (UTC) Received: from [98.138.90.52] by nm19.bullet.mail.ne1.yahoo.com with NNFMP; 14 May 2013 01:08:50 -0000 Received: from [98.138.87.4] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 14 May 2013 01:08:50 -0000 Received: from [127.0.0.1] by omp1004.mail.ne1.yahoo.com with NNFMP; 14 May 2013 01:08:50 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 862916.61777.bm@omp1004.mail.ne1.yahoo.com Received: (qmail 57983 invoked by uid 60001); 14 May 2013 01:08:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1368493730; bh=usAoBF5wCf772eFoRqH6WsnTFg5UVkN7vSYQOVDJBYY=; 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=lq2sF62RX/U4mfP9sQRfUahfS1pCLPi3ELKxgQ4gb76rQpxqGi6w4vf5NS/I5qTfbFhg4Bo0qvB+eOWxYrpTalXJYUQuEjWpf8pOIZ733vmXP5bAszY+fODWnedkyJh9gwGEiZt3OjCdn1D4JIfM5shdlaPkTswNd3Gl1nms2DA= 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=HeeV+BIjOrmu7e5eT5baLMmvxSLm7XGK+YxyHCePKtD2ByTanRsX9hDZ7ZXe96TT4j4SmNFKC0whG9lYrA+1hSlrI4tLOzQk1wbw9Q9C1nWjmD3zb0l9O/GRdtYNEpTvhbySbhrGL8fUbkRPn9YctDOEaSTloMHmGGEOcltZSj0=; X-YMail-OSG: rutnDekVM1lPT62pv7ghXyxw_R1P50Ii7A1sTtI9k.wKGno asrUtBTIEaJ4I2vM9PpPySmpOtdWSDLoZY34htCnLqRNKCXZU4zLrAad2r3i 49d4DwPUOYpd1Y4iGVijgpzfQMhD.wVnEaiE2rosSN46wgBJEWmAwTQUMzCa 1Zzvlml2KLXbgs4FjlrUhwdK6cjxtUGlIokJve0wr0lUJSDaahbj05sebt3L NlKHHLW1rSq.rLmCF4vKLsGLKCQo96ChnATW1klRn19X6t8bYp3Q8GMqQImH NsVtQgcmEFC54cLsRMDrUKp0RyapuVWYdVkiJezE2S.ttixfGCzDb4_sqXm7 fY_PKGlNXIVEmqagO2x83kW6x4vnEPTokZYZpA48i5JKmkcDij3enUR3vrrF MBjouejBI.xPvGSYuhL6Jcipp.VRjpa5srxxrCHA3u9BXo7Rv3Il7udodFL8 4TbQUbGc_L4db6hFyU_hePg3765gV5zI935aF4saK9za8NWjDYl64MS02MDs cYKGgZBAsuszbp3nzE_sX5CSjhmj.GFJu7ahcKUMGiQ-- Received: from [98.203.118.124] by web121601.mail.ne1.yahoo.com via HTTP; Mon, 13 May 2013 18:08:50 PDT X-Rocket-MIMEInfo: 002.001, WW91IGhhdmUgdG8gYWRtaXQgdGhlcmUncyBhIHByb2JsZW0gYmVmb3JlIHlvdSBjYW4gZml4IGl0LiBJZiBFdWdlbmUgaXMgDQpnb2luZyB0byBibGFtZSB0byBib3R0bGVuZWNrIGFuZCBubyBvbmUgaXMgZ29pbmcgdG8gdGVsbCBoaW0gaGUncyB3cm9uZywNCnRoZW4gdGhlcmUgaXMgbm8gZGlzY3Vzc2lvbi4NCg0KVGhlIHNvbHV0aW9uIGluIHRoaXMgY2FzZSBpcyB0byB1c2UgMSBxdWV1ZSwgd2hpY2ggd2FzIG15IHN1Z2dlc3Rpb24NCm1hbnkgZGF5cyBhZ28uIA0KDQpUaGUgZGVmYXVsdHMgYXJlIGJyb2sBMAEBAQE- X-Mailer: YahooMailClassic/15.1.8 YahooMailWebService/0.8.141.536 Message-ID: <1368493730.55723.YahooMailClassic@web121601.mail.ne1.yahoo.com> Date: Mon, 13 May 2013 18:08:50 -0700 (PDT) From: Barney Cordoba Subject: Re: High CPU interrupt load on intel I350T4 with igb on 8.3 To: Hooman Fazaeli , Adrian Chadd In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, =?iso-8859-1?Q?Cl=E9ment_Hermann_=28nodens=29?= , Eugene Grosbein 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, 14 May 2013 01:10:41 -0000 You have to admit there's a problem before you can fix it. If Eugene is=20 going to blame to bottleneck and no one is going to tell him he's wrong, then there is no discussion. The solution in this case is to use 1 queue, which was my suggestion many days ago.=20 The defaults are broken. The driver should default to 1 queue, and be tuned to the system environment. With 2 NICs in the box, the defaults are defective.=20 1 queue should always work. Other settings require tuning and an understanding of how things work.=20 I've had to support i350 so I've been playing with the driver a bit. It=20 works fine with lots of cores. But you have to have more cores than queues. 2 cards with 4 queues on a 6 physical core system gets into a contention problem at certain loads. I've also removed the cpu bindings, which is about all I'm free to disclose= . The driver needs a tuning doc as much as anything else. BC --- On Sat, 5/11/13, Adrian Chadd wrote: > From: Adrian Chadd > Subject: Re: High CPU interrupt load on intel I350T4 with igb on 8.3 > To: "Hooman Fazaeli" > Cc: "Barney Cordoba" , ""Cl=E9ment Hermann (nod= ens)"" , "Eugene Grosbein" , freeb= sd-net@freebsd.org > Date: Saturday, May 11, 2013, 6:16 PM > Hi, >=20 > The motivation behind the locking scheme in igb in friends > is for a > very specific, userland-traffic-origin workload. >=20 > Sure, it may or may not work well for forwarding/filtering > workloads. >=20 > If you want to fix it, let's have a discussion about how to > do it, > followed by some patches to do so. >=20 >=20 >=20 >=20 > Adrian >=20 > On 11 May 2013 13:12, Hooman Fazaeli > wrote: > > On 5/11/2013 8:26 PM, Barney Cordoba wrote: > >> Clearly you don't understand the problem. Your > logic is that because other drivers are defective also; > therefore its not a driver problem? The problem is caused by > a multi-threaded driver that > >> haphazardly launches tasks and that doesn't manage > the case that the rest of the system can't handle the load. > It's no different than a driver that barfs when mbuf > clusters are exhausted. The answer > >> isn't to increase memory or mbufs, even though that > may alleviate the problem. The answer is to fix the driver, > so that it doesn't crash the system for an event that is > wholly predictable. igb has > >> 1) too many locks and 2) exasperates the problem by > binding to cpus, which causes it to not only have to wait > for the lock to free, but also for a specific cpu to become > free. So it chugs along > >> happily until it encounters a bottleneck, at which > point it quickly blows up the entire system in a domino > effect. It needs to manage locks more efficiently, and also > to detect when the backup is > >> unmanageable. Ever since FreeBSD 5 the answer has > been "it's fixed in 7, or its fixed in 9, or it's fixed in > 10". There will always be bottlenecks, and no driver should > blow up the system no matter > >> what intermediate code may present a problem. Its > the driver's responsibility to behave and to drop packets if > necessary. BC > > > > And how the driver should behave? You suggest dropping > the packets. Even if we accept > > that dropping packets is a good strategy in all > configurations (which I doubt), the driver is > > definitely not the best place to implement it, since > that involves duplication of similar > > code between drivers. Somewhere like the Ethernet layer > is a much better choice to watch > > load of packets and drop them to prevent them to eat > all the cores. Furthermore, ignoring > > the fact that pf is not optimized for multi-processors > and blaming drivers for not adjusting > > themselves with the this pf's fault, is a bit unfair, I > believe. > > > > > > -- > > > > Best regards. > > Hooman Fazaeli > > > > _______________________________________________ > > 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 May 14 06:56:17 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 403DAB3D; Tue, 14 May 2013 06:56:17 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 87A1D620; Tue, 14 May 2013 06:56:15 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.6/8.14.6) with ESMTP id r4E6uBx2060419; Tue, 14 May 2013 13:56:12 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <5191E006.4060403@rdtc.ru> Date: Tue, 14 May 2013 13:56:06 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130415 Thunderbird/17.0.5 MIME-Version: 1.0 To: Barney Cordoba Subject: Re: High CPU interrupt load on intel I350T4 with igb on 8.3 References: <1368493730.55723.YahooMailClassic@web121601.mail.ne1.yahoo.com> In-Reply-To: <1368493730.55723.YahooMailClassic@web121601.mail.ne1.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Adrian Chadd , =?UTF-8?B?IkNsw6ltZW50IEhlcm1hbm4gKG5vZGVucyki?= , Hooman Fazaeli 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, 14 May 2013 06:56:17 -0000 On 14.05.2013 08:08, Barney Cordoba wrote: > The defaults are broken. Finally we managed to get to the point. Hallelujah! From owner-freebsd-net@FreeBSD.ORG Tue May 14 12:02: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 3B8E35EB for ; Tue, 14 May 2013 12:02:53 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id BAE426E1 for ; Tue, 14 May 2013 12:02:52 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.6/8.14.6) with ESMTP id r4EC2leE063910; Tue, 14 May 2013 19:02:47 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <519227E2.2090801@rdtc.ru> Date: Tue, 14 May 2013 19:02:42 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130415 Thunderbird/17.0.5 MIME-Version: 1.0 To: h bagade Subject: Re: how to completely makes an interface down? References: <20130124195056.GB1410@funkthat.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, John-Mark Gurney , 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: Tue, 14 May 2013 12:02:53 -0000 On 26.01.2013 14:15, h bagade wrote: > I've tried the command on freebsd 8.2 with em card but doesn't work as you > mentioned. > I need such an operation to disable the connection and yes, not the led but > the link establishment itself. Is there a way to have this option on em and > igb drivers on freebsd 8.2? I've needed this feature several years ago so I made a patch for igb(4) and em(4) drivers. The patch introduces new per-interface sysctls with default zero values: dev.em.X.down_disables_link dev.igb.X.down.disables_link With this patch, sysctl dev.em.0.down_disables_link=1 makes "ifconfig em0 down" bring link down. For LACP mode this feature is very useful as it makes LACP peer reconfigure itself quickly. For 8.2: http://www.grosbein.net/freebsd/patches/em_sysctl.diff.gz http://www.grosbein.net/freebsd/patches/igb_sysctl.diff.gz For newer versions (8.3 and 9.1): http://www.grosbein.net/freebsd/patches/em_sysctl-8.3.diff.gz http://www.grosbein.net/freebsd/patches/igb_sysctl-8.3.diff.gz From owner-freebsd-net@FreeBSD.ORG Tue May 14 18:43:06 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 B304F9DD for ; Tue, 14 May 2013 18:43:06 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by mx1.freebsd.org (Postfix) with ESMTP id 4D1B21B1 for ; Tue, 14 May 2013 18:43:06 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id ey16so818642wid.17 for ; Tue, 14 May 2013 11:43: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=Ys/YhZDSQ5X5bWSvGc6KKCXWRro9SsBC3rt0OMxnuno=; b=u3He9ybwtDgAV3O2cJVKJw4v3ehIUgJ5LFDbuDH3l2zdumAUUjJPlHAwwFyvE+/VQX WOEyXrBxxSCf0SuiTkbnoOHPQgcOqb38zoPODRWN/JikgPVbxHOycwa4sYX1gfHY4E4O WK/E8xRlDd+p5c0I4T80u/WVkMEi5ETP71P6G/phNKMvePyCJd0uPEtXGrveIQ60dHDi 9MIoh+gq/jZOL+Ipqz3WOjOOshMMPooEBDA/nPt0HDK5Z1FrybMnH8mxlKOQsEitE0/W +KpToEjOKvvSGaq3TdfP/+766PUpvExbB04l2qiF6xlG+eFu4J0G6ZAbvXm9bGxd6Ede Cxig== X-Received: by 10.180.36.229 with SMTP id t5mr9211200wij.21.1368556985434; Tue, 14 May 2013 11:43:05 -0700 (PDT) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.194.234.72 with HTTP; Tue, 14 May 2013 11:42:45 -0700 (PDT) In-Reply-To: <519227E2.2090801@rdtc.ru> References: <20130124195056.GB1410@funkthat.com> <519227E2.2090801@rdtc.ru> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Tue, 14 May 2013 20:42:45 +0200 X-Google-Sender-Auth: 6R8_MYitSIsi-6g_UsvOJ869fKk Message-ID: Subject: Re: how to completely makes an interface down? To: Eugene Grosbein Content-Type: text/plain; charset=KOI8-R Cc: h bagade , "freebsd-net@freebsd.org" , John-Mark Gurney , 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: Tue, 14 May 2013 18:43:06 -0000 On Tue, May 14, 2013 at 2:02 PM, Eugene Grosbein wrote: > > I've needed this feature several years ago so I made a patch for igb(4) and em(4) drivers. > The patch introduces new per-interface sysctls with default zero values: > > dev.em.X.down_disables_link > dev.igb.X.down.disables_link > > With this patch, sysctl dev.em.0.down_disables_link=1 makes "ifconfig em0 down" bring link down. > For LACP mode this feature is very useful as it makes LACP peer reconfigure itself quickly. > Great ! but what about adding a generic ifconfig mediaopt option in place of adding another new sysctl ? Something like "poweroff", "linkdown" or your "disablelink" as example. Because with this kind of sysctl values we can imagine a non-homogeneous future: We have already this problem with flow-control on em(4). The sysctl option for configuring flowcontrol on em(4) (no idea how to configure it with other drivers) are: - dev.em.0.fc (if chipset depends of if_em.c) - dev.em.0.flow_control (if chipset depends of if_lem.c) => By using ifconfig like "ifconfig INTERFACE mediaopt flowcontrol off|rx|tx|full" we could prevent different sysctl names between all NIC drivers. Regards, Olivier From owner-freebsd-net@FreeBSD.ORG Tue May 14 20:03: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 11737C84 for ; Tue, 14 May 2013 20:03:33 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by mx1.freebsd.org (Postfix) with ESMTP id 9BF61886 for ; Tue, 14 May 2013 20:03:32 +0000 (UTC) Received: by mail-wg0-f54.google.com with SMTP id x12so842366wgg.21 for ; Tue, 14 May 2013 13:03:31 -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=BjRKpvPIlxIoBMeBL/vkC+YjdgMwHhKLHa8lV7vdHLo=; b=kzUGpiIgavDN948BHNwcXW9oYz6P1mfVcz5REmocUglRKB813y7I6+I78UoVCLJZVC im8ipziO5kGYQMYHdkD2jE97ScldkqNFEuhcanUnC7bjaJkBsgFkEK8pUAefzW4Am7iE UuZhkpJOPF/vu0sW41Cj7YCFD+XfDdISE91OHEAsu4eIlkhB3BoQadiHhIHNP/4ZxgsX VG5fxF6XaoZ8slSRFmka7lYQ5g9xxaVEsUJXXb807cyN7S4P4RDOdzMTkhi5vsr37/MD VSw3FGfAox0RnSpmdOQ0S4Ktd4c/QAO1iVjWb5FUsPXPHdk7/nqR5oTijBJzO9BmSOmc OzOg== MIME-Version: 1.0 X-Received: by 10.181.13.42 with SMTP id ev10mr2877383wid.1.1368561811667; Tue, 14 May 2013 13:03:31 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.58.138 with HTTP; Tue, 14 May 2013 13:03:31 -0700 (PDT) In-Reply-To: References: <20130124195056.GB1410@funkthat.com> <519227E2.2090801@rdtc.ru> Date: Tue, 14 May 2013 13:03:31 -0700 X-Google-Sender-Auth: 6CWbaBaJJS7hEd0WzrvfDwb6hGU Message-ID: Subject: Re: how to completely makes an interface down? From: Adrian Chadd To: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: h bagade , "freebsd-net@freebsd.org" , John-Mark Gurney , Eugene Grosbein , 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: Tue, 14 May 2013 20:03:33 -0000 ... we have flow-control in ifconfig, don't we? On 14 May 2013 11:42, Olivier Cochard-Labb=E9 wrote: > On Tue, May 14, 2013 at 2:02 PM, Eugene Grosbein wrot= e: >> >> I've needed this feature several years ago so I made a patch for igb(4) = and em(4) drivers. >> The patch introduces new per-interface sysctls with default zero values: >> >> dev.em.X.down_disables_link >> dev.igb.X.down.disables_link >> >> With this patch, sysctl dev.em.0.down_disables_link=3D1 makes "ifconfig = em0 down" bring link down. >> For LACP mode this feature is very useful as it makes LACP peer reconfig= ure itself quickly. >> > > Great ! > > but what about adding a generic ifconfig mediaopt option in place of > adding another new sysctl ? > Something like "poweroff", "linkdown" or your "disablelink" as example. > > Because with this kind of sysctl values we can imagine a > non-homogeneous future: We have already this problem with flow-control > on em(4). > The sysctl option for configuring flowcontrol on em(4) (no idea how to > configure it with other drivers) are: > - dev.em.0.fc (if chipset depends of if_em.c) > - dev.em.0.flow_control (if chipset depends of if_lem.c) > > =3D> By using ifconfig like "ifconfig INTERFACE mediaopt flowcontrol > off|rx|tx|full" we could prevent different sysctl names between all > NIC drivers. > > Regards, > > Olivier > _______________________________________________ > 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 May 14 21:11: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 BE1F88C9 for ; Tue, 14 May 2013 21:11:27 +0000 (UTC) (envelope-from pzkordus@gmail.com) Received: from mail-ia0-x242.google.com (mail-ia0-x242.google.com [IPv6:2607:f8b0:4001:c02::242]) by mx1.freebsd.org (Postfix) with ESMTP id 967B7D6E for ; Tue, 14 May 2013 21:11:27 +0000 (UTC) Received: by mail-ia0-f194.google.com with SMTP id r13so200845iar.1 for ; Tue, 14 May 2013 14:11:27 -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=xFHxnn1IpsRjVaMCVkRr2/A4yLkVhh6rZjQmuGs6rw0=; b=wzZBvtpIjOqynNrph3et0+E65yKX/S9VNMFF8DM0DwLyT92VgCOnmh+j+Aszxu3t5k KHFBIwPPfR6/s2fakJgSaZmJ8qyTR26rmdD/jt0N4BoTQR6A273pFjgprtCyitzDJiGc C+x3nerPwZHM73O1xTk/CVqdydEISLXFYQvrW6FpNJovaZNx63Jxo3eZePDiqMv18SFO l00yUGrP/FcHrbG/pKj7qVXLn1oP6au+8Xzhnuc3BonmUX/yVHfBd0ZnZe0lcRmd0CL7 OwjSmxjp71WhicGOR1IvP1SQY7uPdjjwv0rWXzeqqHY8mPtHK3gNin4Ws+tz9oSqw67V SOzg== MIME-Version: 1.0 X-Received: by 10.42.66.140 with SMTP id p12mr18212630ici.15.1368565887259; Tue, 14 May 2013 14:11:27 -0700 (PDT) Received: by 10.50.25.164 with HTTP; Tue, 14 May 2013 14:11:27 -0700 (PDT) Date: Tue, 14 May 2013 17:11:27 -0400 Message-ID: Subject: dangling pointer off rn_mklist From: Ping Kordus To: freebsd-net@freebsd.org 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: Tue, 14 May 2013 21:11:27 -0000 Hi, We are seeing a dangling pointer off rn_mklist, this happened in the following condition. 1. a RNF_NORMAL flagged element on an internal node's rn_mklist is pointing to a child leaf route say route A via rm_rmu.rmu_leaf. 2. a dup route B of route A is added and becomes the head of rn_dupedkey 3. Route A is deleted. As route A is no longer at the head of the rn_dupedkey, MPATH code simply unlinks it without traversing parent to clean up the pointer off the parent's rn_mklist. Below is the GDB trace indicating route state after step 2. Route A:0xffffff000beb8410 Route B:0xffffff000c7c55b0 internal node:0xffffff000beb8850, its rn_mklist is traversed via GDB macro as below -----GDB macro snippet to traverse rn_mklist set $m = $arg0->rn_mklist while ($m !=0) if ($m->rm_flags & $RNF_NORMAL) set $mp=$m->rm_rmu.rmu_leaf printf "mlist: %p\n", $mp end set $m = $m->rm_mklist end --------------------------------------------------------------- kgdb-amd64-7.4-65) parent node 0xffffff000beb8850:mlist: 0xffffff000beb8410 right child rtentry node 0xffffff000beb8340: 172.31.21.52 link#1 U-H-------S------- 0 0 8232 lo0 0 left child rtentry node 0xffffff000c7c55b0 172.31.0.0 link#1 U----------------- 0 19 1500 e0a 0 => dup:0xffffff000beb8410 route entry = 0xffffff000beb8410 172.31.0.0 link#2 U----------------- 1 42 1500 e0b 0 So after step 3 where route A is deleted the routing table looks like below with a dangling pointer on parent's rn_mklist parent node 0xffffff000beb8850:mlist: 0xffffff000beb8410 right child rtentry node 0xffffff000beb8340: 172.31.21.52 link#1 U-H-------S------- 0 0 8232 lo0 0 left child rtentry node 0xffffff000c7c55b0 172.31.0.0 link#1 U----------------- 0 19 1500 e0a 0 Did anybody else see the issue? It seems to us the correct patch would do 1. Everytime add to the head of the dupedkey list, update the parent mklist to point to the new head. 2.Everytime the head is deleted update the parent mklist to point to the new head. Thanks a lot for your help, Ping From owner-freebsd-net@FreeBSD.ORG Tue May 14 22:23:11 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 49418BC7; Tue, 14 May 2013 22:23:11 +0000 (UTC) (envelope-from hiren@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 22124264; Tue, 14 May 2013 22:23:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4EMNBjO054765; Tue, 14 May 2013 22:23:11 GMT (envelope-from hiren@freefall.freebsd.org) Received: (from hiren@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4EMNAhk054764; Tue, 14 May 2013 22:23:10 GMT (envelope-from hiren) Date: Tue, 14 May 2013 22:23:10 GMT Message-Id: <201305142223.r4EMNAhk054764@freefall.freebsd.org> To: hiren@FreeBSD.org, freebsd-net@FreeBSD.org, hiren@FreeBSD.org From: hiren@FreeBSD.org Subject: Re: bin/136994: [patch] ifconfig(8) print carp mac address 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, 14 May 2013 22:23:11 -0000 Synopsis: [patch] ifconfig(8) print carp mac address Responsible-Changed-From-To: freebsd-net->hiren Responsible-Changed-By: hiren Responsible-Changed-When: Tue May 14 22:22:56 UTC 2013 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=136994 From owner-freebsd-net@FreeBSD.ORG Wed May 15 05:04:41 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 2AEF3F05; Wed, 15 May 2013 05:04:41 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from mail1.ozon.ru (mx4.ozon.ru [194.186.179.140]) by mx1.freebsd.org (Postfix) with ESMTP id A3535A66; Wed, 15 May 2013 05:04:40 +0000 (UTC) Received: from intmail03msk.ozon (intmail03msk.ozon [10.18.18.171]) by mail1.ozon.ru (Postfix) with ESMTP id 251A671A5D2; Wed, 15 May 2013 09:04:39 +0400 (MSK) Received: from mail pickup service by intmail03msk.ozon with Microsoft SMTPSVC; Wed, 15 May 2013 09:04:19 +0400 Received: from intmail03msk.ozon ([10.18.18.171]) by intmail02msk.ozon with Microsoft SMTPSVC(6.0.3790.4675); Sun, 12 May 2013 12:56:23 +0400 Received: from mail1.ozon.ru ([194.186.179.140]) by intmail03msk.ozon with Microsoft SMTPSVC(6.0.3790.4675); Sun, 12 May 2013 12:02:37 +0400 Received: from localhost (localhost [127.0.0.1]) by mail1.ozon.ru (Postfix) with ESMTP id DE3BD71CB1F for ; Sun, 12 May 2013 04:58:53 +0400 (MSK) X-Virus-Scanned: amavisd-new at ozon.ru Received: from mail1.ozon.ru ([127.0.0.1]) by localhost (mx4.ozon.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0lZBkImiO5J for ; Sun, 12 May 2013 04:58:46 +0400 (MSK) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received-SPF: pass (freebsd.org: 8.8.178.116 is authorized to use 'owner-freebsd-bugs@freebsd.org' in 'mfrom' identity (mechanism 'ip4:8.8.178.116' matched)) receiver=mx4.ozon.ru; identity=mfrom; envelope-from="owner-freebsd-bugs@freebsd.org"; helo=mx2.freebsd.org; client-ip=8.8.178.116 Received: from mx2.freebsd.org (mx2.FreeBSD.org [8.8.178.116]) by mail1.ozon.ru (Postfix) with ESMTP id 071F271CB1D for ; Sun, 12 May 2013 04:58:45 +0400 (MSK) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id 02F601B27; Sun, 12 May 2013 00:58:45 +0000 (UTC) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by hub.freebsd.org (Postfix) with ESMTP id 007B3FFE; Sun, 12 May 2013 00:58:45 +0000 (UTC) (envelope-from owner-freebsd-bugs@freebsd.org) Delivered-To: freebsd-bugs@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 A13C3FB7; Sun, 12 May 2013 00:58:38 +0000 (UTC) (envelope-from linimon@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 798761DD; Sun, 12 May 2013 00:58:38 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4C0wcEa048119; Sun, 12 May 2013 00:58:38 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4C0wb8J048118; Sun, 12 May 2013 00:58:37 GMT (envelope-from linimon) Date: Sun, 12 May 2013 00:58:37 GMT Message-Id: <201305120058.r4C0wb8J048118@freefall.freebsd.org> To: slashwaves@yahoo.com, linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/178071: FreeBSD unable to recongize Kontron (Industrial Computer Source / ICS Advent) DM9601 Fast Ethernet Adapter X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: owner-freebsd-bugs@freebsd.org Sender: owner-freebsd-bugs@freebsd.org X-OriginalArrivalTime: 12 May 2013 08:02:37.0826 (UTC) FILETIME=[117ED620:01CE4EE7] X-BeenThere: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 05:04:41 -0000 Old Synopsis: Driver for Kontron (Industrial Computer Source / ICS Advent) DM9601 Fast Ethernet Adapter New Synopsis: FreeBSD unable to recongize Kontron (Industrial Computer Source / ICS Advent) DM9601 Fast Ethernet Adapter State-Changed-From-To: open->suspended State-Changed-By: linimon State-Changed-When: Sun May 12 00:57:29 UTC 2013 State-Changed-Why: Reclassify and assign. Mark suspended awaiting patches. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun May 12 00:57:29 UTC 2013 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=178071 _______________________________________________ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed May 15 12:25:06 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 8FC4FC34; Wed, 15 May 2013 12:25:06 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 1FCA48CE; Wed, 15 May 2013 12:25:05 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r4FCOvOR031392; Wed, 15 May 2013 16:24:57 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r4FCOvH4031391; Wed, 15 May 2013 16:24:57 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 15 May 2013 16:24:57 +0400 From: Gleb Smirnoff To: hiren@FreeBSD.org Subject: Re: bin/136994: [patch] ifconfig(8) print carp mac address Message-ID: <20130515122457.GM17164@FreeBSD.org> References: <201305142223.r4EMNAhk054764@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <201305142223.r4EMNAhk054764@freefall.freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) 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, 15 May 2013 12:25:06 -0000 On Tue, May 14, 2013 at 10:23:10PM +0000, hiren@FreeBSD.org wrote: h> Synopsis: [patch] ifconfig(8) print carp mac address h> h> Responsible-Changed-From-To: freebsd-net->hiren h> Responsible-Changed-By: hiren h> Responsible-Changed-When: Tue May 14 22:22:56 UTC 2013 h> Responsible-Changed-Why: h> Grab. Note that patch and entire idea isn't applicable to head branch. It might be applicable once we grow support for multiple l2 addresses on an ifnet. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Wed May 15 14:43: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 3B4D3885; Wed, 15 May 2013 14:43:20 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by mx1.freebsd.org (Postfix) with ESMTP id 138832D1; Wed, 15 May 2013 14:43:20 +0000 (UTC) Received: by mail-pa0-f50.google.com with SMTP id fb10so1555214pad.23 for ; Wed, 15 May 2013 07:43:19 -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=dVnGo7s+t9wQCNjMESIIcY+CzllXiqNAXenwMeUXqww=; b=Y2cxmdhhHqzOKscQc+lj/2jasYNoBWyUJDn0olwDHCMo4M4ynyRnC8x0IFK5hEymKy tzK5yxwCl/anZpvy+CiL06L6EiJcwqg5gWRb2yMLuCcmwLnsbtS9GyBsqAklGJq/GiEk aFsifNkxMSi0nN28guGztz4vHFGVGrXk2VZUCI780o5sLbd2/RWQAQat14SA5BFSQicE jqg5VfITttxm930FgiScEVcEbjOnpXy2FtrbVyWGH8hewLuwudVhzHjI/rr2CFvwrdyK F30iC/J9u9PAkePu5j067D27VU3oDKzO1pHaPW2oAS3Qq3lwPILZ1WCnaNcLmktxPBmI /I7w== MIME-Version: 1.0 X-Received: by 10.66.158.101 with SMTP id wt5mr14777287pab.8.1368628999144; Wed, 15 May 2013 07:43:19 -0700 (PDT) Received: by 10.70.67.195 with HTTP; Wed, 15 May 2013 07:43:18 -0700 (PDT) Received: by 10.70.67.195 with HTTP; Wed, 15 May 2013 07:43:18 -0700 (PDT) In-Reply-To: <5146121B.5080608@FreeBSD.org> References: <5146121B.5080608@FreeBSD.org> Date: Wed, 15 May 2013 17:43:18 +0300 Message-ID: Subject: Re: MPLS From: Sami Halabi To: "Alexander V. Chernikov" 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: Wed, 15 May 2013 14:43:20 -0000 Hi Alex, Any progress on mpls fbsd? Thanks in advance, Sami On Mar 17, 2013 8:57 PM, "Alexander V. Chernikov" wrote: > On 17.03.2013 13:20, Sami Halabi wrote: > >> any one? :) >> >> >> On Fri, Mar 15, 2013 at 6:28 PM, Sami Halabi wrote: >> >> Hi, >>> Are there ongoing job of mpls in freebsd? >>> I saw thd site http://freebsd.mpls.in for aboug a year now and I don't >>> see much progress. >>> >> Yep. It was frozen for a while. > Currently I'm working on it again. > > control plane code was heavily redesigned, see > http://bird.mpls.in/projects/**mpls-bird/repository/show?rev=**bird_mpls > > I have some working MPLS code on 8-S and I hope to create freebsd svn > branch with base MPLS support in 2-3 weeks. > > 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). > 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. > >> >>> Thanks in advance, >>> Sami >>> >>> >> >> >> > From owner-freebsd-net@FreeBSD.ORG Wed May 15 17:19:50 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 BAEA9254 for ; Wed, 15 May 2013 17:19:50 +0000 (UTC) (envelope-from prvs=184709d2bd=agave.spring@cadamericas.com) Received: from cadamericas.com (mail02.amotive.com [173.164.153.20]) by mx1.freebsd.org (Postfix) with ESMTP id 9D68BE23 for ; Wed, 15 May 2013 17:19:50 +0000 (UTC) Received: from agave.cadamericas.com ([64.183.139.162]) by amotive.com (mail02.amotive.com) (MDaemon PRO v13.0.2) with ESMTP id md50002059409.msg; Wed, 15 May 2013 10:19:49 -0700 X-Spam-Processed: mail02.amotive.com, Wed, 15 May 2013 10:19:49 -0700 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 64.183.139.162 X-Return-Path: prvs=184709d2bd=agave.spring@cadamericas.com X-Envelope-From: agave.spring@cadamericas.com X-MDaemon-Deliver-To: freebsd-net@freebsd.org Date: Wed, 15 May 2013 10:18:27 -0700 To: freebsd-net From: CAD Americas Subject: CAD Americas Training Day is Coming to San Jose Message-ID: X-Priority: 3 X-Mailer: PHPMailer 5.2.1 (http://code.google.com/a/apache-extras.org/p/phpmailer/) X-CampTrackID: 261f3fb5-d518-5ff3-145b-5193c3086262 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" 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 Reply-To: CAD Americas List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 17:19:50 -0000 TIME IS RUNNING OUT! Register for CAD Americas Training Days by MAY 7 and S= AVE!=0ACAD AMERICAS TRAINING DAYS ARRIVE IN YOUR AREA SOON Join us for this= one-day training event in your area. Whether your focus is Mechanical Desi= gn, Construction, BIM, Electrical Design or Plant Design, there will be ses= sions that will improve your productivity immediately!=0AJune 4June 6June 7= June 12June 13June 26 June 27=0A Cleveland Cincinnati Detroit Atlanta D= allas San Jose San_Bernardino =0ATAKE HOME NEW TOOLS AND TECHNIQUES THAT = WILL IMPROVE YOUR PERFORMANCE IMMEDIATELY=0A=0A=0A=0A=0ALynn AllenTechnical= Evangelist More =0ARobert GreenCAD Mgmt Expert More =0ASteve SchainAutoCAD= Expert More =0ATod StephensRevit Expert More =0AClick here to see current = session descriptions.Please note that sessions will vary by location =0ALea= rn from well-known industry instructors who will share best practices and t= rends, product tips and tricks, new features =E2=80=A6 and more.=0AImprove = your productivity with new techniques that you can put to work right away.= =0AMeet your peers and exchange ideas on how to best use the CAD tools you = have to meet the demands of your job.=0ATake a closer look at services and = technologies offered by resellers in your area.=0AREGISTER BY MAY 7TH AND S= AVERegister for=C2=A0a CAD Americas Training Day by May 7th and save.=0AEar= ly Bird Rate: $150 (Until May 7th)=0AStandard Rate: $195 (AFTER May 7th)=0A= Student/Faculty Rate: $95 (must present current student ID upon check-in at= registration)=0AREGISTER FOR CAD AMERICAS TRAINING TODAY!=0A=0A=0A=0A=0AJo= in us at=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=C2=A0INTERNATIONAL SPONSORS=0A= =0A=0A=C2=A0=C2=A0 =C2=A0=C2=A0 =0A=0AEDUCATION SPONSOR=0A=0A=0AMEDIA SPONS= ORS=0A=0A=C2=A0=0AThis email was sent to email address: freebsd-net@freebsd= .org Click here to Opt-Out=0A From owner-freebsd-net@FreeBSD.ORG Thu May 16 08:30:17 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 15F13F07 for ; Thu, 16 May 2013 08:30:17 +0000 (UTC) (envelope-from carlopmart@gmail.com) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by mx1.freebsd.org (Postfix) with ESMTP id AA78778B for ; Thu, 16 May 2013 08:30:16 +0000 (UTC) Received: by mail-we0-f174.google.com with SMTP id x53so2417361wes.19 for ; Thu, 16 May 2013 01:30:15 -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=jADUHKlZu77R7gHsyhSCzFIgj9hoCVj5GkjY9//GjrI=; b=mJBqmIYNoUBThr3+Swt/K1SlT0cCwSTbfQMGRp1sBXyJW6KXcvxB4BMSuFO7Qbw8sD 37s0YbDZKE5Agk4v22+lBilAfacRxQ2JIK4L2Z2KYCuEyMSOlewdi0oh/4Iw6QJeboCO JdnBQiWxhq2MSjDYNKX5Hqy3I6QWhsPI8ZGuFI0mnMFlES+SNdm0WLffOQDzxmL/4okI IJ3caIIRPr+GPljWgEApd/ElE2Bsm82Mn7FxMewuZM0aYpnFmMPxHgnp3STNEzJtZ7mB 7qI3CHPSrXhXDmTmc2TvF0XL4MAOyIvmSwAi5R6AP2PGXx/XkwfE3mPGc/aRvgkcHcds wXGQ== MIME-Version: 1.0 X-Received: by 10.180.185.207 with SMTP id fe15mr21908666wic.33.1368693015844; Thu, 16 May 2013 01:30:15 -0700 (PDT) Received: by 10.194.71.34 with HTTP; Thu, 16 May 2013 01:30:15 -0700 (PDT) Date: Thu, 16 May 2013 08:30:15 +0000 Message-ID: Subject: Applying filters to bridge interfaces From: "C. L. Martinez" To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 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, 16 May 2013 08:30:17 -0000 Hi all, Is it possible to apply filters (something like bpf does) to a bridge interfaces in FreeBSd 9.1? I have one bridge interface configured with span options. I would like to "filter" traffic that cross this bridge and redirect some traffic to one span port and another traffic to the other. For example: My bridge interfaces is configured like this: ifconfig_bridge0="addm em0 addm em1 span em3 span 4 up" I would like to redirect traffic that comes and arrives to/from IP 10.1.1.1 to span port in em3, and redirect only 'vlan' traffic to span port in em4 ... Is this possible?? Or is it a stupid question?? Thanks. From owner-freebsd-net@FreeBSD.ORG Thu May 16 11:11:47 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EA02A2C7 for ; Thu, 16 May 2013 11:11:47 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from ost.citrin.ru (ost.citrin.ru [193.169.234.215]) by mx1.freebsd.org (Postfix) with ESMTP id ABAC7EC7 for ; Thu, 16 May 2013 11:11:47 +0000 (UTC) Received: from citrin.office.vega.ru (citrin.office.vega.ru [10.100.124.49]) (Authenticated sender: citrin@citrin.ru) by ost.citrin.ru (Postfix) with ESMTPSA id 3C089CEA5FB for ; Thu, 16 May 2013 11:11:45 +0000 (UTC) Message-ID: <5194BEF0.5090809@citrin.ru> Date: Thu, 16 May 2013 15:11:44 +0400 From: Anton Yuzhaninov User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130409 Thunderbird/17.0.5 MIME-Version: 1.0 To: net@freebsd.org Subject: ifconfig media for ixgbe Content-Type: text/plain; charset=us-ascii; 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: Thu, 16 May 2013 11:11:48 -0000 I'm testing Intel 82599EB network adapter. Sometimes link is lost. 1. /usr/src/sys/dev/ixgbe/README said When 82599-based SFP+ devices are connected back to back, they should be set to the same Speed setting via Ethtool. Results may vary if you mix speed settings. But manual speed settings for ixgbe don't work under FreeBSD: # ifconfig -m ix0 ix0: flags=8843 metric 0 mtu 1500 options=407bb capabilities=1507bb ... skipped ... media: Ethernet autoselect (10Gbase-SR ) status: active supported media: media autoselect media 10Gbase-SR # ifconfig ix0 media 10Gbase-SR ifconfig: SIOCSIFMEDIA (media): Invalid argument And as I can see it is limited in driver: http://bxr.su/FreeBSD/sys/dev/ixgbe/ixgbe.c#1697 README file is outdated? 2. Link sometimes (but no always) lost aster starting /usr/src/tools/tools/netmap/pkt-gen Sometime link restorted after aboring pkt-gen, sometimes only after power off/on (ifconfig down/up don't help). Is this netmap related issue? From owner-freebsd-net@FreeBSD.ORG Thu May 16 11:56:06 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 D67FF89C for ; Thu, 16 May 2013 11:56:06 +0000 (UTC) (envelope-from julian@vps1.elischer.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 9E439E9 for ; Thu, 16 May 2013 11:56:06 +0000 (UTC) Received: from vps1.elischer.org (localhost [127.0.0.1]) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r4GBu0UI018201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 16 May 2013 04:56:00 -0700 (PDT) (envelope-from julian@vps1.elischer.org) Received: (from julian@localhost) by vps1.elischer.org (8.14.5/8.14.5/Submit) id r4GBu0HQ018200 for freebsd-net@freebsd.org; Thu, 16 May 2013 04:56:00 -0700 (PDT) (envelope-from julian) Date: Thu, 16 May 2013 04:56:00 -0700 (PDT) From: Julian Elischer Message-Id: <201305161156.r4GBu0HQ018200@vps1.elischer.org> To: freebsd-net@freebsd.org Subject: more FIBs patch for review 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, 16 May 2013 11:56:06 -0000 Index: sys/conf/NOTES =================================================================== --- sys/conf/NOTES (revision 250696) +++ sys/conf/NOTES (working copy) @@ -571,7 +571,8 @@ options INET #Internet communications protocols options INET6 #IPv6 communications protocols -options ROUTETABLES=2 # max 16. 1 is back compatible. +options ROUTETABLES=2 # allocated fibs up to 65536. default is 1. + # but that would be a bad idea as they are large. options TCP_OFFLOAD # TCP offload support. Index: sys/net/route.c =================================================================== --- sys/net/route.c (revision 250696) +++ sys/net/route.c (working copy) @@ -68,8 +68,7 @@ #include -/* We use 4 bits in the mbuf flags, thus we are limited to 16 FIBS. */ -#define RT_MAXFIBS 16 +#define RT_MAXFIBS UINT16_MAX /* Kernel config default option. */ #ifdef ROUTETABLES @@ -86,17 +85,10 @@ #define RT_NUMFIBS 1 #endif +/* This is read-only.. */ u_int rt_numfibs = RT_NUMFIBS; SYSCTL_UINT(_net, OID_AUTO, fibs, CTLFLAG_RD, &rt_numfibs, 0, ""); -/* - * Allow the boot code to allow LESS than RT_MAXFIBS to be used. - * We can't do more because storage is statically allocated for now. - * (for compatibility reasons.. this will change. When this changes, code should - * be refactored to protocol independent parts and protocol dependent parts, - * probably hanging of domain(9) specific storage to not need the full - * fib * af RNH allocation etc. but allow tuning the number of tables per - * address family). - */ +/* and this can be set too big but will be fixed before it is used */ TUNABLE_INT("net.fibs", &rt_numfibs); /* Index: sys/netinet6/ip6_output.c =================================================================== --- sys/netinet6/ip6_output.c (revision 250696) +++ sys/netinet6/ip6_output.c (working copy) @@ -1126,7 +1126,7 @@ IP6STAT_INC(ip6s_odropped); goto sendorfree; } - m->m_flags = m0->m_flags & M_COPYFLAGS; /* incl. FIB */ + m->m_flags = m0->m_flags & M_COPYFLAGS; *mnext = m; mnext = &m->m_nextpkt; m->m_data += max_linkhdr; @@ -1152,6 +1152,7 @@ } m_cat(m, m_frgpart); m->m_pkthdr.len = len + hlen + sizeof(*ip6f); + m->m_pkthdr.fibnum = m0->m_pkthdr.fibnum; m->m_pkthdr.rcvif = NULL; ip6f->ip6f_reserved = 0; ip6f->ip6f_ident = id; Index: sys/sys/mbuf.h =================================================================== --- sys/sys/mbuf.h (revision 250696) +++ sys/sys/mbuf.h (working copy) @@ -129,6 +129,8 @@ u_int16_t vt_vtag; /* Ethernet 802.1p+q vlan tag */ u_int16_t vt_nrecs; /* # of IGMPv3 records in this chain */ } PH_vt; + u_int16_t fibnum; /* this packet should use this fib */ + u_int16_t pad2; /* align to 32 bits */ SLIST_HEAD(packet_tags, m_tag) tags; /* list of packet tags */ }; #define ether_vtag PH_vt.vt_vtag @@ -171,6 +173,7 @@ #define m_type m_hdr.mh_type #define m_flags m_hdr.mh_flags #define m_nextpkt m_hdr.mh_nextpkt +#define m_fibnum m_hdr.mh_nextpkt #define m_act m_nextpkt #define m_pkthdr M_dat.MH.MH_pkthdr #define m_ext M_dat.MH.MH_dat.MH_ext @@ -205,12 +208,6 @@ #define M_FLOWID 0x00400000 /* deprecated: flowid is valid */ #define M_HASHTYPEBITS 0x0F000000 /* mask of bits holding flowid hash type */ -/* - * For RELENG_{6,7} steal these flags for limited multiple routing table - * support. In RELENG_8 and beyond, use just one flag and a tag. - */ -#define M_FIB 0xF0000000 /* steal some bits to store fib number. */ - #define M_NOTIFICATION M_PROTO5 /* SCTP notification */ /* @@ -258,7 +255,7 @@ */ #define M_COPYFLAGS \ (M_PKTHDR|M_EOR|M_RDONLY|M_PROTOFLAGS|M_SKIP_FIREWALL|M_BCAST|M_MCAST|\ - M_FRAG|M_FIRSTFRAG|M_LASTFRAG|M_VLANTAG|M_PROMISC|M_FIB|M_HASHTYPEBITS) + M_FRAG|M_FIRSTFRAG|M_LASTFRAG|M_VLANTAG|M_PROMISC|M_HASHTYPEBITS) /* * External buffer types: identify ext_buf type. @@ -1010,17 +1007,18 @@ m_tag_locate(m, MTAG_ABI_COMPAT, type, start)); } -/* XXX temporary FIB methods probably eventually use tags.*/ -#define M_FIBSHIFT 28 -#define M_FIBMASK 0x0F +static int inline +rt_m_getfib(struct mbuf *m) +{ + KASSERT(m->m_flags & M_EXT , ("attempt to set FIB on non header mbuf")); + return (m->m_pkthdr.fibnum); +} -/* get the fib from an mbuf and if it is not set, return the default */ -#define M_GETFIB(_m) \ - ((((_m)->m_flags & M_FIB) >> M_FIBSHIFT) & M_FIBMASK) +#define M_GETFIB(_m) rt_m_getfib(_m) #define M_SETFIB(_m, _fib) do { \ - _m->m_flags &= ~M_FIB; \ - _m->m_flags |= (((_fib) << M_FIBSHIFT) & M_FIB); \ + KASSERT((_m)->m_flags & M_EXT, ("No FIB on non header mbuf")); \ + ((_m)->m_pkthdr.fibnum) = (_fib); \ } while (0) #endif /* _KERNEL */ From owner-freebsd-net@FreeBSD.ORG Fri May 17 21:57:43 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 67F7E6AE; Fri, 17 May 2013 21:57:43 +0000 (UTC) (envelope-from linimon@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 41FC2DE6; Fri, 17 May 2013 21:57:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4HLvhmp020751; Fri, 17 May 2013 21:57:43 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4HLvhwX020750; Fri, 17 May 2013 21:57:43 GMT (envelope-from linimon) Date: Fri, 17 May 2013 21:57:43 GMT Message-Id: <201305172157.r4HLvhwX020750@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/178612: [run] kernel panic due the problems with run driver 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, 17 May 2013 21:57:43 -0000 Synopsis: [run] kernel panic due the problems with run driver Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri May 17 21:56:47 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=178612 From owner-freebsd-net@FreeBSD.ORG Fri May 17 22:27:32 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 27A2CEA3 for ; Fri, 17 May 2013 22:27:32 +0000 (UTC) (envelope-from laurie_jennings_1977@yahoo.com) Received: from nm18-vm1.bullet.mail.ne1.yahoo.com (nm18-vm1.bullet.mail.ne1.yahoo.com [98.138.91.64]) by mx1.freebsd.org (Postfix) with ESMTP id CA69E186 for ; Fri, 17 May 2013 22:27:31 +0000 (UTC) Received: from [98.138.90.56] by nm18.bullet.mail.ne1.yahoo.com with NNFMP; 17 May 2013 22:25:42 -0000 Received: from [98.138.226.167] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 17 May 2013 22:25:42 -0000 Received: from [127.0.0.1] by omp1068.mail.ne1.yahoo.com with NNFMP; 17 May 2013 22:25:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 804200.47930.bm@omp1068.mail.ne1.yahoo.com Received: (qmail 54320 invoked by uid 60001); 17 May 2013 22:25:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1368829542; bh=QPvuYeUC6tSdfUtokpSPE2PyatbceDGSdl4MeQ/kn9k=; 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=ByoH+D+HPiRdyjJ9tQquGiUJXIuqtiU671SK1KiLgNnA0xfZBlm5ssBb96j7VYZAo1MfHD+WuF/1RegEAS7rEaROVaNELfCVcPTJBBLzOO1qfR8Xv12nx33MUq+Zodl7EHPqrSHF70a6E38wBRHQ9chxflK9TVs1g5J8QyJKxa8= 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=ERhQEsgIs5LPzdfC1YPev9+gOBlb04o93kOnHX2RbKB6bIV4NHyiWIRnufdwOkKjoDROX6nzGMxXb9SYwV418QMcD/yb+DJx20unPCMWS4vOoyALEjXgpzTbN7Kd9YV73CzXcV+AI2lt/jKnpSdbfXfK2keSDvEeFHV7h9KBsdI=; X-YMail-OSG: 9S3FdNYVM1np7LOs9VJvWm7BPOdl7jG13Jtc037SDTrVB1p i3VBrRiiBuzrvc5qpbIcHt6xaWzG9tZB9Y13wTXwxD4uiV0eWkEqNrL8OHFE yvh1za0NlP6YR6cPQ2Xbi18uFF6QgfBCrkpejVsadVjOmaduDFD3wULOy0nc 9scJVrVyGBXmLgvu0tggVrF8TDa5J5Kr2IXHwK10G2EJ_Oy4r8Xnf3PMq1SV feHdQDzwQ.RpsfmkEFxbtUA.pNC0PFy_MRJbKcY1CDp5WLa1IR5bAYNmjcnH iE5tDuoS8DuMpRnMT6qwB2O_QqQq_.KTIbbbsRdm5LBJbLuXUoDqhaSuA4zH eu3E_8XM.G_9PLPl9VmaoZMQJSskCm6eynJdtbBqFA4_VHroHCxC_oZPC_wW tVFI143OlHYb8XuJH7aAhpj3yoZ_M3BuWti.5nIcgQmFVSBW4Jqk8NdDYgdc yuxBY3wh_N_8G0.IwsGdsUpFRhJYF78QY_oEi32VldXnToTNYP5TG9UGKjC6 7I6sg6Hup9YQ98.SU9hzNLXOn9gSha4Ee_Pd7961IPpU- Received: from [98.203.118.124] by web125804.mail.ne1.yahoo.com via HTTP; Fri, 17 May 2013 15:25:42 PDT X-Rocket-MIMEInfo: 002.001, RGlkIHlvdSBnZXQgdG8gY29tbWl0IHRoYXQgbmV3IGNvZGUgeWV0Pw0KTGF1cmllDQoNCi0tLSBPbiBTYXQsIDUvNC8xMywgSmFjayBWb2dlbCA8amZ2b2dlbEBnbWFpbC5jb20.IHdyb3RlOg0KDQpGcm9tOiBKYWNrIFZvZ2VsIDxqZnZvZ2VsQGdtYWlsLmNvbT4NClN1YmplY3Q6IFJlOiBJcyB0aGVyZSBhbnkgd2F5IHRvIGxpbWl0IHRoZSBhbW91bnQgb2YgZGF0YSBpbiBhbiBtYnVmIGNoYWluIHN1Ym1pdHRlZCB0byBhIGRyaXZlcj8NClRvOiAiUmljaGFyZCBTaGFycGUiIDxyZWFscmljaGFyZHNoYXJwZUABMAEBAQE- X-Mailer: YahooMailClassic/15.1.8 YahooMailWebService/0.8.142.542 Message-ID: <1368829542.53502.YahooMailClassic@web125804.mail.ne1.yahoo.com> Date: Fri, 17 May 2013 15:25:42 -0700 (PDT) From: Laurie Jennings Subject: Re: Is there any way to limit the amount of data in an mbuf chain submitted to a driver? To: Richard Sharpe , Jack Vogel In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Net , Adrian Chadd 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, 17 May 2013 22:27:32 -0000 Did you get to commit that new code yet? Laurie --- On Sat, 5/4/13, Jack Vogel wrote: From: Jack Vogel Subject: Re: Is there any way to limit the amount of data in an mbuf chain = submitted to a driver? To: "Richard Sharpe" Cc: "FreeBSD Net" , "Adrian Chadd" Date: Saturday, May 4, 2013, 2:18 PM Ahh, Twinville, new hardware :)=C2=A0 The version at the tip is 2.5.8 and I= am working on version 2.5.12 internally that I hope to commit next week... so your version is "a bit old" :) I would do some testing on newer code. Jack On Sat, May 4, 2013 at 1:54 PM, Richard Sharpe wrote: > On Sat, May 4, 2013 at 1:41 PM, Jack Vogel wrote: > > If you don't use TSO you will hurt your TX performance significantly fr= om > > the tests that I've run. What exactly is the device you are using, I > don't > > have the source in front of me now, but I'm almost sure that the limit = is > > not 64K but 256K, or are you using some ancient version of the driver? > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0ix0 pnpinfo vendor=3D= 0x8086 device=3D0x1528 subvendor=3D0x8086 > subdevice=3D0x0001 class=3D0x020000 at slot=3D0 function=3D0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0ix1 pnpinfo vendor=3D= 0x8086 device=3D0x1528 subvendor=3D0x8086 > subdevice=3D0x0001 class=3D0x020000 at slot=3D0 function=3D1 > > The version calls itself ixgbe-2.4.4 ... > > Hmmm, copyright is 2001-2010 ... so perhaps a bit old. > > > Jack > > > > > > > > On Sat, May 4, 2013 at 1:30 PM, Richard Sharpe < > realrichardsharpe@gmail.com> > > wrote: > >> > >> On Sat, May 4, 2013 at 10:39 AM, Adrian Chadd > wrote: > >> > On 4 May 2013 06:52, Richard Sharpe > wrote: > >> >> Hi folks, > >> >> > >> >> I understand better why I am seeing EINVAL intermittently when > sending > >> >> data from Samba via SMB2. > >> >> > >> >> The ixgbe driver, for TSO reasons, limits the amount of data that c= an > >> >> be DMA'd to 65535 bytes. It returns EINVAL for any mbuf chain large= r > >> >> than that. > >> >> > >> >> The SO_SNDBUF for that socket is set to 131972. Mostly there is les= s > >> >> than 64kiB of space available, so that is all TCP etc can put into > the > >> >> socket in one chain of mbufs. However, every now and then there is > >> >> more than 65535 bytes available in the socket buffers, and we have = an > >> >> SMB packet that is larger than 65535 bytes, and we get hit. > >> >> > >> >> To confirm this I am going to set SO_SNDBUF back to the default of > >> >> 65536 and test again. My repros are very reliable. > >> >> > >> >> However, I wondered if my only way around this if I want to continu= e > >> >> to use SO_SNDBUF sizes larger than 65536 is to fragment large mbuf > >> >> chains in the driver? > >> > > >> > Hm, is this is a problem without TSO? > >> > >> We are using the card without TSO, so I am thinking of changing that > >> limit to 131072 and retesting. > >> > >> I am currently testing with SO_SNDBUF=3D32768 and have not hit the > problem. > >> > >> > Is the problem that the NIC can't handle a frame that big, or a buff= er > >> > that big? > >> > Ie - if you handed the hardware two descriptors of 64k each, for the > >> > same IP datagram, will it complain? > >> > >> I can't find any documentation, but it seems that with TSO it cannot > >> handle a frame that big. Actually, since we are not using TSO, there > >> really should not be a problem with larger frames. > >> > >> > Or do you need to break it up into two separate IP datagrams, facing > >> > the driver, with a maximum size of 64k each? > >> > >> Not sure, but it looks like we need to do that. > >> > >> > >> -- > >> Regards, > >> Richard Sharpe > >> (=E4=BD=95=E4=BB=A5=E8=A7=A3=E6=86=82=EF=BC=9F=E5=94=AF=E6=9C=89=E6=9D= =9C=E5=BA=B7=E3=80=82--=E6=9B=B9=E6=93=8D) > >> _______________________________________________ > >> 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" > > > > > > > > -- > Regards, > Richard Sharpe > (=E4=BD=95=E4=BB=A5=E8=A7=A3=E6=86=82=EF=BC=9F=E5=94=AF=E6=9C=89=E6=9D=9C= =E5=BA=B7=E3=80=82--=E6=9B=B9=E6=93=8D) > _______________________________________________ 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 May 17 22:32:24 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 B60A91DA; Fri, 17 May 2013 22:32:24 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) by mx1.freebsd.org (Postfix) with ESMTP id 645881D5; Fri, 17 May 2013 22:32:24 +0000 (UTC) Received: by mail-vc0-f169.google.com with SMTP id kw10so4190192vcb.0 for ; Fri, 17 May 2013 15:32:18 -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=wGWLZW7klgyeOeeYtiW3eCdFm+wF+xiUw6DiLmL6LEw=; b=Nl0eSo+R4cMrqx4I/RP7qCJArll8p97SCe67UNNhi6BBCX7Pl0tl+OV4LCZ7Uh1m9o RtIb7DOjHW2qYwA74TUI821ZSz3puLLjW2OdfybkUD8uOfGhqwT1SPE6PnA6poSo9TDz +W0hDx91KGGpDZcFMjLGCTLI/dmlws08Eba45XTbHfAvQVs6v+CqAcALyxpmZbZH1fiI xrct/qB8cS2zwfx+RuEIJlEJQgyUkQORCIL+oE5hOXtJRE34XCuWxhGWltXG7E3bfH4j xt+jsGjXSyI2Huq1/x/oR/ldhCjZ3W2f7Cv9ghf0/7kLPJbT9Pi3zkpqKL34ZtBcPE8E AyTA== MIME-Version: 1.0 X-Received: by 10.58.247.130 with SMTP id ye2mr30703522vec.35.1368829938120; Fri, 17 May 2013 15:32:18 -0700 (PDT) Received: by 10.220.55.143 with HTTP; Fri, 17 May 2013 15:32:17 -0700 (PDT) In-Reply-To: <1368829542.53502.YahooMailClassic@web125804.mail.ne1.yahoo.com> References: <1368829542.53502.YahooMailClassic@web125804.mail.ne1.yahoo.com> Date: Fri, 17 May 2013 15:32:17 -0700 Message-ID: Subject: Re: Is there any way to limit the amount of data in an mbuf chain submitted to a driver? From: Jack Vogel To: Laurie Jennings Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Net , Adrian Chadd , Richard Sharpe 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, 17 May 2013 22:32:24 -0000 No Laurie, I ran into an issue that I needed to resolve, and then my validation engineer went out of town a couple days. Should be early next week. Jack On Fri, May 17, 2013 at 3:25 PM, Laurie Jennings < laurie_jennings_1977@yahoo.com> wrote: > Did you get to commit that new code yet? > > Laurie > > --- On *Sat, 5/4/13, Jack Vogel * wrote: > > > From: Jack Vogel > Subject: Re: Is there any way to limit the amount of data in an mbuf chai= n > submitted to a driver? > To: "Richard Sharpe" > Cc: "FreeBSD Net" , "Adrian Chadd" < > adrian@freebsd.org> > Date: Saturday, May 4, 2013, 2:18 PM > > > Ahh, Twinville, new hardware :) The version at the tip is 2.5.8 and I am > working on version 2.5.12 internally that I hope to commit next week... > so your version is "a bit old" :) I would do some testing on newer code. > > Jack > > > > On Sat, May 4, 2013 at 1:54 PM, Richard Sharpe > > >wrote: > > > On Sat, May 4, 2013 at 1:41 PM, Jack Vogel > > wrote: > > > If you don't use TSO you will hurt your TX performance significantly > from > > > the tests that I've run. What exactly is the device you are using, I > > don't > > > have the source in front of me now, but I'm almost sure that the limi= t > is > > > not 64K but 256K, or are you using some ancient version of the driver= ? > > > > ix0 pnpinfo vendor=3D0x8086 device=3D0x1528 subvendor=3D0x8= 086 > > subdevice=3D0x0001 class=3D0x020000 at slot=3D0 function=3D0 > > ix1 pnpinfo vendor=3D0x8086 device=3D0x1528 subvendor=3D0x8= 086 > > subdevice=3D0x0001 class=3D0x020000 at slot=3D0 function=3D1 > > > > The version calls itself ixgbe-2.4.4 ... > > > > Hmmm, copyright is 2001-2010 ... so perhaps a bit old. > > > > > Jack > > > > > > > > > > > > On Sat, May 4, 2013 at 1:30 PM, Richard Sharpe < > > realrichardsharpe@gmail.com > > > > > wrote: > > >> > > >> On Sat, May 4, 2013 at 10:39 AM, Adrian Chadd > > > > wrote: > > >> > On 4 May 2013 06:52, Richard Sharpe > > > > wrote: > > >> >> Hi folks, > > >> >> > > >> >> I understand better why I am seeing EINVAL intermittently when > > sending > > >> >> data from Samba via SMB2. > > >> >> > > >> >> The ixgbe driver, for TSO reasons, limits the amount of data that > can > > >> >> be DMA'd to 65535 bytes. It returns EINVAL for any mbuf chain > larger > > >> >> than that. > > >> >> > > >> >> The SO_SNDBUF for that socket is set to 131972. Mostly there is > less > > >> >> than 64kiB of space available, so that is all TCP etc can put int= o > > the > > >> >> socket in one chain of mbufs. However, every now and then there i= s > > >> >> more than 65535 bytes available in the socket buffers, and we hav= e > an > > >> >> SMB packet that is larger than 65535 bytes, and we get hit. > > >> >> > > >> >> To confirm this I am going to set SO_SNDBUF back to the default o= f > > >> >> 65536 and test again. My repros are very reliable. > > >> >> > > >> >> However, I wondered if my only way around this if I want to > continue > > >> >> to use SO_SNDBUF sizes larger than 65536 is to fragment large mbu= f > > >> >> chains in the driver? > > >> > > > >> > Hm, is this is a problem without TSO? > > >> > > >> We are using the card without TSO, so I am thinking of changing that > > >> limit to 131072 and retesting. > > >> > > >> I am currently testing with SO_SNDBUF=3D32768 and have not hit the > > problem. > > >> > > >> > Is the problem that the NIC can't handle a frame that big, or a > buffer > > >> > that big? > > >> > Ie - if you handed the hardware two descriptors of 64k each, for t= he > > >> > same IP datagram, will it complain? > > >> > > >> I can't find any documentation, but it seems that with TSO it cannot > > >> handle a frame that big. Actually, since we are not using TSO, there > > >> really should not be a problem with larger frames. > > >> > > >> > Or do you need to break it up into two separate IP datagrams, faci= ng > > >> > the driver, with a maximum size of 64k each? > > >> > > >> Not sure, but it looks like we need to do that. > > >> > > >> > > >> -- > > >> Regards, > > >> Richard Sharpe > > >> (=A6=F3=A5H=B8=D1=BC~=A1H=B0=DF=A6=B3=A7=F9=B1d=A1C--=B1=E4=BE=DE) > > >> _______________________________________________ > > >> freebsd-net@freebsd.orgmailing list > > >> http://lists.freebsd.org/mailman/listinfo/freebsd-net > > >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.or= g > " > > > > > > > > > > > > > > -- > > Regards, > > Richard Sharpe > > (=A6=F3=A5H=B8=D1=BC~=A1H=B0=DF=A6=B3=A7=F9=B1d=A1C--=B1=E4=BE=DE) > > > _______________________________________________ > freebsd-net@freebsd.org m= ailing 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 Sat May 18 12:11: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 5C6E69AC for ; Sat, 18 May 2013 12:11:25 +0000 (UTC) (envelope-from laurie_jennings_1977@yahoo.com) Received: from nm22-vm2.bullet.mail.ne1.yahoo.com (nm22-vm2.bullet.mail.ne1.yahoo.com [98.138.91.210]) by mx1.freebsd.org (Postfix) with ESMTP id DA8DEEA7 for ; Sat, 18 May 2013 12:11:24 +0000 (UTC) Received: from [98.138.226.180] by nm22.bullet.mail.ne1.yahoo.com with NNFMP; 18 May 2013 12:08:42 -0000 Received: from [98.138.89.169] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 18 May 2013 12:08:42 -0000 Received: from [127.0.0.1] by omp1025.mail.ne1.yahoo.com with NNFMP; 18 May 2013 12:08:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 813294.86267.bm@omp1025.mail.ne1.yahoo.com Received: (qmail 70265 invoked by uid 60001); 18 May 2013 12:08:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1368878922; bh=2OWRjfVN9nSoNJ2KUVouylMvxi1OWDQEaOkVtzO9NVs=; 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=MP7VsHhzPEAZnkC9Qrwab8BxjG3DqX7RkTU4dTORRpK2DUN5k3slKxmpjhJ7o99NpogUqE3nvPkOiQGrt+8sk4eMCkbaALbhe7MUQPjNjaSNIKl7YBfx5SMJ5vc8cRC2/kzCa30twl0SSTqw2TRtpcK4cqYmbNx1lNBU7TmP+04= 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=s4bHXom68wNIVUSIO6llbaPl66/UOCR3SK0nUn5WUBDd4kFxmzC3p3x4/fZNP55krZri+ZoYxGB1v2Iejta4ZDEuShzBuF62CEUQ/wXsjwVvwBnIDdho28SD2Bkzw99rmPgg70G9ZLZwjVNv6lVK1CtvZ4Q3mWO/bJeQ1oGS5as=; X-YMail-OSG: yc2lvggVM1mff1KlpKDJIsdok02wl.wUQMByoAjtEWnorG3 b0HiSGWP6ZTKp49O3iHe.PGGGrG4rAz19fFXH6NnZcC6LJZYqjquyjHkAccD j4FnZxd9tPx2FcHK5kwJk_2UlKZuHlFZSDfLPEWH_gD3PLJhVmGxLNoDKSix HqxTh_KCpqmeDgYb80S0MRqucHGCi2LGWJxUr9.NEFnstsc.7cwkHHg_5o.n AGszEJLHPWNofEGgX77wTBtYi8GZq8f0kIOagpqFYR7ei_iceNgsKRdO1cEU NZCCX8cK0yZ0qHLr4k3J6PhiWqJ9WvRMvUXbA9de9vI15qftn63C9Ps6IpGy GzdT2HUWIzHo3zHZdJaOhC_89lv4eOGOpqm6T2Dj16zymo7sFqn0rYCR5Wac hJP8_Ee0TP4OJD4tTyjdH06dP.YNoMwroGGdtRVQULOjihxF8V2rUeUruyeS 9Vv0FV0I7Jh59k8kUxU8X.NPef4jfIdCg.TOH3Hfph80dFDDSj0ovGygjNQe Ai70KLLiabI9GVHwVsQus35Bs66RgrAhtA7h6zu9CuA-- Received: from [98.203.118.124] by web125801.mail.ne1.yahoo.com via HTTP; Sat, 18 May 2013 05:08:42 PDT X-Rocket-MIMEInfo: 002.001, Q2FuIHlvdSBvdXRsaW5lIHRoZSBjaGFuZ2VzPyBBbnl0aGluZyB3aXRoIHRoZSBnZW5lcmFsIHByb2Nlc3Npbmc_IEkgaGF2ZSB0byBtYWtlYSBjYXNlIHRvIGhvbGQgb2ZmIGEgZGVwbG95bWVudC4NCmFuZCB3aGF0IGhhcHBlbmVkIHRvIDksIDEwLCBhbmQgMTE_DQpMYXVyaWUNCg0KLS0tIE9uIEZyaSwgNS8xNy8xMywgSmFjayBWb2dlbCA8amZ2b2dlbEBnbWFpbC5jb20.IHdyb3RlOg0KDQpGcm9tOiBKYWNrIFZvZ2VsIDxqZnZvZ2VsQGdtYWlsLmNvbT4NClN1YmplY3Q6IFJlOiBJcyB0aGVyZSBhbnkgd2EBMAEBAQE- X-Mailer: YahooMailClassic/15.1.8 YahooMailWebService/0.8.142.542 Message-ID: <1368878922.70089.YahooMailClassic@web125801.mail.ne1.yahoo.com> Date: Sat, 18 May 2013 05:08:42 -0700 (PDT) From: Laurie Jennings Subject: Re: Is there any way to limit the amount of data in an mbuf chain submitted to a driver? To: Jack Vogel In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Sat, 18 May 2013 12:11:25 -0000 Can you outline the changes? Anything with the general processing? I have t= o makea case to hold off a deployment. and what happened to 9, 10, and 11? Laurie --- On Fri, 5/17/13, Jack Vogel wrote: From: Jack Vogel Subject: Re: Is there any way to limit the amount of data in an mbuf chain = submitted to a driver? To: "Laurie Jennings" Cc: "FreeBSD Net" , "Adrian Chadd" , "Richard Sharpe" Date: Friday, May 17, 2013, 3:32 PM No Laurie, I ran into an issue that I needed to resolve, and then my validation engineer went out of town a couple days. Should be early next week. Jack On Fri, May 17, 2013 at 3:25 PM, Laurie Jennings < laurie_jennings_1977@yahoo.com> wrote: > Did you get to commit that new code yet? > > Laurie > > --- On *Sat, 5/4/13, Jack Vogel * wrote: > > > From: Jack Vogel > Subject: Re: Is there any way to limit the amount of data in an mbuf chai= n > submitted to a driver? > To: "Richard Sharpe" > Cc: "FreeBSD Net" , "Adrian Chadd" < > adrian@freebsd.org> > Date: Saturday, May 4, 2013, 2:18 PM > > > Ahh, Twinville, new hardware :)=C2=A0 The version at the tip is 2.5.8 and= I am > working on version 2.5.12 internally that I hope to commit next week... > so your version is "a bit old" :) I would do some testing on newer code. > > Jack > > > > On Sat, May 4, 2013 at 1:54 PM, Richard Sharpe > > >wrote: > > > On Sat, May 4, 2013 at 1:41 PM, Jack Vogel > > wrote: > > > If you don't use TSO you will hurt your TX performance significantly > from > > > the tests that I've run. What exactly is the device you are using, I > > don't > > > have the source in front of me now, but I'm almost sure that the limi= t > is > > > not 64K but 256K, or are you using some ancient version of the driver= ? > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0ix0 pnpinfo vendor= =3D0x8086 device=3D0x1528 subvendor=3D0x8086 > > subdevice=3D0x0001 class=3D0x020000 at slot=3D0 function=3D0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0ix1 pnpinfo vendor= =3D0x8086 device=3D0x1528 subvendor=3D0x8086 > > subdevice=3D0x0001 class=3D0x020000 at slot=3D0 function=3D1 > > > > The version calls itself ixgbe-2.4.4 ... > > > > Hmmm, copyright is 2001-2010 ... so perhaps a bit old. > > > > > Jack > > > > > > > > > > > > On Sat, May 4, 2013 at 1:30 PM, Richard Sharpe < > > realrichardsharpe@gmail.com > > > > > wrote: > > >> > > >> On Sat, May 4, 2013 at 10:39 AM, Adrian Chadd > > > > wrote: > > >> > On 4 May 2013 06:52, Richard Sharpe > > > > wrote: > > >> >> Hi folks, > > >> >> > > >> >> I understand better why I am seeing EINVAL intermittently when > > sending > > >> >> data from Samba via SMB2. > > >> >> > > >> >> The ixgbe driver, for TSO reasons, limits the amount of data that > can > > >> >> be DMA'd to 65535 bytes. It returns EINVAL for any mbuf chain > larger > > >> >> than that. > > >> >> > > >> >> The SO_SNDBUF for that socket is set to 131972. Mostly there is > less > > >> >> than 64kiB of space available, so that is all TCP etc can put int= o > > the > > >> >> socket in one chain of mbufs. However, every now and then there i= s > > >> >> more than 65535 bytes available in the socket buffers, and we hav= e > an > > >> >> SMB packet that is larger than 65535 bytes, and we get hit. > > >> >> > > >> >> To confirm this I am going to set SO_SNDBUF back to the default o= f > > >> >> 65536 and test again. My repros are very reliable. > > >> >> > > >> >> However, I wondered if my only way around this if I want to > continue > > >> >> to use SO_SNDBUF sizes larger than 65536 is to fragment large mbu= f > > >> >> chains in the driver? > > >> > > > >> > Hm, is this is a problem without TSO? > > >> > > >> We are using the card without TSO, so I am thinking of changing that > > >> limit to 131072 and retesting. > > >> > > >> I am currently testing with SO_SNDBUF=3D32768 and have not hit the > > problem. > > >> > > >> > Is the problem that the NIC can't handle a frame that big, or a > buffer > > >> > that big? > > >> > Ie - if you handed the hardware two descriptors of 64k each, for t= he > > >> > same IP datagram, will it complain? > > >> > > >> I can't find any documentation, but it seems that with TSO it cannot > > >> handle a frame that big. Actually, since we are not using TSO, there > > >> really should not be a problem with larger frames. > > >> > > >> > Or do you need to break it up into two separate IP datagrams, faci= ng > > >> > the driver, with a maximum size of 64k each? > > >> > > >> Not sure, but it looks like we need to do that. > > >> > > >> > > >> -- > > >> Regards, > > >> Richard Sharpe > > >> (=E4=BD=95=E4=BB=A5=E8=A7=A3=E6=86=82=EF=BC=9F=E5=94=AF=E6=9C=89=E6= =9D=9C=E5=BA=B7=E3=80=82--=E6=9B=B9=E6=93=8D) > > >> _______________________________________________ > > >> freebsd-net@freebsd.orgmailing list > > >> http://lists.freebsd.org/mailman/listinfo/freebsd-net > > >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.or= g > " > > > > > > > > > > > > > > -- > > Regards, > > Richard Sharpe > > (=E4=BD=95=E4=BB=A5=E8=A7=A3=E6=86=82=EF=BC=9F=E5=94=AF=E6=9C=89=E6=9D= =9C=E5=BA=B7=E3=80=82--=E6=9B=B9=E6=93=8D) > > > _______________________________________________ > freebsd-net@freebsd.org m= ailing 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 Sat May 18 16:16: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 66EEF389 for ; Sat, 18 May 2013 16:16:25 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 27C8588F for ; Sat, 18 May 2013 16:16:25 +0000 (UTC) Received: by mail-ve0-f175.google.com with SMTP id cz11so4694764veb.6 for ; Sat, 18 May 2013 09:16:24 -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=AjW0C2yl2nYSWjxeF6Bs2kgsSjeMu/Jq2K30UoLIW0Q=; b=AabCQ2d9ouHrRZuu+DRl7Oyymx7XNe+T2utvca3Fyvpw9lUxboZiEZudm/4xdOsX11 zrFVt+A71juGlydjVInbHisiUvSRH5WFyou2oUmmjaPvi/JToyXd+jFsF6ah136ud7cP aos4vo4KUWLXvYSSFhVAcA7JOfkgdMg+urm/TDOhI76aJwixmSj3a0XlJ9rPwrfB7Q1L XGU6qfGubo2+BaT2ONGsu0lmsUVU42dX2MqKUGzAUhzRgnGwC7jgEqa1Yl7h20AqBCF/ VTGAATSwFBol10q26CG1rdEFc05+qa42zp+bLSfLh2LLdCYvyP8XKXrkydAp2R7Xt1P2 QvIg== MIME-Version: 1.0 X-Received: by 10.52.171.135 with SMTP id au7mr307203vdc.126.1368893784098; Sat, 18 May 2013 09:16:24 -0700 (PDT) Received: by 10.220.55.143 with HTTP; Sat, 18 May 2013 09:16:23 -0700 (PDT) In-Reply-To: <1368878922.70089.YahooMailClassic@web125801.mail.ne1.yahoo.com> References: <1368878922.70089.YahooMailClassic@web125801.mail.ne1.yahoo.com> Date: Sat, 18 May 2013 09:16:23 -0700 Message-ID: Subject: Re: Is there any way to limit the amount of data in an mbuf chain submitted to a driver? From: Jack Vogel To: Laurie Jennings Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: quoted-printable 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: Sat, 18 May 2013 16:16:25 -0000 Version numbers result from my work internally, and sometimes they increment due to a build issue, or a bug found that needs to be corrected, so unfortunately its not always a neat progression. I have thought at times about having a separate revision sequence but that would make for other issues, also not ever change made into the community source changes the version either. Its all because of the driver living in two different worlds you might say :) I don't have the list at hand right now, what were you planning to deploy instead? Jack On Sat, May 18, 2013 at 5:08 AM, Laurie Jennings < laurie_jennings_1977@yahoo.com> wrote: > Can you outline the changes? Anything with the general processing? I have > to make > a case to hold off a deployment. > > and what happened to 9, 10, and 11? > > Laurie > > > --- On *Fri, 5/17/13, Jack Vogel * wrote: > > > From: Jack Vogel > Subject: Re: Is there any way to limit the amount of data in an mbuf chai= n > submitted to a driver? > To: "Laurie Jennings" > Cc: "FreeBSD Net" , "Adrian Chadd" < > adrian@freebsd.org>, "Richard Sharpe" > Date: Friday, May 17, 2013, 3:32 PM > > No Laurie, I ran into an issue that I needed to resolve, and then my > validation engineer > went out of town a couple days. Should be early next week. > > Jack > > > > On Fri, May 17, 2013 at 3:25 PM, Laurie Jennings < > laurie_jennings_1977@yahoo.com> > wrote: > > > Did you get to commit that new code yet? > > > > Laurie > > > > --- On *Sat, 5/4/13, Jack Vogel >* > wrote: > > > > > > From: Jack Vogel > > > > Subject: Re: Is there any way to limit the amount of data in an mbuf > chain > > submitted to a driver? > > To: "Richard Sharpe" > > > > Cc: "FreeBSD Net" >, > "Adrian Chadd" < > > adrian@freebsd.org > > > Date: Saturday, May 4, 2013, 2:18 PM > > > > > > Ahh, Twinville, new hardware :) The version at the tip is 2.5.8 and I = am > > working on version 2.5.12 internally that I hope to commit next week... > > so your version is "a bit old" :) I would do some testing on newer code= . > > > > Jack > > > > > > > > On Sat, May 4, 2013 at 1:54 PM, Richard Sharpe > > > > > >wrote: > > > > > On Sat, May 4, 2013 at 1:41 PM, Jack Vogel > > > > > wrote: > > > > If you don't use TSO you will hurt your TX performance significantl= y > > from > > > > the tests that I've run. What exactly is the device you are using, = I > > > don't > > > > have the source in front of me now, but I'm almost sure that the > limit > > is > > > > not 64K but 256K, or are you using some ancient version of the > driver? > > > > > > ix0 pnpinfo vendor=3D0x8086 device=3D0x1528 subvendor=3D0= x8086 > > > subdevice=3D0x0001 class=3D0x020000 at slot=3D0 function=3D0 > > > ix1 pnpinfo vendor=3D0x8086 device=3D0x1528 subvendor=3D0= x8086 > > > subdevice=3D0x0001 class=3D0x020000 at slot=3D0 function=3D1 > > > > > > The version calls itself ixgbe-2.4.4 ... > > > > > > Hmmm, copyright is 2001-2010 ... so perhaps a bit old. > > > > > > > Jack > > > > > > > > > > > > > > > > On Sat, May 4, 2013 at 1:30 PM, Richard Sharpe < > > > realrichardsharpe@gmail.com > > > > > > > > wrote: > > > >> > > > >> On Sat, May 4, 2013 at 10:39 AM, Adrian Chadd > > > > > > > wrote: > > > >> > On 4 May 2013 06:52, Richard Sharpe > > > > > > > > wrote: > > > >> >> Hi folks, > > > >> >> > > > >> >> I understand better why I am seeing EINVAL intermittently when > > > sending > > > >> >> data from Samba via SMB2. > > > >> >> > > > >> >> The ixgbe driver, for TSO reasons, limits the amount of data th= at > > can > > > >> >> be DMA'd to 65535 bytes. It returns EINVAL for any mbuf chain > > larger > > > >> >> than that. > > > >> >> > > > >> >> The SO_SNDBUF for that socket is set to 131972. Mostly there is > > less > > > >> >> than 64kiB of space available, so that is all TCP etc can put > into > > > the > > > >> >> socket in one chain of mbufs. However, every now and then there > is > > > >> >> more than 65535 bytes available in the socket buffers, and we > have > > an > > > >> >> SMB packet that is larger than 65535 bytes, and we get hit. > > > >> >> > > > >> >> To confirm this I am going to set SO_SNDBUF back to the default > of > > > >> >> 65536 and test again. My repros are very reliable. > > > >> >> > > > >> >> However, I wondered if my only way around this if I want to > > continue > > > >> >> to use SO_SNDBUF sizes larger than 65536 is to fragment large > mbuf > > > >> >> chains in the driver? > > > >> > > > > >> > Hm, is this is a problem without TSO? > > > >> > > > >> We are using the card without TSO, so I am thinking of changing th= at > > > >> limit to 131072 and retesting. > > > >> > > > >> I am currently testing with SO_SNDBUF=3D32768 and have not hit the > > > problem. > > > >> > > > >> > Is the problem that the NIC can't handle a frame that big, or a > > buffer > > > >> > that big? > > > >> > Ie - if you handed the hardware two descriptors of 64k each, for > the > > > >> > same IP datagram, will it complain? > > > >> > > > >> I can't find any documentation, but it seems that with TSO it cann= ot > > > >> handle a frame that big. Actually, since we are not using TSO, the= re > > > >> really should not be a problem with larger frames. > > > >> > > > >> > Or do you need to break it up into two separate IP datagrams, > facing > > > >> > the driver, with a maximum size of 64k each? > > > >> > > > >> Not sure, but it looks like we need to do that. > > > >> > > > >> > > > >> -- > > > >> Regards, > > > >> Richard Sharpe > > > >> (=A6=F3=A5H=B8=D1=BC~=A1H=B0=DF=A6=B3=A7=F9=B1d=A1C--=B1=E4=BE=DE) > > > >> _______________________________________________ > > > >> 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 > > > > " > > > > > > > > > > > > > > > > > > > > -- > > > Regards, > > > Richard Sharpe > > > (=A6=F3=A5H=B8=D1=BC~=A1H=B0=DF=A6=B3=A7=F9=B1d=A1C--=B1=E4=BE=DE) > > > > > _______________________________________________ > > freebsd-net@freebsd.org < > http://mc/compose?to=3Dfreebsd-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 m= ailing 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 Sat May 18 16:26:13 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 38F2B4FE; Sat, 18 May 2013 16:26:13 +0000 (UTC) (envelope-from trociny@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 12DD68E3; Sat, 18 May 2013 16:26:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4IGQCQX045737; Sat, 18 May 2013 16:26:12 GMT (envelope-from trociny@freefall.freebsd.org) Received: (from trociny@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4IGQC6T045736; Sat, 18 May 2013 16:26:12 GMT (envelope-from trociny) Date: Sat, 18 May 2013 16:26:12 GMT Message-Id: <201305181626.r4IGQC6T045736@freefall.freebsd.org> To: vijju.singh@gmail.com, trociny@FreeBSD.org, freebsd-net@FreeBSD.org From: trociny@FreeBSD.org Subject: Re: kern/165643: [net] [patch] Missing vnet restores in net/if_ethersubr.c 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, 18 May 2013 16:26:13 -0000 Synopsis: [net] [patch] Missing vnet restores in net/if_ethersubr.c State-Changed-From-To: open->closed State-Changed-By: trociny State-Changed-When: Sat May 18 16:25:35 UTC 2013 State-Changed-Why: Committed. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=165643 From owner-freebsd-net@FreeBSD.ORG Sat May 18 19:20:02 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 5E363D1C for ; Sat, 18 May 2013 19:20:02 +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 37018F18 for ; Sat, 18 May 2013 19:20:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4IJK2Qo080179 for ; Sat, 18 May 2013 19:20:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4IJK2lg080178; Sat, 18 May 2013 19:20:02 GMT (envelope-from gnats) Date: Sat, 18 May 2013 19:20:02 GMT Message-Id: <201305181920.r4IJK2lg080178@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Mikolaj Golub Subject: Re: kern/167059: [tcp] [panic] System does panic in in_pcbbind() and hangs X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Mikolaj Golub List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2013 19:20:02 -0000 The following reply was made to PR kern/167059; it has been noted by GNATS. From: Mikolaj Golub To: bug-followup@FreeBSD.org, yehorov@gmail.com Cc: Subject: Re: kern/167059: [tcp] [panic] System does panic in in_pcbbind() and hangs Date: Sat, 18 May 2013 22:15:26 +0300 This looks similar to the issue fixed in 9.0 (r227207 + r227449). There was a discussion on freebsd-net@ titled "Kernel panic on FreeBSD 9.0-beta2": http://lists.freebsd.org/pipermail/freebsd-net/2011-September/029858.html Are there chances that you can check >=9.0? -- Mikolaj Golub From owner-freebsd-net@FreeBSD.ORG Sat May 18 19:46:14 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 4E052545; Sat, 18 May 2013 19:46:14 +0000 (UTC) (envelope-from trociny@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 28AAEFCE; Sat, 18 May 2013 19:46:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4IJkEdZ085993; Sat, 18 May 2013 19:46:14 GMT (envelope-from trociny@freefall.freebsd.org) Received: (from trociny@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4IJkDgZ085992; Sat, 18 May 2013 19:46:13 GMT (envelope-from trociny) Date: Sat, 18 May 2013 19:46:13 GMT Message-Id: <201305181946.r4IJkDgZ085992@freefall.freebsd.org> To: yehorov@gmail.com, trociny@FreeBSD.org, freebsd-net@FreeBSD.org From: trociny@FreeBSD.org Subject: Re: kern/167059: [tcp] [panic] System does panic in in_pcbbind() and hangs 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, 18 May 2013 19:46:14 -0000 Synopsis: [tcp] [panic] System does panic in in_pcbbind() and hangs State-Changed-From-To: open->feedback State-Changed-By: trociny State-Changed-When: Sat May 18 19:44:43 UTC 2013 State-Changed-Why: Asking the reporter to check on >=9.0. http://www.freebsd.org/cgi/query-pr.cgi?pr=167059 From owner-freebsd-net@FreeBSD.ORG Sat May 18 19:56: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 426B29C3 for ; Sat, 18 May 2013 19:56:32 +0000 (UTC) (envelope-from laurie_jennings_1977@yahoo.com) Received: from nm6-vm4.bullet.mail.ne1.yahoo.com (nm6-vm4.bullet.mail.ne1.yahoo.com [98.138.91.166]) by mx1.freebsd.org (Postfix) with ESMTP id A4EFDB3 for ; Sat, 18 May 2013 19:56:31 +0000 (UTC) Received: from [98.138.90.53] by nm6.bullet.mail.ne1.yahoo.com with NNFMP; 18 May 2013 19:54:28 -0000 Received: from [98.138.89.248] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 18 May 2013 19:54:28 -0000 Received: from [127.0.0.1] by omp1040.mail.ne1.yahoo.com with NNFMP; 18 May 2013 19:54:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 173277.68242.bm@omp1040.mail.ne1.yahoo.com Received: (qmail 52741 invoked by uid 60001); 18 May 2013 19:54:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1368906868; bh=YPNfUh9RkdauJLzJF9q3EXpkxOiGjIwvNKW5Ez3xMME=; 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=EYROPaYFsB/13tstHJOvSz6GJeHrO1yuBKH4BYt1LgtlWKJmT+lAC6VHsD/Lho1qY9S6daNwnCOKXV/c8zc8vLADKFJRmmjKT4vDAxujhIHXovc6tmKrXT6WCFTXA6xoG9Wvd1CFWI/j2iyhyoFO0JoBTRtPuPX2lqTcZ2b3hKU= 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=SeJgOXgU36Z18mys3KQKNB2SJynyOFArHkuwMeeWzthD/9h0WIdI4cNrWl+ta+FE52yBQnJKHuT7FxTeoxr0HFGADjzb1EN8XmS0Pz2cDxgHlAw/p+4rRmtdMgjo/cNjOXIkVeDZVLh98qKFK4Xv4m9P95t1tDSSCxAHwR1vJa4=; X-YMail-OSG: VTnwtmQVM1nGn99HIoG3xyteHQiD65sEny8vitWNKxl0GTg pzgyYE.YFTL1F.oxH.mUg29LT6LpqzFtmMBZf.bvG03RaFmkPvrg9C7Rbv83 JveijAzy0oi3ptAk07_WRua0pB5f4kSy1d7Pl7WEPuZ3gfCm_OfmABFUBaaW 0gjXfkqgIJE5mEM2MmVSxNZOlMOzYGJrU6Jlb.SYBvSeyxdDSRDUIsY3e8aK lNEImJmb6vf3oPRxYyuGprK6avsFOkKC0kENVZqPrxWvzoUmgcg90FpNX3pZ x3XmdpRzORqzVNgnR6cesQoSMtSWvw3d.Mp7f8HytFaxEDM5nGhKHm4K_OOK hky3TadJEOEYP3FILk2JkGQD4QPiEeQ3RV8ZRY86bynZ._99zL3USCw._li7 Xm6vTVVHS8xtrGoRgu83gLIwJYNoYMyhA64rW5ooPxeXSd3TONwsRWQATOgr xWPX.tEbL1cMKilNQvnnER6Ocw0jTkBF7bqM0TABNKJM0tifv6CBCi8ZLhEi j5c8kgiuxl.9gquZhzua9gNhUKsk06.fvvIBedGaLCg-- Received: from [98.203.118.124] by web125806.mail.ne1.yahoo.com via HTTP; Sat, 18 May 2013 12:54:27 PDT X-Rocket-MIMEInfo: 002.001, SSBoYXZlIHRvIG1ha2UgYSBjYXNlIHRvIHdhaXQgZm9yIHRoZSBuZXcgdmVyc2lvbiBvciB0byBkZXBsb3kgdGhlIGN1cnJlbnQgdmVyc2lvbi4NCkFyZSB0aGVyZSBzdHJ1Y3R1cmFsIGltcHJvdmVtZW50cyB0byB0aGUgZHJpdmVyLCBvciBqdXN0IHBlcmlwaGVyYWwgZmVhdHVyZXM_IFdlJ3JlIHVzaW5neDU0MCBOSUNzLg0KTGF1cmllDQoNCi0tLSBPbiBTYXQsIDUvMTgvMTMsIEphY2sgVm9nZWwgPGpmdm9nZWxAZ21haWwuY29tPiB3cm90ZToNCg0KRnJvbTogSmFjayBWb2dlbCA8amZ2b2dlbEBnbWFpbC4BMAEBAQE- X-Mailer: YahooMailClassic/15.1.8 YahooMailWebService/0.8.142.542 Message-ID: <1368906867.48056.YahooMailClassic@web125806.mail.ne1.yahoo.com> Date: Sat, 18 May 2013 12:54:27 -0700 (PDT) From: Laurie Jennings Subject: Re: Is there any way to limit the amount of data in an mbuf chain submitted to a driver? To: Jack Vogel In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Sat, 18 May 2013 19:56:32 -0000 I have to make a case to wait for the new version or to deploy the current = version. Are there structural improvements to the driver, or just peripheral feature= s? We're usingx540 NICs. Laurie --- On Sat, 5/18/13, Jack Vogel wrote: From: Jack Vogel Subject: Re: Is there any way to limit the amount of data in an mbuf chain = submitted to a driver? To: "Laurie Jennings" Cc: "FreeBSD Net" Date: Saturday, May 18, 2013, 9:16 AM Version numbers result from my work internally, and sometimes they increment due to a build issue, or a bug found that needs to be corrected, so unfortunately its not always a neat progression. I have thought at times about having a separate revision sequence but that would make for other issues, also not ever change made into the community source changes the version either. Its all because of the driver living in two different worlds you might say :) I don't have the list at hand right now, what were you planning to deploy instead? Jack On Sat, May 18, 2013 at 5:08 AM, Laurie Jennings < laurie_jennings_1977@yahoo.com> wrote: > Can you outline the changes? Anything with the general processing? I have > to make > a case to hold off a deployment. > > and what happened to 9, 10, and 11? > > Laurie > > > --- On *Fri, 5/17/13, Jack Vogel * wrote: > > > From: Jack Vogel > Subject: Re: Is there any way to limit the amount of data in an mbuf chai= n > submitted to a driver? > To: "Laurie Jennings" > Cc: "FreeBSD Net" , "Adrian Chadd" < > adrian@freebsd.org>, "Richard Sharpe" > Date: Friday, May 17, 2013, 3:32 PM > > No Laurie, I ran into an issue that I needed to resolve, and then my > validation engineer > went out of town a couple days. Should be early next week. > > Jack > > > > On Fri, May 17, 2013 at 3:25 PM, Laurie Jennings < > laurie_jennings_1977@yahoo.com> > wrote: > > > Did you get to commit that new code yet? > > > > Laurie > > > > --- On *Sat, 5/4/13, Jack Vogel >* > wrote: > > > > > > From: Jack Vogel > > > > Subject: Re: Is there any way to limit the amount of data in an mbuf > chain > > submitted to a driver? > > To: "Richard Sharpe" > > > > Cc: "FreeBSD Net" >, > "Adrian Chadd" < > > adrian@freebsd.org > > > Date: Saturday, May 4, 2013, 2:18 PM > > > > > > Ahh, Twinville, new hardware :)=C2=A0 The version at the tip is 2.5.8 a= nd I am > > working on version 2.5.12 internally that I hope to commit next week... > > so your version is "a bit old" :) I would do some testing on newer code= . > > > > Jack > > > > > > > > On Sat, May 4, 2013 at 1:54 PM, Richard Sharpe > > > > > >wrote: > > > > > On Sat, May 4, 2013 at 1:41 PM, Jack Vogel > > > > > wrote: > > > > If you don't use TSO you will hurt your TX performance significantl= y > > from > > > > the tests that I've run. What exactly is the device you are using, = I > > > don't > > > > have the source in front of me now, but I'm almost sure that the > limit > > is > > > > not 64K but 256K, or are you using some ancient version of the > driver? > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0ix0 pnpinfo vendo= r=3D0x8086 device=3D0x1528 subvendor=3D0x8086 > > > subdevice=3D0x0001 class=3D0x020000 at slot=3D0 function=3D0 > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0ix1 pnpinfo vendo= r=3D0x8086 device=3D0x1528 subvendor=3D0x8086 > > > subdevice=3D0x0001 class=3D0x020000 at slot=3D0 function=3D1 > > > > > > The version calls itself ixgbe-2.4.4 ... > > > > > > Hmmm, copyright is 2001-2010 ... so perhaps a bit old. > > > > > > > Jack > > > > > > > > > > > > > > > > On Sat, May 4, 2013 at 1:30 PM, Richard Sharpe < > > > realrichardsharpe@gmail.com > > > > > > > > wrote: > > > >> > > > >> On Sat, May 4, 2013 at 10:39 AM, Adrian Chadd > > > > > > > wrote: > > > >> > On 4 May 2013 06:52, Richard Sharpe > > > > > > > > wrote: > > > >> >> Hi folks, > > > >> >> > > > >> >> I understand better why I am seeing EINVAL intermittently when > > > sending > > > >> >> data from Samba via SMB2. > > > >> >> > > > >> >> The ixgbe driver, for TSO reasons, limits the amount of data th= at > > can > > > >> >> be DMA'd to 65535 bytes. It returns EINVAL for any mbuf chain > > larger > > > >> >> than that. > > > >> >> > > > >> >> The SO_SNDBUF for that socket is set to 131972. Mostly there is > > less > > > >> >> than 64kiB of space available, so that is all TCP etc can put > into > > > the > > > >> >> socket in one chain of mbufs. However, every now and then there > is > > > >> >> more than 65535 bytes available in the socket buffers, and we > have > > an > > > >> >> SMB packet that is larger than 65535 bytes, and we get hit. > > > >> >> > > > >> >> To confirm this I am going to set SO_SNDBUF back to the default > of > > > >> >> 65536 and test again. My repros are very reliable. > > > >> >> > > > >> >> However, I wondered if my only way around this if I want to > > continue > > > >> >> to use SO_SNDBUF sizes larger than 65536 is to fragment large > mbuf > > > >> >> chains in the driver? > > > >> > > > > >> > Hm, is this is a problem without TSO? > > > >> > > > >> We are using the card without TSO, so I am thinking of changing th= at > > > >> limit to 131072 and retesting. > > > >> > > > >> I am currently testing with SO_SNDBUF=3D32768 and have not hit the > > > problem. > > > >> > > > >> > Is the problem that the NIC can't handle a frame that big, or a > > buffer > > > >> > that big? > > > >> > Ie - if you handed the hardware two descriptors of 64k each, for > the > > > >> > same IP datagram, will it complain? > > > >> > > > >> I can't find any documentation, but it seems that with TSO it cann= ot > > > >> handle a frame that big. Actually, since we are not using TSO, the= re > > > >> really should not be a problem with larger frames. > > > >> > > > >> > Or do you need to break it up into two separate IP datagrams, > facing > > > >> > the driver, with a maximum size of 64k each? > > > >> > > > >> Not sure, but it looks like we need to do that. > > > >> > > > >> > > > >> -- > > > >> Regards, > > > >> Richard Sharpe > > > >> (=E4=BD=95=E4=BB=A5=E8=A7=A3=E6=86=82=EF=BC=9F=E5=94=AF=E6=9C=89= =E6=9D=9C=E5=BA=B7=E3=80=82--=E6=9B=B9=E6=93=8D) > > > >> _______________________________________________ > > > >> 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 > > > > " > > > > > > > > > > > > > > > > > > > > -- > > > Regards, > > > Richard Sharpe > > > (=E4=BD=95=E4=BB=A5=E8=A7=A3=E6=86=82=EF=BC=9F=E5=94=AF=E6=9C=89=E6= =9D=9C=E5=BA=B7=E3=80=82--=E6=9B=B9=E6=93=8D) > > > > > _______________________________________________ > > freebsd-net@freebsd.org < > http://mc/compose?to=3Dfreebsd-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 m= ailing 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 Sat May 18 20: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 E2E42AD0 for ; Sat, 18 May 2013 20: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 BB4C1D4 for ; Sat, 18 May 2013 20:00:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4IK01k5088709 for ; Sat, 18 May 2013 20:00:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4IK01A1088708; Sat, 18 May 2013 20:00:01 GMT (envelope-from gnats) Date: Sat, 18 May 2013 20:00:01 GMT Message-Id: <201305182000.r4IK01A1088708@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Mykhaylo Yehorov Subject: Re: kern/167059: [tcp] [panic] System does panic in in_pcbbind() and hangs X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Mykhaylo Yehorov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2013 20:00:01 -0000 The following reply was made to PR kern/167059; it has been noted by GNATS. From: Mykhaylo Yehorov To: Mikolaj Golub Cc: bug-followup@freebsd.org Subject: Re: kern/167059: [tcp] [panic] System does panic in in_pcbbind() and hangs Date: Sat, 18 May 2013 22:51:00 +0300 --089e0158b44c3cc80904dd036b4d Content-Type: text/plain; charset=UTF-8 We use our software on FreeBSD 9.X without any kernel panics for a year. On Sat, May 18, 2013 at 10:15 PM, Mikolaj Golub wrote: > This looks similar to the issue fixed in 9.0 (r227207 + r227449). > > There was a discussion on freebsd-net@ titled "Kernel panic on FreeBSD > 9.0-beta2": > > > http://lists.freebsd.org/pipermail/freebsd-net/2011-September/029858.html > > Are there chances that you can check >=9.0? > > -- > Mikolaj Golub > -- Mykhaylo Yehorov --089e0158b44c3cc80904dd036b4d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We use our software on FreeBSD 9.X without any kernel pani= cs for a year.


On Sat, May 18, 2013 at 10:15 PM, Mikolaj Golub <trociny@free= bsd.org> wrote:
This looks similar to the issue fixed in 9.0= (r227207 + r227449).

There was a discussion on freebsd-net@ titled "Kernel panic on FreeBSD=
9.0-beta2":

=C2=A0 http://lists.freebsd.org/pipermail/free= bsd-net/2011-September/029858.html

Are there chances that you can check >=3D9.0?

--
Mikolaj Golub



--
Mykhaylo = Yehorov
--089e0158b44c3cc80904dd036b4d-- From owner-freebsd-net@FreeBSD.ORG Sat May 18 20:08:22 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 9CCC0F57; Sat, 18 May 2013 20:08:22 +0000 (UTC) (envelope-from trociny@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 76CE6126; Sat, 18 May 2013 20:08:22 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4IK8Mce090774; Sat, 18 May 2013 20:08:22 GMT (envelope-from trociny@freefall.freebsd.org) Received: (from trociny@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4IK8MhY090773; Sat, 18 May 2013 20:08:22 GMT (envelope-from trociny) Date: Sat, 18 May 2013 20:08:22 GMT Message-Id: <201305182008.r4IK8MhY090773@freefall.freebsd.org> To: yehorov@gmail.com, trociny@FreeBSD.org, freebsd-net@FreeBSD.org From: trociny@FreeBSD.org Subject: Re: kern/167059: [tcp] [panic] System does panic in in_pcbbind() and hangs 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, 18 May 2013 20:08:22 -0000 Synopsis: [tcp] [panic] System does panic in in_pcbbind() and hangs State-Changed-From-To: feedback->closed State-Changed-By: trociny State-Changed-When: Sat May 18 20:07:20 UTC 2013 State-Changed-Why: It is believed to be fixed in 9.0. http://www.freebsd.org/cgi/query-pr.cgi?pr=167059