From owner-freebsd-net@FreeBSD.ORG Sun Jan 13 22:07:47 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 85905BE5 for ; Sun, 13 Jan 2013 22:07:47 +0000 (UTC) (envelope-from guy.helmer@gmail.com) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by mx1.freebsd.org (Postfix) with ESMTP id 533BC8D for ; Sun, 13 Jan 2013 22:07:47 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id h16so3452299oag.33 for ; Sun, 13 Jan 2013 14:07:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=9ReybXVz3A/Po1AfVJP38akhONjCkla7Q/YSSKMkxbI=; b=YqR8MtZNqO2Of7s8Llt1OgDeN9JnT9QrMxS6aBjhLFLZ6z4bgB8Efwba5DeSzWAjjL Wx4VIEsYRzohnvta9Bfx6WKzN244KcSHG9C11S4q7K0LeagU64ulbDj9QR2EH7HkCAFP zSZmXxE/AHWWlWd8naPmNcGQHoOwi3ijh57pjZczTLkj3SCJFYvBo5/5rNL9Pvuc9igZ sALehoZFB08GoSBuSyFUR1QfuB/ZzE1Ik4aXQrBVg+xN5kiVl7m2QcgURWut7oFehCHV 0T955rj5IORwHyMZCjxjCNBryNPy5zGstTlnPZFwYPluzUV8gxauFbmJdAlmFsh+xFHb y4ig== X-Received: by 10.60.12.74 with SMTP id w10mr51062783oeb.100.1358114866603; Sun, 13 Jan 2013 14:07:46 -0800 (PST) Received: from [192.168.1.107] (173-25-205-212.client.mchsi.com. [173.25.205.212]) by mx.google.com with ESMTPS id yn8sm9104700obb.12.2013.01.13.14.07.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 13 Jan 2013 14:07:46 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: bpf hold buffer in-use flag From: Guy Helmer In-Reply-To: <0AAF6A81-2594-449E-A38D-28DE5B055AFF@sqrt.ca> Date: Sun, 13 Jan 2013 16:07:44 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <0D770FD0-6FD1-4D01-84A3-69B610894B9D@gmail.com> References: <9C928117-2230-4F01-9B95-B6D945AF4416@gmail.com> <0AAF6A81-2594-449E-A38D-28DE5B055AFF@sqrt.ca> To: Christian Peron X-Mailer: Apple Mail (2.1499) 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: Sun, 13 Jan 2013 22:07:47 -0000 On Jan 11, 2013, at 5:48 PM, Christian Peron wrote: > Guy, >=20 > Can you please describe the race and how to reproduce it? When we = introduced zerocopy-bpf, we also introduced bpf_bufheld() and = bpf_bufreclaimed() which are effectively nops for the regular buffer = mode. Maybe we could maintain state there as well? In any case, I would = like to understand the race/and reproduce it >=20 > Thanks! Related to rwatson's comment from r175903, dropping the bpf descriptor = lock while performing the uiomove() in bpfread() enables a couple of = races: 1) simultaneous reads on a bpf device (not great), and 2) races = between bpfread() and catchpacket() (panics due to NULL pointer = dereference). The symptom I encountered was a panic in catchpacket() where the save = buffer was NULL. I added diagnostic code and found that one of the two = buffers was being lost. As I reviewed the code, it seemed that the only = way this could happen was if the hold buffer was being invalidated = (rotated) out from under these lines in bpfread(): BPFD_UNLOCK(d);=20 =20 /*=20 * Move data from hold buffer into user space.=20 * We know the entire buffer is transferred since=20 * we checked above that the read buffer is bpf_bufsize bytes.=20= *=20 * XXXRW: More synchronization needed here: what if a second = thread=20 * issues a read on the same fd at the same time? Don't want = this=20 * getting invalidated.=20 */=20 error =3D bpf_uiomove(d, d->bd_hbuf, d->bd_hlen, uio);=20 =20 BPFD_LOCK(d);=20 d->bd_fbuf =3D d->bd_hbuf; /* if other code in the driver = simultaneously sets hbuf to NULL, this loses a buffer! */ d->bd_hbuf =3D NULL;=20 d->bd_hlen =3D 0;=20 bpf_buf_reclaimed(d);=20 BPFD_UNLOCK(d);=20 My instrumented code validated this hypothesis, and I added the = bd_hbuf_in_use flag to allow dropping the descriptor lock over the = bpf_uiomove() call while protecting the hold buffer from rotation = anywhere else in the driver. In my own tree, I have left some additional = diagnostic code to make sure hbuf is still valid after uiomove = completes, and that code has not been triggered since I added the = bd_hbuf_in_use flag and associated code. The way I was able to trigger the panic in catchpacket() was to call = pcap_setfilter() more than one time on a live, promiscuous pcap = descriptor while reading from a very busy network. I was able to = temporarily work around this issue by using the BIOCSETFNR ioctl = directly on the bpf descriptor rather than using pcap_setfilter(), which = avoided calling reset_d() in the ioctl handler and thus avoided clearing = bd_hbuf in a race with bpfread(). Just as I'm writing this, I realized the code that triggered the problem = may have called pcap_setfilter() in a separate thread from the packet = reading thread. I wrote a unit test for this issue, but as it was = single-threaded, I was never able to cause the crash with it. Regarding the zero-copy code, I'm not sure how bpf_bufheld() could be = used as a general approach to solving this race. It appears to me that a = condition variable is necessary to work around the necessity of = releasing the bpf descriptor lock over the uiomove() call. Hope this helps! Guy >=20 > On 2012-11-13, at 3:40 PM, Guy Helmer wrote: >=20 >> To try to completely resolve the race in bpfread(), I have put = together these changes to add a flag to indicate when the hold buffer = cannot be modified because it is in use. Since it's my first time using = mtx_sleep() and wakeup(), I wanted to run these past the list to see if = I can get any feedback on the approach. >>=20 >>=20 >> Index: bpf.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- bpf.c (revision 242997) >> +++ bpf.c (working copy) >> @@ -819,6 +819,7 @@ bpfopen(struct cdev *dev, int flags, int fmt, = stru >> * particular buffer method. >> */ >> bpf_buffer_init(d); >> + d->bd_hbuf_in_use =3D 0; >> d->bd_bufmode =3D BPF_BUFMODE_BUFFER; >> d->bd_sig =3D SIGIO; >> d->bd_direction =3D BPF_D_INOUT; >> @@ -872,6 +873,9 @@ bpfread(struct cdev *dev, struct uio *uio, int = iof >> callout_stop(&d->bd_callout); >> timed_out =3D (d->bd_state =3D=3D BPF_TIMED_OUT); >> d->bd_state =3D BPF_IDLE; >> + while (d->bd_hbuf_in_use) >> + mtx_sleep(&d->bd_hbuf_in_use, &d->bd_lock, >> + PRINET|PCATCH, "bd_hbuf", 0); >> /* >> * If the hold buffer is empty, then do a timed sleep, which >> * ends when the timeout expires or when enough packets >> @@ -940,27 +944,27 @@ bpfread(struct cdev *dev, struct uio *uio, int = iof >> /* >> * At this point, we know we have something in the hold slot. >> */ >> + d->bd_hbuf_in_use =3D 1; >> BPFD_UNLOCK(d); >>=20 >> /* >> * Move data from hold buffer into user space. >> * We know the entire buffer is transferred since >> * we checked above that the read buffer is bpf_bufsize bytes. >> - * >> - * XXXRW: More synchronization needed here: what if a second = thread >> - * issues a read on the same fd at the same time? Don't want = this >> - * getting invalidated. >> + * >> + * We do not have to worry about simultaneous reads because >> + * we waited for sole access to the hold buffer above. >> */ >> error =3D bpf_uiomove(d, d->bd_hbuf, d->bd_hlen, uio); >>=20 >> BPFD_LOCK(d); >> - if (d->bd_hbuf !=3D NULL) { >> - /* Free the hold buffer only if it is still valid. */ >> - d->bd_fbuf =3D d->bd_hbuf; >> - d->bd_hbuf =3D NULL; >> - d->bd_hlen =3D 0; >> - bpf_buf_reclaimed(d); >> - } >> + KASSERT(d->bd_hbuf !=3D NULL, ("bpfread: lost bd_hbuf")); >> + d->bd_fbuf =3D d->bd_hbuf; >> + d->bd_hbuf =3D NULL; >> + d->bd_hlen =3D 0; >> + bpf_buf_reclaimed(d); >> + d->bd_hbuf_in_use =3D 0; >> + wakeup(&d->bd_hbuf_in_use); >> BPFD_UNLOCK(d); >>=20 >> return (error); >> @@ -1114,6 +1118,9 @@ reset_d(struct bpf_d *d) >>=20 >> BPFD_LOCK_ASSERT(d); >>=20 >> + while (d->bd_hbuf_in_use) >> + mtx_sleep(&d->bd_hbuf_in_use, &d->bd_lock, PRINET, >> + "bd_hbuf", 0); >> if ((d->bd_hbuf !=3D NULL) && >> (d->bd_bufmode !=3D BPF_BUFMODE_ZBUF || bpf_canfreebuf(d))) = { >> /* Free the hold buffer. */ >> @@ -1254,6 +1261,9 @@ bpfioctl(struct cdev *dev, u_long cmd, caddr_t = add >>=20 >> BPFD_LOCK(d); >> n =3D d->bd_slen; >> + while (d->bd_hbuf_in_use) >> + mtx_sleep(&d->bd_hbuf_in_use, = &d->bd_lock, >> + PRINET, "bd_hbuf", 0); >> if (d->bd_hbuf) >> n +=3D d->bd_hlen; >> BPFD_UNLOCK(d); >> @@ -1967,6 +1977,9 @@ filt_bpfread(struct knote *kn, long hint) >> ready =3D bpf_ready(d); >> if (ready) { >> kn->kn_data =3D d->bd_slen; >> + while (d->bd_hbuf_in_use) >> + mtx_sleep(&d->bd_hbuf_in_use, &d->bd_lock, >> + PRINET, "bd_hbuf", 0); >> if (d->bd_hbuf) >> kn->kn_data +=3D d->bd_hlen; >> } else if (d->bd_rtout > 0 && d->bd_state =3D=3D BPF_IDLE) { >> @@ -2299,6 +2312,9 @@ catchpacket(struct bpf_d *d, u_char *pkt, u_int = pk >> * spot to do it. >> */ >> if (d->bd_fbuf =3D=3D NULL && bpf_canfreebuf(d)) { >> + while (d->bd_hbuf_in_use) >> + mtx_sleep(&d->bd_hbuf_in_use, &d->bd_lock, >> + PRINET, "bd_hbuf", 0); >> d->bd_fbuf =3D d->bd_hbuf; >> d->bd_hbuf =3D NULL; >> d->bd_hlen =3D 0; >> @@ -2341,6 +2357,9 @@ catchpacket(struct bpf_d *d, u_char *pkt, u_int = pk >> ++d->bd_dcount; >> return; >> } >> + while (d->bd_hbuf_in_use) >> + mtx_sleep(&d->bd_hbuf_in_use, &d->bd_lock, >> + PRINET, "bd_hbuf", 0); >> ROTATE_BUFFERS(d); >> do_wakeup =3D 1; >> curlen =3D 0; >> Index: bpf.h >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- bpf.h (revision 242997) >> +++ bpf.h (working copy) >> @@ -1235,7 +1235,8 @@ SYSCTL_DECL(_net_bpf); >> /* >> * Rotate the packet buffers in descriptor d. Move the store buffer = into the >> * hold slot, and the free buffer ino the store slot. Zero the length = of the >> - * new store buffer. Descriptor lock should be held. >> + * new store buffer. Descriptor lock should be held. Hold buffer = must >> + * not be marked "in use". >> */ >> #define ROTATE_BUFFERS(d) do { = \ >> (d)->bd_hbuf =3D (d)->bd_sbuf; = \ >> Index: bpf_buffer.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- bpf_buffer.c (revision 242997) >> +++ bpf_buffer.c (working copy) >> @@ -189,6 +189,9 @@ bpf_buffer_ioctl_sblen(struct bpf_d *d, u_int *i) >> return (EINVAL); >> } >>=20 >> + while (d->bd_hbuf_in_use) >> + mtx_sleep(&d->bd_hbuf_in_use, &d->bd_lock, >> + PRINET, "bd_hbuf", 0); >> /* Free old buffers if set */ >> if (d->bd_fbuf !=3D NULL) >> free(d->bd_fbuf, M_BPF); >> Index: bpfdesc.h >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- bpfdesc.h (revision 242997) >> +++ bpfdesc.h (working copy) >> @@ -63,6 +63,7 @@ struct bpf_d { >> caddr_t bd_sbuf; /* store slot */ >> caddr_t bd_hbuf; /* hold slot */ >> caddr_t bd_fbuf; /* free slot */ >> + int bd_hbuf_in_use; /* don't rotate buffers */ >> int bd_slen; /* current length of store = buffer */ >> int bd_hlen; /* current length of hold buffer = */ >>=20 >> _______________________________________________ >> 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" >=20 From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 03:01:30 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 B1CB5E74; Mon, 14 Jan 2013 03:01:30 +0000 (UTC) (envelope-from bryanv@daemoninthecloset.org) Received: from torment.daemoninthecloset.org (ip-static-94-242-209-234.as5577.net [94.242.209.234]) by mx1.freebsd.org (Postfix) with ESMTP id 79C76E78; Mon, 14 Jan 2013 03:01:30 +0000 (UTC) Received: from sage.daemoninthecloset.org (unknown [70.114.209.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sage.daemoninthecloset.org", Issuer "daemoninthecloset.org" (verified OK)) by torment.localdomain (Postfix) with ESMTPS id EA99542C0867; Sun, 13 Jan 2013 07:17:16 +0100 (CET) X-Virus-Scanned: amavisd-new at daemoninthecloset.org Received: from sage.daemoninthecloset.org (sage.daemoninthecloset.org [127.0.1.1]) by sage.daemoninthecloset.org (Postfix) with ESMTP id AAFC07AA57; Sun, 13 Jan 2013 00:15:15 -0600 (CST) Date: Sun, 13 Jan 2013 00:15:13 -0600 (CST) From: Bryan Venteicher To: John Baldwin Message-ID: <330287752.17.1358057713463.JavaMail.root@daemoninthecloset.org> In-Reply-To: <201301111039.17673.jhb@freebsd.org> Subject: Re: To SMP or not to SMP MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.51.1.14] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - GC23 (Mac)/7.2.0_GA_2669) Cc: freebsd-net@freebsd.org, Peter Jeremy 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, 14 Jan 2013 03:01:30 -0000 ----- Original Message ----- > From: "John Baldwin" > To: freebsd-net@freebsd.org > Cc: "Barney Cordoba" , "Peter Jeremy" > Sent: Friday, January 11, 2013 9:39:17 AM > Subject: Re: To SMP or not to SMP > > On Thursday, January 10, 2013 02:36:59 PM Peter Jeremy wrote: > > On 2013-Jan-07 18:25:58 -0800, Barney Cordoba > > > wrote: > > >I have a situation where I have to run 9.1 on an old single core > > >box. Does anyone have a handle on whether it's better to build a > > >non > > >SMP kernel or to just use a standard SMP build with just the one > > >core? > > > > Another input for this decision is kern/173322. Currently on x86, > > atomic operations within kernel modules are implemented using calls > > to code in the kernel, which do or don't use lock prefixes > > depending > > on whethur the kernel was built as SMP. My proposed change changes > > kernel modules to inline atomic operations but always include lock > > prefixes (effectively reverting r49999). I'm appreciate anyone who > > feels like testing the impact of this change. > > Presumably a locked atomic op is cheaper than a function call then? > The > current setup assumes the opposite. > > I think we should actually do this for atomics in modules on x86: > > 1) If a module is built standalone, it should do whichever is > cheaper: > a function call or always use "LOCK". > > 2) If a module is built as part of the kernel build, it should use > inlined > atomics that match what the kernel does. Thus, modules built with > a > non-SMP kernel would use inlined atomic ops that do not use LOCK. > We > have a way to detect this now (some HAVE_FOO #define added in the > past > few years) that we didn't back when this bit of atomic.h was > written. > It would be nice to have the LOCK variants available even on UP kernels in non-hackish way. For VirtIO, we need to handle an guest UP kernel running on an SMP host. Whether this is an #define that forces the SMP atomics to be inlined, or if they're exposed with an _smp suffix. VirtIO currently uses mb() to enforce ordering. I have a patch to change to use atomic(9), but can only do so when VirtIO is included in the an SMP kernel (among other constraints - must have 16-bit atomic operations too). (FreeBSD's VirtIO is x86 only for now - but that will be changing soon; I haven't looked if other arch's atomic(9) behave differently for UP/SMP.) > -- > John Baldwin > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 06:16: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 6F937532 for ; Mon, 14 Jan 2013 06:16:06 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by mx1.freebsd.org (Postfix) with ESMTP id 1FD1E397 for ; Mon, 14 Jan 2013 06:16:05 +0000 (UTC) Received: by mail-pb0-f53.google.com with SMTP id jt11so1972958pbb.12 for ; Sun, 13 Jan 2013 22:15:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=+61aG2FVEj4YBy7npHe7/F/0U851NDqe9ndywD9C6M0=; b=KJypQMiJfcDCdMtxwMbnwepr92voHdY5fph/zhHdzQ3OrvU+LC2Jocg2hoX1OWhNu4 OQiqZQ8frydw5W2knm0VnqqGOx0F8AYeIPevql66vcYhETJzJQUaOTeUrYLBfh6nJ4O8 /eUZdBSV3200AYEILSR0BXrklV6tudnibPNhEYf/HMc9FNeXYH0SRRk3rcrNmQTipmKt /RtmA6F25Mr44Vryh+fGuUzPWJXdq1O+6iJaHAWbxUzM4T3pNUFE5kM/A05mATTRilKz aRWBH0QF2L5UBndpIN+nbT7aW3MMMPae/7jky4WD4FF4+ZvUzwJQV0prNdT2ZV8Mj867 q5pw== X-Received: by 10.66.82.170 with SMTP id j10mr230735565pay.9.1358144159530; Sun, 13 Jan 2013 22:15:59 -0800 (PST) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id qt2sm7619716pbb.24.2013.01.13.22.15.56 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 13 Jan 2013 22:15:58 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 14 Jan 2013 15:15:53 +0900 From: YongHyeon PYUN Date: Mon, 14 Jan 2013 15:15:53 +0900 To: Ruslan Makhmatkhanov Subject: Re: if_vr(4) and DFE520-TX Message-ID: <20130114061553.GA3531@michelle.cdnetworks.com> References: <50F110AB.1030107@yandex.ru> <50F14880.4090001@yandex.ru> <50F177E9.3040003@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50F177E9.3040003@yandex.ru> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 06:16:06 -0000 On Sat, Jan 12, 2013 at 06:49:13PM +0400, Ruslan Makhmatkhanov wrote: > Ok, I got some details. It's an DFE-520TX (/C1 or rev. C1). I crafted an > patch attached, but whenever kldloading the modified if_vr, I got this: > > kernel: vr0: port 0xd100-0xd1ff > mem 0xf7c11000-0xf7c110ff irq 19 at device 0.0 on pci4 > kernel: vr0: Quirks: 0x0 > kernel: vr0: Revision: 0x10 > kernel: vr0: reset never completed! > kernel: vr0: attaching PHYs failed > kernel: device_attach: vr0 attach returned 6 > kernel: vr0: port 0xd000-0xd0ff > mem 0xf7c10000-0xf7c100ff irq 16 at device 1.0 on pci4 > kernel: vr0: Quirks: 0x0 > kernel: vr0: Revision: 0x10 > kernel: vr0: reset never completed! > kernel: vr0: attaching PHYs failed > kernel: device_attach: vr0 attach returned 6 > > I also tried to apply VR_Q_NEEDALIGN quirk, but nothing is changed. Any > hints? I recall D-Link was one of notorious vendor which used to completely change its chip set in later revisions without notice. So I'm afraid the controller you have may not be a VIA manufactured one. Could you take a picture of the chip set of controller and let others see it? I guess it could be a RealTek 8139 or 8139C+. > > > Ruslan Makhmatkhanov wrote on 12.01.2013 15:26: > > > >Here is also verbose boot log for what it's worth: > >http://pastebin.com/SnivrtFr > > > >Please keep me in cc:, I'm not subscribed. Thanks. > > > >Ruslan Makhmatkhanov wrote on 12.01.2013 11:28: > >>Hello, > >> > >>I bought two D-link DFE520-TX ethernet adapters that supposed to work > >>with if_vr(4) according to man-page. But the driver cannot attach > >>(tested in 9.1-R and pfSense 2.0.2/2.1 (8.1-R and 8.3-R respectively)). > >> > >>none2@pci0:4:0:0: class=0x020000 card=0x11031186 chip=0x42001186 > >>rev=0x10 hdr=0x00 > >> vendor = 'D-Link System Inc' > >> class = network > >> subclass = ethernet > >> > >>Can please anybody suggest proper changes for > >>/sys/dev/vr/if_vrreg.h|if_vr.c (pci ids would be enought, right?) to > >>test if it works. Thanks in advance. > > > > > -- > Regards, > Ruslan > > Tinderboxing kills... the drives. > diff -uN vr.orig/if_vr.c vr/if_vr.c > --- vr.orig/if_vr.c 2013-01-12 13:19:28.000000000 +0400 > +++ vr/if_vr.c 2013-01-12 18:42:52.000000000 +0400 > @@ -138,6 +138,9 @@ > { DELTA_VENDORID, DELTA_DEVICEID_RHINE_II, > VR_Q_NEEDALIGN, > "Delta Electronics Rhine II 10/100BaseTX" }, > + { DLINK_VENDORID, DLINK_DEVICEID_RHINE_II, > + 0, > + "D-Link System Inc 4200 10/100BaseTX" }, > { ADDTRON_VENDORID, ADDTRON_DEVICEID_RHINE_II, > VR_Q_NEEDALIGN, > "Addtron Technology Rhine II 10/100BaseTX" }, > diff -uN vr.orig/if_vrreg.h vr/if_vrreg.h > --- vr.orig/if_vrreg.h 2013-01-12 13:19:28.000000000 +0400 > +++ vr/if_vrreg.h 2013-01-12 14:29:26.000000000 +0400 > @@ -557,6 +557,16 @@ > #define DELTA_DEVICEID_RHINE_II 0x1320 > > /* > + * D-Link System Inc device ID. > + */ > +#define DLINK_VENDORID 0x1186 > + > +/* > + * D-Link System Inc device IDs. > + */ > +#define DLINK_DEVICEID_RHINE_II 0x4200 > + > +/* > * Addtron vendor ID. > */ > #define ADDTRON_VENDORID 0x4033 From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 06:42:29 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 575B1979 for ; Mon, 14 Jan 2013 06:42:29 +0000 (UTC) (envelope-from bryanv@daemoninthecloset.org) Received: from torment.daemoninthecloset.org (ip-static-94-242-209-234.as5577.net [94.242.209.234]) by mx1.freebsd.org (Postfix) with ESMTP id 1CDB16B4 for ; Mon, 14 Jan 2013 06:42:28 +0000 (UTC) Received: from sage.daemoninthecloset.org (unknown [70.114.209.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sage.daemoninthecloset.org", Issuer "daemoninthecloset.org" (verified OK)) by torment.daemoninthecloset.org (Postfix) with ESMTPS id 5538F42C083F for ; Mon, 14 Jan 2013 07:44:19 +0100 (CET) X-Virus-Scanned: amavisd-new at daemoninthecloset.org Received: from sage.daemoninthecloset.org (sage.daemoninthecloset.org [127.0.1.1]) by sage.daemoninthecloset.org (Postfix) with ESMTP id 04FA47AC5A for ; Mon, 14 Jan 2013 00:42:15 -0600 (CST) Date: Mon, 14 Jan 2013 00:42:14 -0600 (CST) From: Bryan Venteicher To: freebsd-net@freebsd.org Message-ID: <1873789450.140.1358145734760.JavaMail.root@daemoninthecloset.org> In-Reply-To: <975792706.137.1358145587551.JavaMail.root@daemoninthecloset.org> Subject: VMware vmxnet2 driver MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.51.1.14] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - GC23 (Mac)/7.2.0_GA_2669) 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, 14 Jan 2013 06:42:29 -0000 Hi, During the previous months, I've been porting OpenBSD's vmxnet driver (if_vic) to FreeBSD [1]. It has reach a doneness that I'd like to draw attention to it for those not subscribed to svn-projects. Most of the original OpenBSD driver - the attach, init, and Tx/Rx paths - have been rewritten. I added support for vmxnet2 - IPv4 TSO and checksum offloading. Code for LRO was added too, but I cannot figure out how to get it enabled on the hypervisor. Unfortunately, the driver tends to be no faster than the emulated em device, which certainly is not the desired outcome for a paravirtualized device. Nothing in the code jumps out as an obvious performance killer. The original OpenBSD driver suffers from the same lower performance, so it was not introduced during the port. I casually suspect the vmxnet code in VMware has not gotten much attention since vmxnet3 was introduced. The performance issue is gating this from being merged into HEAD, but I don't have the spare cycles at the moment to really investigate this; and I need to spend time to get VirtIO in better shape. My ultimate goal is to have a BSD licensed vmxnet3 driver included in FreeBSD to remove the need to use the poor one that's apart of the VMware tools. There is work in progress to get the necessary documentation to make that happen, but there is no firm date yet (likely later this year, hopefully in time for 10.0). Any testing or performance data is welcome. For bulk TCP transfers, if_vic will tend to be faster than em (~1/2 a magnitude) due to TSO, but I don't think that warrants merging into HEAD yet. Bryan [1] - http://svnweb.freebsd.org/base/projects/vmxnet/sys/dev/vmware/vmxnet/ From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 08:44:52 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 EBAB5251; Mon, 14 Jan 2013 08:44:52 +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 C7190D1C; Mon, 14 Jan 2013 08:44:52 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r0E8iqej060000; Mon, 14 Jan 2013 08:44:52 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r0E8iqdl059996; Mon, 14 Jan 2013 08:44:52 GMT (envelope-from linimon) Date: Mon, 14 Jan 2013 08:44:52 GMT Message-Id: <201301140844.r0E8iqdl059996@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/175267: [pf] [tap] pf + tap keep state problem 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, 14 Jan 2013 08:44:53 -0000 Old Synopsis: pf + tap keep state problem New Synopsis: [pf] [tap] pf + tap keep state problem Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jan 14 08:44:16 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=175267 From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 09:11: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 05D2C911 for ; Mon, 14 Jan 2013 09:11:32 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-vb0-f53.google.com (mail-vb0-f53.google.com [209.85.212.53]) by mx1.freebsd.org (Postfix) with ESMTP id B7068E35 for ; Mon, 14 Jan 2013 09:11:31 +0000 (UTC) Received: by mail-vb0-f53.google.com with SMTP id b23so3225235vbz.26 for ; Mon, 14 Jan 2013 01:11:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=IFS6CMNtH5Gw4VLhlacyW/HxIFim3yJb7FDuBIuHgzM=; b=AoXQa1qtLwnjKdoZdruQln3CmlMFkMTo5mFiNY4GahI9vkqpFnAiKSWDQSO+zloXSQ 7P6xy3fSQmlFWmu/l2TDi0GlmVvSnMj69M6U2RAoFKeOW+K4o8gxgdaJ/s8DwvnsNCQE iiJZvuzw3rhQ2HkTae3NJ0EiWibUgnPd2ZWSqdevQHOwZRJl+kV3OuR0zFb7cVSZcfpu OFQYTVZqHeYSGSnxEa8ws6hL2fbDriwSPJFfkDJjZyWYVB7n9soiNcVzfszZwIIebxEC me3laq0XkugRDQLIetDxvUh2LelnNuvAy5S2/EgiEc08DarodTYKoff9174JslFhv60E sY3g== Received: by 10.220.140.143 with SMTP id i15mr100253463vcu.15.1358154685577; Mon, 14 Jan 2013 01:11:25 -0800 (PST) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.58.164.100 with HTTP; Mon, 14 Jan 2013 01:11:05 -0800 (PST) In-Reply-To: References: <20130108230200.GA36903@onelab2.iet.unipi.it> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Mon, 14 Jan 2013 10:11:05 +0100 X-Google-Sender-Auth: l7je_jfdw0EkhryFar8zm3cGs-k Message-ID: Subject: Re: How to use netmap pkt-gen on 9.1? To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 09:11:32 -0000 On Wed, Jan 9, 2013 at 5:50 PM, Olivier Cochard-Labb=E9 wrote: > > Now I reach to use it on -current and, following your advice, on 9.1 too. > The patch (for 9.1-release) that I've used his here: > http://gugus69.free.fr/freebsd/freebsd.netmap.patch > Hi, I've just discovered that on i386 (no problem on amd64) I meet a fatal trap once I start pkt-gen: Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x62e fault code =3D supervisor write, page not present instruction pointer =3D 0x20:0xc0bd80da stack pointer =3D 0x28:0xcd95688c frame pointer =3D 0x28:0xcd9568c8 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 1645 (pkt-gen) trap number =3D 12 panic: page fault cpuid =3D 0 KDB: stack backtrace: #0 0xc096aba0 at kdb_backtrace+0x50 #1 0xc0935f32 at panic+0x152 #2 0xc0bc1852 at trap_fatal+0x262 #3 0xc0bc1b3b at trap_pfault+0x1ab #4 0xc0bc29dd at trap+0x3bd #5 0xc0bab57c at calltrap+0x6 #6 0xc0682a31 at lem_init_locked+0x701 #7 0xc0685594 at lem_netmap_reg+0xe4 #8 0xc0797ede at netmap_ioctl+0xafe #9 0xc08b6d85 at devfs_ioctl_f+0x75 #10 0xc097ca35 at kern_ioctl+0xc5 #11 0xc097ccc5 at sys_ioctl+0xc5 #12 0xc0bc2300 at syscall+0x520 #13 0xc0bab5e1 at Xint0x80_syscall+0x21 I'm agree that compiling an i386 kernel with netmap is a strange idea :-) Regards, Olivier From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 11:06: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 BB9254D7 for ; Mon, 14 Jan 2013 11:06:50 +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 AC81C64B for ; Mon, 14 Jan 2013 11:06:50 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r0EB6oe1086461 for ; Mon, 14 Jan 2013 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r0EB6oCO086459 for freebsd-net@FreeBSD.org; Mon, 14 Jan 2013 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 14 Jan 2013 11:06:50 GMT Message-Id: <201301141106.r0EB6oCO086459@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, 14 Jan 2013 11:06:50 -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/175267 net [pf] [tap] pf + tap keep state problem o kern/175182 net [panic] kernel panic on RADIX_MPATH when deleting rout 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/173475 net [tun] tun(4) stays opened by PID after process is term o kern/173201 net [ixgbe] [patch] Missing / broken ixgbe sysctl's and tu o kern/173137 net [em] em(4) unable to run at gigabit with 9.1-RC2 o kern/173002 net [patch] data type size problem in if_spppsubr.c o kern/172985 net [patch] [ip6] lltable leak when adding and removing IP o kern/172895 net [ixgb] [ixgbe] do not properly determine link-state o kern/172683 net [ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos o kern/172113 net [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net [ip6] IPv6 packets transmitting only on queue 0 o kern/171838 net [oce] [patch] Possible lock reversal and duplicate loc o kern/171739 net [bce] [panic] bce related kernel panic o kern/171728 net [arp] arp issue o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net [ndis] undocumented dependency for ndis(4) o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net [epair] [request] Add the ability to name epair device o kern/171228 net [re] [patch] if_re - eeprom write issues o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169664 net [bgp] Wrongful replacement of interface connected net o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/167059 net [tcp] [panic] System does panic in in_pcbbind() and ha o kern/166940 net [ipfilter] [panic] Double fault in kern 8.2 o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166372 net [patch] ipfilter drops UDP packets with zero checksum o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis o kern/165963 net [panic] [ipf] ipfilter/nat NULL pointer deference o kern/165903 net mbuf leak o kern/165643 net [net] [patch] Missing vnet restores in net/if_ethersub o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W 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 [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph f kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 435 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 11:52:39 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 68C6BF25 for ; Mon, 14 Jan 2013 11:52:39 +0000 (UTC) (envelope-from cvs-src@yandex.ru) Received: from forward4h.mail.yandex.net (forward4h.mail.yandex.net [IPv6:2a02:6b8:0:f05::4]) by mx1.freebsd.org (Postfix) with ESMTP id 1FE56CB6 for ; Mon, 14 Jan 2013 11:52:39 +0000 (UTC) Received: from smtp3h.mail.yandex.net (smtp3h.mail.yandex.net [84.201.186.20]) by forward4h.mail.yandex.net (Yandex) with ESMTP id 5FA991B20E5F; Mon, 14 Jan 2013 15:52:31 +0400 (MSK) Received: from smtp3h.mail.yandex.net (localhost [127.0.0.1]) by smtp3h.mail.yandex.net (Yandex) with ESMTP id 16EDD1B40062; Mon, 14 Jan 2013 15:52:31 +0400 (MSK) Received: from unknown (unknown [77.66.209.54]) by smtp3h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id qUluDXTO-qUlKloYk; Mon, 14 Jan 2013 15:52:30 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1358164351; bh=vbQLF47kz9qPFt49lCiQiC857uVNRbPjrR81LVOUlwY=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=KhWwNqp8T3yJJ3JPReb97JCLejL/NQyIDSiyY1qRNshhXfSdVXTE0EaM9uO58B7wi CMTXL7I1hoG4ryX20iIdevxLolkQYW9Yb93DS7D3eP6nDoqXnFZ4t+U3ti0nefSkkM zaof3X4cPGRJJdTJD+0hOZ9vheuxSBB67flB3H7Y= Message-ID: <50F3F172.5060903@yandex.ru> Date: Mon, 14 Jan 2013 15:52:18 +0400 From: Ruslan Makhmatkhanov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130114 Thunderbird/17.0.2 MIME-Version: 1.0 To: pyunyh@gmail.com Subject: Re: if_vr(4) and DFE520-TX References: <50F110AB.1030107@yandex.ru> <50F14880.4090001@yandex.ru> <50F177E9.3040003@yandex.ru> <20130114061553.GA3531@michelle.cdnetworks.com> In-Reply-To: <20130114061553.GA3531@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Ruslan Makhmatkhanov 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, 14 Jan 2013 11:52:39 -0000 YongHyeon PYUN wrote on 14.01.2013 10:15: > On Sat, Jan 12, 2013 at 06:49:13PM +0400, Ruslan Makhmatkhanov wrote: >> Ok, I got some details. It's an DFE-520TX (/C1 or rev. C1). I crafted an >> patch attached, but whenever kldloading the modified if_vr, I got this: [...] >> I also tried to apply VR_Q_NEEDALIGN quirk, but nothing is changed. Any >> hints? > > I recall D-Link was one of notorious vendor which used to > completely change its chip set in later revisions without notice. So > I'm afraid the controller you have may not be a VIA manufactured > one. > Could you take a picture of the chip set of controller and let > others see it? I guess it could be a RealTek 8139 or 8139C+. Here they are. Both front and back for the case (see no traces of RealTek though): http://s2.postimage.org/9nvkrlpqx/IMAG1040.jpg http://s2.postimage.org/4qi06hnrt/IMAG1041.jpg -- Regards, Ruslan Tinderboxing kills... the drives. From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 20:50:31 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 A5F3F58E for ; Mon, 14 Jan 2013 20:50:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 80D6B996 for ; Mon, 14 Jan 2013 20:50:31 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CE716B95E; Mon, 14 Jan 2013 15:50:30 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: To SMP or not to SMP Date: Mon, 14 Jan 2013 15:07:50 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <330287752.17.1358057713463.JavaMail.root@daemoninthecloset.org> In-Reply-To: <330287752.17.1358057713463.JavaMail.root@daemoninthecloset.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301141507.50250.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 14 Jan 2013 15:50:30 -0500 (EST) Cc: Peter Jeremy , Bryan Venteicher 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, 14 Jan 2013 20:50:31 -0000 On Sunday, January 13, 2013 1:15:13 am Bryan Venteicher wrote: > > ----- Original Message ----- > > From: "John Baldwin" > > To: freebsd-net@freebsd.org > > Cc: "Barney Cordoba" , "Peter Jeremy" > > Sent: Friday, January 11, 2013 9:39:17 AM > > Subject: Re: To SMP or not to SMP > > > > On Thursday, January 10, 2013 02:36:59 PM Peter Jeremy wrote: > > > On 2013-Jan-07 18:25:58 -0800, Barney Cordoba > > > > > wrote: > > > >I have a situation where I have to run 9.1 on an old single core > > > >box. Does anyone have a handle on whether it's better to build a > > > >non > > > >SMP kernel or to just use a standard SMP build with just the one > > > >core? > > > > > > Another input for this decision is kern/173322. Currently on x86, > > > atomic operations within kernel modules are implemented using calls > > > to code in the kernel, which do or don't use lock prefixes > > > depending > > > on whethur the kernel was built as SMP. My proposed change changes > > > kernel modules to inline atomic operations but always include lock > > > prefixes (effectively reverting r49999). I'm appreciate anyone who > > > feels like testing the impact of this change. > > > > Presumably a locked atomic op is cheaper than a function call then? > > The > > current setup assumes the opposite. > > > > I think we should actually do this for atomics in modules on x86: > > > > 1) If a module is built standalone, it should do whichever is cheaper: > > a function call or always use "LOCK". > > > > 2) If a module is built as part of the kernel build, it should use inlined > > atomics that match what the kernel does. Thus, modules built with a > > non-SMP kernel would use inlined atomic ops that do not use LOCK. We > > have a way to detect this now (some HAVE_FOO #define added in the past > > few years) that we didn't back when this bit of atomic.h was > > written. > > > > It would be nice to have the LOCK variants available even on UP > kernels in non-hackish way. For VirtIO, we need to handle an guest > UP kernel running on an SMP host. Whether this is an #define that > forces the SMP atomics to be inlined, or if they're exposed with > an _smp suffix. > > VirtIO currently uses mb() to enforce ordering. I have a patch > to change to use atomic(9), but can only do so when VirtIO is > included in the an SMP kernel (among other constraints - must > have 16-bit atomic operations too). > > (FreeBSD's VirtIO is x86 only for now - but that will be changing > soon; I haven't looked if other arch's atomic(9) behave differently > for UP/SMP.) Only x86 does this weirdness. The simplest workaround might be to require guest kernels to be compiled with SMP for now. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 20:50: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 BC60A58F for ; Mon, 14 Jan 2013 20:50:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 958CF997 for ; Mon, 14 Jan 2013 20:50:32 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F3D4EB993; Mon, 14 Jan 2013 15:50:31 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: if_vr(4) and DFE520-TX Date: Mon, 14 Jan 2013 15:15:29 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <50F110AB.1030107@yandex.ru> <20130114061553.GA3531@michelle.cdnetworks.com> <50F3F172.5060903@yandex.ru> In-Reply-To: <50F3F172.5060903@yandex.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301141515.29312.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 14 Jan 2013 15:50:32 -0500 (EST) Cc: pyunyh@gmail.com, Ruslan Makhmatkhanov 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, 14 Jan 2013 20:50:32 -0000 On Monday, January 14, 2013 6:52:18 am Ruslan Makhmatkhanov wrote: > YongHyeon PYUN wrote on 14.01.2013 10:15: > > On Sat, Jan 12, 2013 at 06:49:13PM +0400, Ruslan Makhmatkhanov wrote: > >> Ok, I got some details. It's an DFE-520TX (/C1 or rev. C1). I crafted an > >> patch attached, but whenever kldloading the modified if_vr, I got this: > > [...] > > >> I also tried to apply VR_Q_NEEDALIGN quirk, but nothing is changed. Any > >> hints? > > > > I recall D-Link was one of notorious vendor which used to > > completely change its chip set in later revisions without notice. So > > I'm afraid the controller you have may not be a VIA manufactured > > one. > > Could you take a picture of the chip set of controller and let > > others see it? I guess it could be a RealTek 8139 or 8139C+. > > Here they are. Both front and back for the case (see no traces of > RealTek though): > > http://s2.postimage.org/9nvkrlpqx/IMAG1040.jpg > http://s2.postimage.org/4qi06hnrt/IMAG1041.jpg Did your cards come in a box with a driver CD? The manual I found online claimed the CD contains drivers for Linux. Those might be useful for determining which chipset these adapters use. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 20:50:34 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 CABAC592 for ; Mon, 14 Jan 2013 20:50:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id A7976999 for ; Mon, 14 Jan 2013 20:50:34 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1DA61B9AD for ; Mon, 14 Jan 2013 15:50:34 -0500 (EST) From: John Baldwin To: net@freebsd.org Subject: [PATCH] Don't imply TCP and UDP socket options are bitmasks Date: Mon, 14 Jan 2013 15:50:13 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201301141550.13577.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 14 Jan 2013 15:50:34 -0500 (EST) 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, 14 Jan 2013 20:50:34 -0000 The constants used for TCP and UDP socket options (TCP_NODELAY, etc.) are currently defined as hex values that are individual bits. However, socket options are never masked together, they are used as a simple enumeration of discrete values. Using a bitmask forces us to run out of bits and makes it harder for vendors to try to use a high range of values for local custom options (hoping that they never conflict with a new option value added in stock FreeBSD). The socket options in do use bitmasks for the low bits because they map directly to bits so_options, but then they start a simple enumeration at 0x1000. TCP and UDP socket options do not directly map to bits in a flags field in the PCB (e.g. TF_NODELAY != TCP_NODELAY). I would like to change the representation of the constants to be decimal instead of hex and encourage new options to fill in the gaps between the existing values. This would preserve the existing ABI but keep things more sane in the future (I believe). The diff is this: Index: netinet/tcp.h =================================================================== --- netinet/tcp.h (revision 245225) +++ netinet/tcp.h (working copy) @@ -151,18 +151,18 @@ /* * User-settable options (used with setsockopt). */ -#define TCP_NODELAY 0x01 /* don't delay send to coalesce packets */ +#define TCP_NODELAY 1 /* don't delay send to coalesce packets */ #if __BSD_VISIBLE -#define TCP_MAXSEG 0x02 /* set maximum segment size */ -#define TCP_NOPUSH 0x04 /* don't push last block of write */ -#define TCP_NOOPT 0x08 /* don't use TCP options */ -#define TCP_MD5SIG 0x10 /* use MD5 digests (RFC2385) */ -#define TCP_INFO 0x20 /* retrieve tcp_info structure */ -#define TCP_CONGESTION 0x40 /* get/set congestion control algorithm */ -#define TCP_KEEPINIT 0x80 /* N, time to establish connection */ -#define TCP_KEEPIDLE 0x100 /* L,N,X start keeplives after this period */ -#define TCP_KEEPINTVL 0x200 /* L,N interval between keepalives */ -#define TCP_KEEPCNT 0x400 /* L,N number of keepalives before close */ +#define TCP_MAXSEG 2 /* set maximum segment size */ +#define TCP_NOPUSH 4 /* don't push last block of write */ +#define TCP_NOOPT 8 /* don't use TCP options */ +#define TCP_MD5SIG 16 /* use MD5 digests (RFC2385) */ +#define TCP_INFO 32 /* retrieve tcp_info structure */ +#define TCP_CONGESTION 64 /* get/set congestion control algorithm */ +#define TCP_KEEPINIT 128 /* N, time to establish connection */ +#define TCP_KEEPIDLE 256 /* L,N,X start keeplives after this period */ +#define TCP_KEEPINTVL 512 /* L,N interval between keepalives */ +#define TCP_KEEPCNT 1024 /* L,N number of keepalives before close */ #define TCP_CA_NAME_MAX 16 /* max congestion control name length */ Index: netinet/udp.h =================================================================== --- netinet/udp.h (revision 245225) +++ netinet/udp.h (working copy) @@ -48,7 +48,7 @@ /* * User-settable options (used with setsockopt). */ -#define UDP_ENCAP 0x01 +#define UDP_ENCAP 1 /* -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 21:04:35 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 439D1BEF; Mon, 14 Jan 2013 21:04:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0AE62A47; Mon, 14 Jan 2013 21:04:35 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 24773B946; Mon, 14 Jan 2013 16:04:34 -0500 (EST) From: John Baldwin To: net@freebsd.org Subject: Some questions about the new TCP congestion control code Date: Mon, 14 Jan 2013 16:04:29 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201301141604.29864.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 14 Jan 2013 16:04:34 -0500 (EST) Cc: Lawrence Stewart 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, 14 Jan 2013 21:04:35 -0000 I was looking at TCP congestion control at work recently and noticed a few "odd" things in the current code. First, there is this chunk of code in cc_ack_received() in tcp_input.c: static void inline cc_ack_received(struct tcpcb *tp, struct tcphdr *th, uint16_t type) { INP_WLOCK_ASSERT(tp->t_inpcb); tp->ccv->bytes_this_ack = BYTES_THIS_ACK(tp, th); if (tp->snd_cwnd == min(tp->snd_cwnd, tp->snd_wnd)) tp->ccv->flags |= CCF_CWND_LIMITED; else tp->ccv->flags &= ~CCF_CWND_LIMITED; Due to hysterical raisins, snd_cwnd and snd_wnd are u_long values, not integers, so the call to min() results in truncation on 64-bit hosts. It should probably be ulmin() instead. However, this line seems to be a really obfuscated way to just write: if (tp->snd_cwnd <= tp->snd_wnd) If that is correct, I would vote for changing this to use the much simpler logic. Secondly, in the particular case I was investigating at work (restart of an idle connnection), the newreno congestion control code in 8.x and later uses a different algorithm than in 7. Specifically, in 7 TCP would reuse the same logic used for an initial cwnd (honoring ss_fltsz). In 8 this no longer happens (instead, 2 is hardcoded). A guess at a possible fix might look something like this: Index: cc_newreno.c =================================================================== --- cc_newreno.c (revision 243660) +++ cc_newreno.c (working copy) @@ -169,8 +169,21 @@ newreno_after_idle(struct cc_var *ccv) if (V_tcp_do_rfc3390) rw = min(4 * CCV(ccv, t_maxseg), max(2 * CCV(ccv, t_maxseg), 4380)); +#if 1 else rw = CCV(ccv, t_maxseg) * 2; +#else + /* XXX: This is missing a lot of stuff that used to be in 7. */ +#ifdef INET6 + else if ((isipv6 ? in6_localaddr(&CCV(ccv, t_inpcb->in6p_faddr)) : + in_localaddr(CCV(ccv, t_inpcb->inp_faddr)))) +#else + else if (in_localaddr(CCV(ccv, t_inpcb->inp_faddr))) +#endif + rw = V_ss_fltsz_local * CCV(ccv, t_maxseg); + else + rw = V_ss_fltsz * CCV(ccv, t_maxseg); +#endif CCV(ccv, snd_cwnd) = min(rw, CCV(ccv, snd_cwnd)); } (But using the #else clause instead of the current #if 1 code). Was this change in 8 intentional? If not, I would suggest that a real fix would be to export a function that includes the logic to compute the initial cwnd and share that between cc_conn_init() in tcp_input.c and cc_newreno.c. (Yes, I realize that ss_fltsz and friends are gone in 10, but if this was a bug then the fix I suggested above of using a common function could be applied to 8 to restore that functionality if desired. The bigger point is to make sure what we are doing is correct as I'm not sure.) -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 21:08:15 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 22FFBDA2; Mon, 14 Jan 2013 21:08:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7179FA7D; Mon, 14 Jan 2013 21:08:14 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0EL7u9f074273; Mon, 14 Jan 2013 23:07:56 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0EL7u9f074273 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0EL7uAE074272; Mon, 14 Jan 2013 23:07:56 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 14 Jan 2013 23:07:56 +0200 From: Konstantin Belousov To: Bryan Venteicher Subject: Re: To SMP or not to SMP Message-ID: <20130114210756.GM2561@kib.kiev.ua> References: <330287752.17.1358057713463.JavaMail.root@daemoninthecloset.org> <201301141507.50250.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5dzPFofyJ6dbelGf" Content-Disposition: inline In-Reply-To: <201301141507.50250.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-net@freebsd.org, Peter Jeremy , John Baldwin 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, 14 Jan 2013 21:08:15 -0000 --5dzPFofyJ6dbelGf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 14, 2013 at 03:07:50PM -0500, John Baldwin wrote: > On Sunday, January 13, 2013 1:15:13 am Bryan Venteicher wrote: > >=20 > > ----- Original Message ----- > > > From: "John Baldwin" > > > To: freebsd-net@freebsd.org > > > Cc: "Barney Cordoba" , "Peter Jeremy" > > > Sent: Friday, January 11, 2013 9:39:17 AM > > > Subject: Re: To SMP or not to SMP > > >=20 > > > On Thursday, January 10, 2013 02:36:59 PM Peter Jeremy wrote: > > > > On 2013-Jan-07 18:25:58 -0800, Barney Cordoba > > > > > > > wrote: > > > > >I have a situation where I have to run 9.1 on an old single core > > > > >box. Does anyone have a handle on whether it's better to build a > > > > >non > > > > >SMP kernel or to just use a standard SMP build with just the one > > > > >core? > > > >=20 > > > > Another input for this decision is kern/173322. Currently on x86, > > > > atomic operations within kernel modules are implemented using calls > > > > to code in the kernel, which do or don't use lock prefixes > > > > depending > > > > on whethur the kernel was built as SMP. My proposed change changes > > > > kernel modules to inline atomic operations but always include lock > > > > prefixes (effectively reverting r49999). I'm appreciate anyone who > > > > feels like testing the impact of this change. > > >=20 > > > Presumably a locked atomic op is cheaper than a function call then? > > > The > > > current setup assumes the opposite. > > >=20 > > > I think we should actually do this for atomics in modules on x86: > > >=20 > > > 1) If a module is built standalone, it should do whichever is cheaper: > > > a function call or always use "LOCK". > > >=20 > > > 2) If a module is built as part of the kernel build, it should use in= lined > > > atomics that match what the kernel does. Thus, modules built with= a > > > non-SMP kernel would use inlined atomic ops that do not use LOCK. = We > > > have a way to detect this now (some HAVE_FOO #define added in the = past > > > few years) that we didn't back when this bit of atomic.h was > > > written. > > > > >=20 > > It would be nice to have the LOCK variants available even on UP > > kernels in non-hackish way. For VirtIO, we need to handle an guest > > UP kernel running on an SMP host. Whether this is an #define that > > forces the SMP atomics to be inlined, or if they're exposed with > > an _smp suffix.=20 Could you please, clarify why does UP kernel needs it ? Shouldn't the hypervisor context switching provide neccessary serialization anyway ? > >=20 > > VirtIO currently uses mb() to enforce ordering. I have a patch > > to change to use atomic(9), but can only do so when VirtIO is > > included in the an SMP kernel (among other constraints - must > > have 16-bit atomic operations too). > >=20 > > (FreeBSD's VirtIO is x86 only for now - but that will be changing > > soon; I haven't looked if other arch's atomic(9) behave differently > > for UP/SMP.) >=20 > Only x86 does this weirdness. The simplest workaround might be to require > guest kernels to be compiled with SMP for now. >=20 > --=20 > John Baldwin > _______________________________________________ > 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" --5dzPFofyJ6dbelGf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ9HOsAAoJEJDCuSvBvK1B56gP/0iKE8Dz7UabdPih8xmRPu96 9tVVCaaM7XC4Jr+JnO53WRuajrbj+XUETvNp81SQXxB9+4XJtpVLDyoHFOXKlMTV kvCGYX2mgxuy/oyQaEvSEc0XpPEfxEV4DZ/7q3dtWFumQEhwYXElDMS9E/z+3zgx 5k5JeRX4U5BmratmzNmcEwRedmSuxxh5bFmbmSFkykiWyYU0jLMzMGJWwXVoNEFJ R2Tk1Gr8M/+oHko6IjMyyiwFRr+FgP+wMB3KJfPQaZl6hLfxLWlmwM1hTuyVOeQZ +jWHPwcS+DUMJQuD0oSSc7y3DOeSTCjQZACJI1syBWgi9SsysiF2Hf0KC+/F8FtT L/HCFRPrSlCOpQEtBQHGFy3Ywzz8abpam7cViaJYWPsnxgd6CssDde4waLUZKUa+ iJRwtjVpmTnvtac37illdqkfhAWMNucp7w/BD+2S0O4s4GFUZvhG2wziNwmjEY8Z u2CGcKoYNN7Xi9QWR3x6iZdFEr4dV7FPePT6cHq5PzXoz2AmZgl0aSiw0UZmuffI sR8vrYsy2xfqaYAjpriEymGaPw1UVLoFR9nGjb4IVPE39TC9ip5n1Sv5DvhmtGkB d2DUMzu1rURskZz0S/CC1aHc+rSyt7bwNmJZ0tlp+nW9GIg/WES7qZKNfhLTYqo+ rD2AmuUkRhWmhNbxuWoH =V+NN -----END PGP SIGNATURE----- --5dzPFofyJ6dbelGf-- From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 21:42:19 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 B380BC51; Mon, 14 Jan 2013 21:42:19 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 919C1D06; Mon, 14 Jan 2013 21:42:19 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (unknown [64.25.27.130]) by elvis.mu.org (Postfix) with ESMTPSA id D13DE1A3CD7; Mon, 14 Jan 2013 13:42:18 -0800 (PST) Message-ID: <50F47BB8.9000409@mu.org> Date: Mon, 14 Jan 2013 16:42:16 -0500 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: John Baldwin Subject: Re: [PATCH] Don't imply TCP and UDP socket options are bitmasks References: <201301141550.13577.jhb@freebsd.org> In-Reply-To: <201301141550.13577.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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, 14 Jan 2013 21:42:19 -0000 Wouldn't a comment over the code suffice? Something like your email as a header would actually work very nicely! I think just using decimal would be more confusing than explicitly calling it out like: /* begin enumerated (not bitmask) socket option specifiers */ #define TCP_MAXSEG 0x02 /* set maximum segment size */ #define TCP_NOPUSH 0x04 /* don't push last block of write */ #define TCP_NOOPT 0x08 /* don't use TCP options */ #define TCP_MD5SIG 0x10 /* use MD5 digests (RFC2385) */ /* end enumerated socket option specifiers */ On 1/14/13 3:50 PM, John Baldwin wrote: > The constants used for TCP and UDP socket options (TCP_NODELAY, etc.) are > currently defined as hex values that are individual bits. However, socket > options are never masked together, they are used as a simple enumeration of > discrete values. Using a bitmask forces us to run out of bits and makes it > harder for vendors to try to use a high range of values for local custom > options (hoping that they never conflict with a new option value added in > stock FreeBSD). > > The socket options in do use bitmasks for the low bits because > they map directly to bits so_options, but then they start a simple enumeration > at 0x1000. TCP and UDP socket options do not directly map to bits in a flags > field in the PCB (e.g. TF_NODELAY != TCP_NODELAY). I would like to change the > representation of the constants to be decimal instead of hex and encourage new > options to fill in the gaps between the existing values. This would preserve > the existing ABI but keep things more sane in the future (I believe). The > diff is this: > > Index: netinet/tcp.h > =================================================================== > --- netinet/tcp.h (revision 245225) > +++ netinet/tcp.h (working copy) > @@ -151,18 +151,18 @@ > /* > * User-settable options (used with setsockopt). > */ > -#define TCP_NODELAY 0x01 /* don't delay send to coalesce packets */ > +#define TCP_NODELAY 1 /* don't delay send to coalesce packets */ > #if __BSD_VISIBLE > -#define TCP_MAXSEG 0x02 /* set maximum segment size */ > -#define TCP_NOPUSH 0x04 /* don't push last block of write */ > -#define TCP_NOOPT 0x08 /* don't use TCP options */ > -#define TCP_MD5SIG 0x10 /* use MD5 digests (RFC2385) */ > -#define TCP_INFO 0x20 /* retrieve tcp_info structure */ > -#define TCP_CONGESTION 0x40 /* get/set congestion control algorithm */ > -#define TCP_KEEPINIT 0x80 /* N, time to establish connection */ > -#define TCP_KEEPIDLE 0x100 /* L,N,X start keeplives after this period */ > -#define TCP_KEEPINTVL 0x200 /* L,N interval between keepalives */ > -#define TCP_KEEPCNT 0x400 /* L,N number of keepalives before close */ > +#define TCP_MAXSEG 2 /* set maximum segment size */ > +#define TCP_NOPUSH 4 /* don't push last block of write */ > +#define TCP_NOOPT 8 /* don't use TCP options */ > +#define TCP_MD5SIG 16 /* use MD5 digests (RFC2385) */ > +#define TCP_INFO 32 /* retrieve tcp_info structure */ > +#define TCP_CONGESTION 64 /* get/set congestion control algorithm */ > +#define TCP_KEEPINIT 128 /* N, time to establish connection */ > +#define TCP_KEEPIDLE 256 /* L,N,X start keeplives after this period */ > +#define TCP_KEEPINTVL 512 /* L,N interval between keepalives */ > +#define TCP_KEEPCNT 1024 /* L,N number of keepalives before close */ > > #define TCP_CA_NAME_MAX 16 /* max congestion control name length */ > > Index: netinet/udp.h > =================================================================== > --- netinet/udp.h (revision 245225) > +++ netinet/udp.h (working copy) > @@ -48,7 +48,7 @@ > /* > * User-settable options (used with setsockopt). > */ > -#define UDP_ENCAP 0x01 > +#define UDP_ENCAP 1 > > > /* > From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 21:58:00 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 6A46F521; Mon, 14 Jan 2013 21:58:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2DD4BDF5; Mon, 14 Jan 2013 21:58:00 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 99A1EB945; Mon, 14 Jan 2013 16:57:59 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: [PATCH] Don't imply TCP and UDP socket options are bitmasks Date: Mon, 14 Jan 2013 16:56:36 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <201301141550.13577.jhb@freebsd.org> <50F47BB8.9000409@mu.org> In-Reply-To: <50F47BB8.9000409@mu.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301141656.37175.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 14 Jan 2013 16:57:59 -0500 (EST) Cc: Alfred Perlstein , 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, 14 Jan 2013 21:58:00 -0000 On Monday, January 14, 2013 4:42:16 pm Alfred Perlstein wrote: > Wouldn't a comment over the code suffice? > > Something like your email as a header would actually work very nicely! > > I think just using decimal would be more confusing than explicitly > calling it out like: > > /* begin enumerated (not bitmask) socket option specifiers */ > #define TCP_MAXSEG 0x02 /* set maximum segment size */ > #define TCP_NOPUSH 0x04 /* don't push last block of write */ > #define TCP_NOOPT 0x08 /* don't use TCP options */ > #define TCP_MD5SIG 0x10 /* use MD5 digests (RFC2385) */ > /* end enumerated socket option specifiers */ I have a patch I'll post next which will add a new option as '3'. I think that will make it more obvious and avoid having new options follow the old pattern. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 21:58:01 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 AA5DD522 for ; Mon, 14 Jan 2013 21:58:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8697FDF6 for ; Mon, 14 Jan 2013 21:58:01 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CCCA9B95B; Mon, 14 Jan 2013 16:58:00 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: To SMP or not to SMP Date: Mon, 14 Jan 2013 16:57:58 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <330287752.17.1358057713463.JavaMail.root@daemoninthecloset.org> <201301141507.50250.jhb@freebsd.org> <20130114210756.GM2561@kib.kiev.ua> In-Reply-To: <20130114210756.GM2561@kib.kiev.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201301141657.58727.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 14 Jan 2013 16:58:00 -0500 (EST) Cc: Konstantin Belousov , Peter Jeremy , Bryan Venteicher 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, 14 Jan 2013 21:58:01 -0000 On Monday, January 14, 2013 4:07:56 pm Konstantin Belousov wrote: > On Mon, Jan 14, 2013 at 03:07:50PM -0500, John Baldwin wrote: > > On Sunday, January 13, 2013 1:15:13 am Bryan Venteicher wrote: > > > > > > ----- Original Message ----- > > > > From: "John Baldwin" > > > > To: freebsd-net@freebsd.org > > > > Cc: "Barney Cordoba" , "Peter Jeremy" > > > > Sent: Friday, January 11, 2013 9:39:17 AM > > > > Subject: Re: To SMP or not to SMP > > > > > > > > On Thursday, January 10, 2013 02:36:59 PM Peter Jeremy wrote: > > > > > On 2013-Jan-07 18:25:58 -0800, Barney Cordoba > > > > > > > > > wrote: > > > > > >I have a situation where I have to run 9.1 on an old single core > > > > > >box. Does anyone have a handle on whether it's better to build a > > > > > >non > > > > > >SMP kernel or to just use a standard SMP build with just the one > > > > > >core? > > > > > > > > > > Another input for this decision is kern/173322. Currently on x86, > > > > > atomic operations within kernel modules are implemented using calls > > > > > to code in the kernel, which do or don't use lock prefixes > > > > > depending > > > > > on whethur the kernel was built as SMP. My proposed change changes > > > > > kernel modules to inline atomic operations but always include lock > > > > > prefixes (effectively reverting r49999). I'm appreciate anyone who > > > > > feels like testing the impact of this change. > > > > > > > > Presumably a locked atomic op is cheaper than a function call then? > > > > The > > > > current setup assumes the opposite. > > > > > > > > I think we should actually do this for atomics in modules on x86: > > > > > > > > 1) If a module is built standalone, it should do whichever is cheaper: > > > > a function call or always use "LOCK". > > > > > > > > 2) If a module is built as part of the kernel build, it should use inlined > > > > atomics that match what the kernel does. Thus, modules built with a > > > > non-SMP kernel would use inlined atomic ops that do not use LOCK. We > > > > have a way to detect this now (some HAVE_FOO #define added in the past > > > > few years) that we didn't back when this bit of atomic.h was > > > > written. > > > > > > > > > > It would be nice to have the LOCK variants available even on UP > > > kernels in non-hackish way. For VirtIO, we need to handle an guest > > > UP kernel running on an SMP host. Whether this is an #define that > > > forces the SMP atomics to be inlined, or if they're exposed with > > > an _smp suffix. > Could you please, clarify why does UP kernel needs it ? > Shouldn't the hypervisor context switching provide neccessary serialization > anyway ? I thought this, too, but in the case of virtio you are presumably sychronizing with other threads in the hypervisor itself which might be running concurrently on another physical CPU. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 22:12:18 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 C6E7A9C4; Mon, 14 Jan 2013 22:12:18 +0000 (UTC) (envelope-from bryanv@daemoninthecloset.org) Received: from torment.daemoninthecloset.org (ip-static-94-242-209-234.as5577.net [94.242.209.234]) by mx1.freebsd.org (Postfix) with ESMTP id 5BBBFEAD; Mon, 14 Jan 2013 22:12:17 +0000 (UTC) Received: from sage.daemoninthecloset.org (unknown [70.114.209.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sage.daemoninthecloset.org", Issuer "daemoninthecloset.org" (verified OK)) by torment.daemoninthecloset.org (Postfix) with ESMTPS id 7F86542C0858; Mon, 14 Jan 2013 23:14:14 +0100 (CET) X-Virus-Scanned: amavisd-new at daemoninthecloset.org Received: from sage.daemoninthecloset.org (sage.daemoninthecloset.org [127.0.1.1]) by sage.daemoninthecloset.org (Postfix) with ESMTP id 35D607AF0E; Mon, 14 Jan 2013 16:12:10 -0600 (CST) Date: Mon, 14 Jan 2013 16:12:09 -0600 (CST) From: Bryan Venteicher To: John Baldwin Message-ID: <1893331462.132.1358201529856.JavaMail.root@daemoninthecloset.org> In-Reply-To: <201301141657.58727.jhb@freebsd.org> Subject: Re: To SMP or not to SMP MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.51.1.14] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - GC23 (Mac)/7.2.0_GA_2669) Cc: Konstantin Belousov , freebsd-net@freebsd.org, Peter Jeremy 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, 14 Jan 2013 22:12:18 -0000 ----- Original Message ----- > From: "John Baldwin" > To: freebsd-net@freebsd.org > Cc: "Konstantin Belousov" , "Bryan Venteicher" , "Peter Jeremy" > > Sent: Monday, January 14, 2013 3:57:58 PM > Subject: Re: To SMP or not to SMP > > On Monday, January 14, 2013 4:07:56 pm Konstantin Belousov wrote: > > On Mon, Jan 14, 2013 at 03:07:50PM -0500, John Baldwin wrote: > > > On Sunday, January 13, 2013 1:15:13 am Bryan Venteicher wrote: > > > > > > > > ----- Original Message ----- > > > > > From: "John Baldwin" > > > > > To: freebsd-net@freebsd.org > > > > > Cc: "Barney Cordoba" , "Peter > > > > > Jeremy" > > > > > > Sent: Friday, January 11, 2013 9:39:17 AM > > > > > Subject: Re: To SMP or not to SMP > > > > > > > > > > On Thursday, January 10, 2013 02:36:59 PM Peter Jeremy wrote: > > > > > > On 2013-Jan-07 18:25:58 -0800, Barney Cordoba > > > > > > > > > > > wrote: > > > > > > >I have a situation where I have to run 9.1 on an old > > > > > > >single core > > > > > > >box. Does anyone have a handle on whether it's better to > > > > > > >build a > > > > > > >non > > > > > > >SMP kernel or to just use a standard SMP build with just > > > > > > >the one > > > > > > >core? > > > > > > > > > > > > Another input for this decision is kern/173322. Currently > > > > > > on x86, > > > > > > atomic operations within kernel modules are implemented > > > > > > using calls > > > > > > to code in the kernel, which do or don't use lock prefixes > > > > > > depending > > > > > > on whethur the kernel was built as SMP. My proposed change > > > > > > changes > > > > > > kernel modules to inline atomic operations but always > > > > > > include lock > > > > > > prefixes (effectively reverting r49999). I'm appreciate > > > > > > anyone who > > > > > > feels like testing the impact of this change. > > > > > > > > > > Presumably a locked atomic op is cheaper than a function call > > > > > then? > > > > > The > > > > > current setup assumes the opposite. > > > > > > > > > > I think we should actually do this for atomics in modules on > > > > > x86: > > > > > > > > > > 1) If a module is built standalone, it should do whichever is > > > > > cheaper: > > > > > a function call or always use "LOCK". > > > > > > > > > > 2) If a module is built as part of the kernel build, it > > > > > should use > inlined > > > > > atomics that match what the kernel does. Thus, modules > > > > > built with > a > > > > > non-SMP kernel would use inlined atomic ops that do not > > > > > use LOCK. > We > > > > > have a way to detect this now (some HAVE_FOO #define added > > > > > in the > past > > > > > few years) that we didn't back when this bit of atomic.h > > > > > was > > > > > written. > > > > > > > > > > > > > It would be nice to have the LOCK variants available even on UP > > > > kernels in non-hackish way. For VirtIO, we need to handle an > > > > guest > > > > UP kernel running on an SMP host. Whether this is an #define > > > > that > > > > forces the SMP atomics to be inlined, or if they're exposed > > > > with > > > > an _smp suffix. > > Could you please, clarify why does UP kernel needs it ? > > Shouldn't the hypervisor context switching provide neccessary > > serialization > > anyway ? > > I thought this, too, but in the case of virtio you are presumably > sychronizing with other threads in the hypervisor itself which might > be running concurrently on another physical CPU. > Yes, that is the case to be concerned about. Although, thinking about this a bit more, in VirtIO (at least the current spec), all the shared fields are updated by either the host or guest, not both, so a UP kernel can get by without the LOCK, correct? > -- > John Baldwin > From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 22:17:14 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D7064AC7; Mon, 14 Jan 2013 22:17:14 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id C509AEF5; Mon, 14 Jan 2013 22:17:14 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (unknown [64.25.27.130]) by elvis.mu.org (Postfix) with ESMTPSA id B80AC1A3CD9; Mon, 14 Jan 2013 14:17:13 -0800 (PST) Message-ID: <50F483E8.2040107@mu.org> Date: Mon, 14 Jan 2013 17:17:12 -0500 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: John Baldwin Subject: Re: [PATCH] Don't imply TCP and UDP socket options are bitmasks References: <201301141550.13577.jhb@freebsd.org> <50F47BB8.9000409@mu.org> <201301141656.37175.jhb@freebsd.org> In-Reply-To: <201301141656.37175.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, 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, 14 Jan 2013 22:17:14 -0000 On 1/14/13 4:56 PM, John Baldwin wrote: > On Monday, January 14, 2013 4:42:16 pm Alfred Perlstein wrote: >> Wouldn't a comment over the code suffice? >> >> Something like your email as a header would actually work very nicely! >> >> I think just using decimal would be more confusing than explicitly >> calling it out like: >> >> /* begin enumerated (not bitmask) socket option specifiers */ >> #define TCP_MAXSEG 0x02 /* set maximum segment size */ >> #define TCP_NOPUSH 0x04 /* don't push last block of write */ >> #define TCP_NOOPT 0x08 /* don't use TCP options */ >> #define TCP_MD5SIG 0x10 /* use MD5 digests (RFC2385) */ >> /* end enumerated socket option specifiers */ > I have a patch I'll post next which will add a new option as '3'. I think that > will make it more obvious and avoid having new options follow the old pattern. > Any objection to adding the contents of that email as a comment section? It really would help. -Alfred From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 22:47:11 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 11D4DAAC for ; Mon, 14 Jan 2013 22:47:11 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) by mx1.freebsd.org (Postfix) with ESMTP id D4FB8FE for ; Mon, 14 Jan 2013 22:47:10 +0000 (UTC) Received: by mail-ob0-f169.google.com with SMTP id v19so4419151obq.28 for ; Mon, 14 Jan 2013 14:47:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=dARVi09cK3j8E94dQv8ZmY+ZO3fMxVSne24bX3N+FZU=; b=Ui/6GLqz+ByMSdMxvTHejtqmRvT66tyAPb71fB9bu7Ck0vL/9HlYNfKdHFDj3OXLYw NEKoI0e9yhZEvcJxP3ErTpigPwNX6+sWv0PrYtmQOEUS+y+fxLQGIyIoyDZAKHjIPvrD 17AK3a2UVESSyEJ8CqcjJb0q5fGmT0I32pFBbNrsFAuYmdCBcSc+P3j/2C++H9Q4bUjP pQqhPguXmjKDty941YLIOjVUZmHtwAk4WuGBSOp3QifeJ8YozPxde8WWELeIxADt0jwj rhw7hrFlA0T1tVfXezHc2JzaaHcZhRA7AHUHxw8JVzBc6zkzj97jjLUTiIF7gZOTkhUx Jz7g== MIME-Version: 1.0 Received: by 10.60.1.168 with SMTP id 8mr33926390oen.46.1358203629938; Mon, 14 Jan 2013 14:47:09 -0800 (PST) Received: by 10.60.119.9 with HTTP; Mon, 14 Jan 2013 14:47:09 -0800 (PST) In-Reply-To: <50F483E8.2040107@mu.org> References: <201301141550.13577.jhb@freebsd.org> <50F47BB8.9000409@mu.org> <201301141656.37175.jhb@freebsd.org> <50F483E8.2040107@mu.org> Date: Mon, 14 Jan 2013 14:47:09 -0800 Message-ID: Subject: Re: [PATCH] Don't imply TCP and UDP socket options are bitmasks From: Michael Sierchio To: Alfred Perlstein Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl0TjrkdObkkRHL0+CkpeL6lZfMm2b5h8AsVDj8L6ZtWBUNFKiHhoj0nSDNOFJD0VugwpB4 Cc: freebsd-net@freebsd.org, John Baldwin , 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, 14 Jan 2013 22:47:11 -0000 Change "Don't imply TCP and UDP socket options are bitmasks" to "Don't infer TCP and UDP socket options are bitmasks" - M On Mon, Jan 14, 2013 at 2:17 PM, Alfred Perlstein wrote: > On 1/14/13 4:56 PM, John Baldwin wrote: >> >> On Monday, January 14, 2013 4:42:16 pm Alfred Perlstein wrote: >>> >>> Wouldn't a comment over the code suffice? >>> >>> Something like your email as a header would actually work very nicely! >>> >>> I think just using decimal would be more confusing than explicitly >>> calling it out like: >>> >>> /* begin enumerated (not bitmask) socket option specifiers */ >>> #define TCP_MAXSEG 0x02 /* set maximum segment size */ >>> #define TCP_NOPUSH 0x04 /* don't push last block of write */ >>> #define TCP_NOOPT 0x08 /* don't use TCP options */ >>> #define TCP_MD5SIG 0x10 /* use MD5 digests (RFC2385) */ >>> /* end enumerated socket option specifiers */ >> >> I have a patch I'll post next which will add a new option as '3'. I think >> that >> will make it more obvious and avoid having new options follow the old >> pattern. >> > Any objection to adding the contents of that email as a comment section? It > really would help. > > > -Alfred > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 23:50:53 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 910C6645; Mon, 14 Jan 2013 23:50:53 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from relay1-bcrtfl2.verio.net (relay1-bcrtfl2.verio.net [131.103.218.142]) by mx1.freebsd.org (Postfix) with ESMTP id 465C7370; Mon, 14 Jan 2013 23:50:52 +0000 (UTC) Received: from iad-wprd-xchw01.corp.verio.net (iad-wprd-xchw01.corp.verio.net [198.87.7.164]) by relay1-bcrtfl2.verio.net (Postfix) with ESMTP id AFFDCB03812A; Mon, 14 Jan 2013 18:30:56 -0500 (EST) Thread-Index: Ac3yrzOJ/lxzh+qeSyGQuWm/TVFlFw== Received: from hometx-733b1p1.corp.verio.net ([10.144.2.53]) by iad-wprd-xchw01.corp.verio.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Jan 2013 18:30:54 -0500 Received: by hometx-733b1p1.corp.verio.net (sSMTP sendmail emulation); Mon, 14 Jan 2013 17:30:53 -0600 Date: Mon, 14 Jan 2013 17:30:53 -0600 From: "David DeSimone" To: "John Baldwin" Content-Transfer-Encoding: 7bit Subject: Re: if_vr(4) and DFE520-TX Message-ID: <20130114233053.GL2680@verio.net> Mail-Followup-To: John Baldwin , freebsd-net@freebsd.org, pyunyh@gmail.com, Ruslan Makhmatkhanov Content-class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 References: <50F110AB.1030107@yandex.ru> <20130114061553.GA3531@michelle.cdnetworks.com> <50F3F172.5060903@yandex.ru> <201301141515.29312.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <201301141515.29312.jhb@freebsd.org> Precedence: bulk User-Agent: Mutt/1.5.20 (2009-12-10) X-OriginalArrivalTime: 14 Jan 2013 23:30:55.0065 (UTC) FILETIME=[32E48C90:01CDF2AF] Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Ruslan Makhmatkhanov X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 23:50:53 -0000 John Baldwin wrote: > > On Monday, January 14, 2013 6:52:18 am Ruslan Makhmatkhanov wrote: > > > > http://s2.postimage.org/9nvkrlpqx/IMAG1040.jpg > > http://s2.postimage.org/4qi06hnrt/IMAG1041.jpg > > Did your cards come in a box with a driver CD? The manual I found online > claimed the CD contains drivers for Linux. Those might be useful for > determining which chipset these adapters use. On D-Link's web site there is a link to a Linux driver, which appears to be Donald Becker's driver: /* rtl8139.c: A RealTek RTL8129/8139 Fast Ethernet driver for Linux. */ -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio Inc. makes no warranty that this email is error or virus free. Thank you. From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 00:12:02 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 624A1EA4; Tue, 15 Jan 2013 00:12:02 +0000 (UTC) (envelope-from jlh@FreeBSD.org) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [IPv6:2a01:e0c:1:1599::14]) by mx1.freebsd.org (Postfix) with ESMTP id 5656B6F3; Tue, 15 Jan 2013 00:11:59 +0000 (UTC) Received: from endor.tataz.chchile.org (unknown [82.233.239.98]) by smtp5-g21.free.fr (Postfix) with ESMTP id 314F7D48021; Tue, 15 Jan 2013 01:11:53 +0100 (CET) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id 18F877B; Tue, 15 Jan 2013 01:11:53 +0100 (CET) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id D940810D44; Tue, 15 Jan 2013 00:11:52 +0000 (UTC) Date: Tue, 15 Jan 2013 01:11:52 +0100 From: Jeremie Le Hen To: John Baldwin , freebsd-net@freebsd.org, pyunyh@gmail.com, Ruslan Makhmatkhanov Subject: Re: if_vr(4) and DFE520-TX Message-ID: <20130115001152.GB28107@felucia.tataz.chchile.org> Mail-Followup-To: John Baldwin , freebsd-net@freebsd.org, pyunyh@gmail.com, Ruslan Makhmatkhanov References: <50F110AB.1030107@yandex.ru> <20130114061553.GA3531@michelle.cdnetworks.com> <50F3F172.5060903@yandex.ru> <201301141515.29312.jhb@freebsd.org> <20130114233053.GL2680@verio.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130114233053.GL2680@verio.net> User-Agent: Mutt/1.5.21 (2010-09-15) 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, 15 Jan 2013 00:12:02 -0000 On Mon, Jan 14, 2013 at 05:30:53PM -0600, David DeSimone wrote: > John Baldwin wrote: > > > > On Monday, January 14, 2013 6:52:18 am Ruslan Makhmatkhanov wrote: > > > > > > http://s2.postimage.org/9nvkrlpqx/IMAG1040.jpg > > > http://s2.postimage.org/4qi06hnrt/IMAG1041.jpg > > > > Did your cards come in a box with a driver CD? The manual I found online > > claimed the CD contains drivers for Linux. Those might be useful for > > determining which chipset these adapters use. > > On D-Link's web site there is a link to a Linux driver, which appears to > be Donald Becker's driver: > > /* rtl8139.c: A RealTek RTL8129/8139 Fast Ethernet driver for Linux. */ I was looking for it on D-Link website as well, but you've been luckier than me. I found the same thing on a Linux forum. I just did a wild try, can you check if it works? http://people.freebsd.org/~jlh/dlink_dfe520.diff -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 02:30: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 182EC34A for ; Tue, 15 Jan 2013 02:30: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 0AED3CC8 for ; Tue, 15 Jan 2013 02:30:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r0F2U1Zo062119 for ; Tue, 15 Jan 2013 02:30:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r0F2U1QT062118; Tue, 15 Jan 2013 02:30:01 GMT (envelope-from gnats) Date: Tue, 15 Jan 2013 02:30:01 GMT Message-Id: <201301150230.r0F2U1QT062118@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Ingo Flaschberger Subject: Re: kern/175182: [panic] kernel panic on RADIX_MPATH when deleting route X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Ingo Flaschberger List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 02:30:02 -0000 The following reply was made to PR kern/175182; it has been noted by GNATS. From: Ingo Flaschberger To: bug-followup@FreeBSD.org, proler@gmail.com Cc: Subject: Re: kern/175182: [panic] kernel panic on RADIX_MPATH when deleting route Date: Tue, 15 Jan 2013 03:28:30 +0100 This is a multi-part message in MIME format. --------------090708000901090503040100 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit bug is already reported, try this patches: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/173477 and: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/149917 Kind regards, Ingo Flaschberger --------------090708000901090503040100 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit bug is already reported, try this patches:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/173477
and:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/149917

Kind regards,
    Ingo Flaschberger
 --------------090708000901090503040100-- From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 02:40: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 2F30549A for ; Tue, 15 Jan 2013 02: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 1E326D07 for ; Tue, 15 Jan 2013 02:40:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r0F2e17I063706 for ; Tue, 15 Jan 2013 02:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r0F2e0CK063705; Tue, 15 Jan 2013 02:40:01 GMT (envelope-from gnats) Date: Tue, 15 Jan 2013 02:40:01 GMT Message-Id: <201301150240.r0F2e0CK063705@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Ingo Flaschberger Subject: Re: kern/175182: [panic] kernel panic on RADIX_MPATH when deleting route X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Ingo Flaschberger List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 02:40:01 -0000 The following reply was made to PR kern/175182; it has been noted by GNATS. From: Ingo Flaschberger To: bug-followup@FreeBSD.org, proler@gmail.com Cc: Subject: Re: kern/175182: [panic] kernel panic on RADIX_MPATH when deleting route Date: Tue, 15 Jan 2013 03:36:05 +0100 This is a multi-part message in MIME format. --------------020106060107050207070204 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit sorry - posted the wrong ones. this are the right ones: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/173477 and nd6: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/156283 Kind regards, Ingo Flaschberger --------------020106060107050207070204 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit sorry - posted the wrong ones.

this are the right ones:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/173477
and nd6:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/156283

Kind regards,
   Ingo Flaschberger
 --------------020106060107050207070204-- From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 02:44:38 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 0A847611 for ; Tue, 15 Jan 2013 02:44:38 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by mx1.freebsd.org (Postfix) with ESMTP id D6368D50 for ; Tue, 15 Jan 2013 02:44:37 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id bh2so2606920pad.19 for ; Mon, 14 Jan 2013 18:44:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=Nyj0L3/N0xtk1UcIT6Vu9+svav9ZLeW1e3emTGBDUmU=; b=MqxsATxvL7XQh9bqkgkzmUJkfNJYcSkkbKm/XuUavyjHovpY6hGbcE86EwTxAVDP7h EvWRl/atTiqMppNtm+jsPC5ZpusRTZjj/BmZMYcPTPGft6iCRi5IDbKkMUdwqnaQoNFj tXNQyXukbx9aKtrCZERWyYbqGwsjeC/hcU3m3BakRl8PL61chOS4ONF2IDtXrfr35rvK kijHq9J2noIxY7gXXjjINJCwh+U0871BfTatC//FneVj06CZk9R+A4WCexTQ65g4rzQs D9RTa3UGV5fjIk9UWoa4EzA2Dn87/RlYwC3KjobETLYyEkCmj6UrrpKp25BpZ/PuzpID kIkA== X-Received: by 10.68.212.167 with SMTP id nl7mr34232094pbc.12.1358217877068; Mon, 14 Jan 2013 18:44:37 -0800 (PST) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id ot3sm9261401pbb.38.2013.01.14.18.44.34 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 14 Jan 2013 18:44:36 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 15 Jan 2013 11:44:30 +0900 From: YongHyeon PYUN Date: Tue, 15 Jan 2013 11:44:30 +0900 To: Ruslan Makhmatkhanov Subject: Re: if_vr(4) and DFE520-TX Message-ID: <20130115024430.GA3152@michelle.cdnetworks.com> References: <50F110AB.1030107@yandex.ru> <50F14880.4090001@yandex.ru> <50F177E9.3040003@yandex.ru> <20130114061553.GA3531@michelle.cdnetworks.com> <50F3F172.5060903@yandex.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline In-Reply-To: <50F3F172.5060903@yandex.ru> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 02:44:38 -0000 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Jan 14, 2013 at 03:52:18PM +0400, Ruslan Makhmatkhanov wrote: > YongHyeon PYUN wrote on 14.01.2013 10:15: > >On Sat, Jan 12, 2013 at 06:49:13PM +0400, Ruslan Makhmatkhanov wrote: > >>Ok, I got some details. It's an DFE-520TX (/C1 or rev. C1). I crafted an > >>patch attached, but whenever kldloading the modified if_vr, I got this: > > [...] > > >>I also tried to apply VR_Q_NEEDALIGN quirk, but nothing is changed. Any > >>hints? > > > >I recall D-Link was one of notorious vendor which used to > >completely change its chip set in later revisions without notice. So > >I'm afraid the controller you have may not be a VIA manufactured > >one. > >Could you take a picture of the chip set of controller and let > >others see it? I guess it could be a RealTek 8139 or 8139C+. > > Here they are. Both front and back for the case (see no traces of > RealTek though): > > http://s2.postimage.org/9nvkrlpqx/IMAG1040.jpg > http://s2.postimage.org/4qi06hnrt/IMAG1041.jpg Thanks. Try attached patch and let me know how it works. If that patch does not work, try setting a loader tunable like the following. dev.rl.0.prefer_iomap=0 --6c2NcOVqGQ03X4Wi Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="dlink_dfe520.diff" diff -r ffd9aeb1e7ef sys/dev/re/if_re.c --- a/sys/dev/re/if_re.c Mon May 07 23:58:27 2012 +0200 +++ b/sys/dev/re/if_re.c Tue Jan 15 01:10:46 2013 +0100 @@ -174,6 +174,8 @@ static const struct rl_type const re_devs[] = { { DLINK_VENDORID, DLINK_DEVICEID_528T, 0, "D-Link DGE-528(T) Gigabit Ethernet Adapter" }, + { DLINK_VENDORID, DLINK_DEVICEID_520TX, 0, + "D-Link DFE-520(TX) Gigabit Ethernet Adapter" }, { DLINK_VENDORID, DLINK_DEVICEID_530T_REVC, 0, "D-Link DGE-530(T) Gigabit Ethernet Adapter" }, { RT_VENDORID, RT_DEVICEID_8139, 0, @@ -1214,7 +1216,7 @@ * Because RTL8169SC does not seem to work when memory mapping * is used always activate io mapping. */ - if (devid == RT_DEVICEID_8169SC) + if (devid == RT_DEVICEID_8169SC || devid == DLINK_DEVICEID_520TX) prefer_iomap = 1; if (prefer_iomap == 0) { sc->rl_res_id = PCIR_BAR(1); diff -r ffd9aeb1e7ef sys/pci/if_rlreg.h --- a/sys/pci/if_rlreg.h Mon May 07 23:58:27 2012 +0200 +++ b/sys/pci/if_rlreg.h Tue Jan 15 01:10:46 2013 +0100 @@ -1048,6 +1048,11 @@ #define DLINK_DEVICEID_530TXPLUS 0x1300 /* + * D-Link DFE-520TX device ID + */ +#define DLINK_DEVICEID_520TX 0x4200 + +/* * D-Link DFE-5280T device ID */ #define DLINK_DEVICEID_528T 0x4300 --6c2NcOVqGQ03X4Wi-- From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 03:10:39 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 508DB27D; Tue, 15 Jan 2013 03:10:39 +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 29171F74; Tue, 15 Jan 2013 03:10:39 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r0F3Ad4J071451; Tue, 15 Jan 2013 03:10:39 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r0F3Adwr071447; Tue, 15 Jan 2013 03:10:39 GMT (envelope-from linimon) Date: Tue, 15 Jan 2013 03:10:39 GMT Message-Id: <201301150310.r0F3Adwr071447@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/175153: [tcp] will there miss a FIN when do TSO? 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, 15 Jan 2013 03:10:39 -0000 Old Synopsis: will there miss a FIN when do TSO? New Synopsis: [tcp] will there miss a FIN when do TSO? Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Jan 15 03:10:22 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=175153 From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 05:24:26 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 5D20FC3B; Tue, 15 Jan 2013 05:24:26 +0000 (UTC) (envelope-from cvs-src@yandex.ru) Received: from forward4h.mail.yandex.net (forward4h.mail.yandex.net [IPv6:2a02:6b8:0:f05::4]) by mx1.freebsd.org (Postfix) with ESMTP id 017AC99D; Tue, 15 Jan 2013 05:24:26 +0000 (UTC) Received: from smtp4h.mail.yandex.net (smtp4h.mail.yandex.net [84.201.186.21]) by forward4h.mail.yandex.net (Yandex) with ESMTP id D64AC1B2122E; Tue, 15 Jan 2013 09:24:22 +0400 (MSK) Received: from smtp4h.mail.yandex.net (localhost [127.0.0.1]) by smtp4h.mail.yandex.net (Yandex) with ESMTP id 6F75E2C024C; Tue, 15 Jan 2013 09:24:22 +0400 (MSK) Received: from ctsoff2.webstroy.ru (ctsoff2.webstroy.ru [213.27.12.78]) by smtp4h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id OLHSWflF-OMHiodwd; Tue, 15 Jan 2013 09:24:22 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1358227462; bh=+PhS7BPMh3+8ad20vzztk0wBC6cCyPxjBx/FJWTlFyI=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=MHUdVsKRIzfzBijsHssNvyaiTpuN0becksIXx6ULwBssDpyMui8mWN68RVggln0gi kGOyjo4MVPi7LJc6mbN63NOHR3ywWJcwSdRT7rckyOCJ35r3clFEJlX4Z3o9clqRxQ 8wy5Er5o1F5pld8aHYLMVB9m1LJnr5LJo4BatrUg= Message-ID: <50F4E7FA.8080600@yandex.ru> Date: Tue, 15 Jan 2013 09:24:10 +0400 From: Ruslan Makhmatkhanov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130114 Thunderbird/17.0.2 MIME-Version: 1.0 To: John Baldwin Subject: Re: if_vr(4) and DFE520-TX References: <50F110AB.1030107@yandex.ru> <20130114061553.GA3531@michelle.cdnetworks.com> <50F3F172.5060903@yandex.ru> <201301141515.29312.jhb@freebsd.org> In-Reply-To: <201301141515.29312.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Ruslan Makhmatkhanov 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, 15 Jan 2013 05:24:26 -0000 John Baldwin wrote on 15.01.2013 00:15: > On Monday, January 14, 2013 6:52:18 am Ruslan Makhmatkhanov wrote: >> YongHyeon PYUN wrote on 14.01.2013 10:15: >>> On Sat, Jan 12, 2013 at 06:49:13PM +0400, Ruslan Makhmatkhanov wrote: >>>> Ok, I got some details. It's an DFE-520TX (/C1 or rev. C1). I crafted an >>>> patch attached, but whenever kldloading the modified if_vr, I got this: >> >> [...] >> >>>> I also tried to apply VR_Q_NEEDALIGN quirk, but nothing is changed. Any >>>> hints? >>> >>> I recall D-Link was one of notorious vendor which used to >>> completely change its chip set in later revisions without notice. So >>> I'm afraid the controller you have may not be a VIA manufactured >>> one. >>> Could you take a picture of the chip set of controller and let >>> others see it? I guess it could be a RealTek 8139 or 8139C+. >> >> Here they are. Both front and back for the case (see no traces of >> RealTek though): >> >> http://s2.postimage.org/9nvkrlpqx/IMAG1040.jpg >> http://s2.postimage.org/4qi06hnrt/IMAG1041.jpg > > Did your cards come in a box with a driver CD? The manual I found online > claimed the CD contains drivers for Linux. Those might be useful for > determining which chipset these adapters use. No, it was OEM edition - so, no box, no driver CD. -- Regards, Ruslan Tinderboxing kills... the drives. From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 05:38:23 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 D7583494; Tue, 15 Jan 2013 05:38:23 +0000 (UTC) (envelope-from cvs-src@yandex.ru) Received: from forward3h.mail.yandex.net (forward3h.mail.yandex.net [IPv6:2a02:6b8:0:f05::3]) by mx1.freebsd.org (Postfix) with ESMTP id 8B6A2A80; Tue, 15 Jan 2013 05:38:23 +0000 (UTC) Received: from smtp1h.mail.yandex.net (smtp1h.mail.yandex.net [84.201.187.144]) by forward3h.mail.yandex.net (Yandex) with ESMTP id E5EA513603AC; Tue, 15 Jan 2013 09:38:21 +0400 (MSK) Received: from smtp1h.mail.yandex.net (localhost [127.0.0.1]) by smtp1h.mail.yandex.net (Yandex) with ESMTP id 8B1C2134014C; Tue, 15 Jan 2013 09:38:21 +0400 (MSK) Received: from ctsoff2.webstroy.ru (ctsoff2.webstroy.ru [213.27.12.78]) by smtp1h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id cK0OPrVQ-cL0ml6Gg; Tue, 15 Jan 2013 09:38:21 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1358228301; bh=Oo8LZLd2xbkytYkS9+B69H1xk325E0fPmxZa1e6h/8s=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ML+9HJnEA9tC+1xlVoQQv+iPqg9adEiyBsylRBZmxXikKiFqgsW0jLzdtp1uAxs+t 1cY8nO64FvFsrjx65e2nOYM/qd+OmtQUz+E+JOKDpd6yZCQF1PDRnr4FttW0ivCU8e MZUCAa6T3wtJD5gfVT+FnFzdGbpDsa0BnCXapwjo= Message-ID: <50F4EB42.2070604@yandex.ru> Date: Tue, 15 Jan 2013 09:38:10 +0400 From: Ruslan Makhmatkhanov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130114 Thunderbird/17.0.2 MIME-Version: 1.0 To: pyunyh@gmail.com Subject: Re: if_vr(4) and DFE520-TX References: <50F110AB.1030107@yandex.ru> <50F14880.4090001@yandex.ru> <50F177E9.3040003@yandex.ru> <20130114061553.GA3531@michelle.cdnetworks.com> <50F3F172.5060903@yandex.ru> <20130115024430.GA3152@michelle.cdnetworks.com> In-Reply-To: <20130115024430.GA3152@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeremie Le Hen , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 05:38:23 -0000 YongHyeon PYUN wrote on 15.01.2013 06:44: > On Mon, Jan 14, 2013 at 03:52:18PM +0400, Ruslan Makhmatkhanov wrote: >> YongHyeon PYUN wrote on 14.01.2013 10:15: >>> On Sat, Jan 12, 2013 at 06:49:13PM +0400, Ruslan Makhmatkhanov wrote: >>>> Ok, I got some details. It's an DFE-520TX (/C1 or rev. C1). I crafted an >>>> patch attached, but whenever kldloading the modified if_vr, I got this: >> >> [...] >> >>>> I also tried to apply VR_Q_NEEDALIGN quirk, but nothing is changed. Any >>>> hints? >>> >>> I recall D-Link was one of notorious vendor which used to >>> completely change its chip set in later revisions without notice. So >>> I'm afraid the controller you have may not be a VIA manufactured >>> one. >>> Could you take a picture of the chip set of controller and let >>> others see it? I guess it could be a RealTek 8139 or 8139C+. >> >> Here they are. Both front and back for the case (see no traces of >> RealTek though): >> >> http://s2.postimage.org/9nvkrlpqx/IMAG1040.jpg >> http://s2.postimage.org/4qi06hnrt/IMAG1041.jpg > > Thanks. Try attached patch and let me know how it works. > If that patch does not work, try setting a loader tunable like the > following. > dev.rl.0.prefer_iomap=0 I'll try that today and let you know. Thank you YongHyeon and Jeremie! -- Regards, Ruslan Tinderboxing kills... the drives. From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 06: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 10FFA5E0; Tue, 15 Jan 2013 06:32:24 +0000 (UTC) (envelope-from cvs-src@yandex.ru) Received: from forward4h.mail.yandex.net (forward4h.mail.yandex.net [IPv6:2a02:6b8:0:f05::4]) by mx1.freebsd.org (Postfix) with ESMTP id 8D877EB7; Tue, 15 Jan 2013 06:32:23 +0000 (UTC) Received: from smtp3h.mail.yandex.net (smtp3h.mail.yandex.net [84.201.186.20]) by forward4h.mail.yandex.net (Yandex) with ESMTP id 4B5C91B209C2; Tue, 15 Jan 2013 10:32:18 +0400 (MSK) Received: from smtp3h.mail.yandex.net (localhost [127.0.0.1]) by smtp3h.mail.yandex.net (Yandex) with ESMTP id DFFE51B404A2; Tue, 15 Jan 2013 10:32:17 +0400 (MSK) Received: from ctsoff2.webstroy.ru (ctsoff2.webstroy.ru [213.27.12.78]) by smtp3h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id WHl8xCai-WHlq2QKD; Tue, 15 Jan 2013 10:32:17 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1358231537; bh=SlfxNJ/nhs/xbt7BvgOY4ygMwalHfNGfeZo2P9h9Nm0=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=vMV03WetwgsRgJE2+FBJSa89s8CtGDX6EqPVUs98ZThzJlRASkk9gZrLxilRE8XxW DX7n5V7DOIQpC/kZ6PaQAkHHKaIIYugFYxXlj9Hqebj9w/r/13j49ld5HiMU19p8YL Ew0xVhCKCAC73JrYN56eEI7ewRIIli37W1d7c1lQ= Message-ID: <50F4F7E6.7070004@yandex.ru> Date: Tue, 15 Jan 2013 10:32:06 +0400 From: Ruslan Makhmatkhanov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130114 Thunderbird/17.0.2 MIME-Version: 1.0 To: pyunyh@gmail.com Subject: Re: if_vr(4) and DFE520-TX References: <50F110AB.1030107@yandex.ru> <50F14880.4090001@yandex.ru> <50F177E9.3040003@yandex.ru> <20130114061553.GA3531@michelle.cdnetworks.com> <50F3F172.5060903@yandex.ru> <20130115024430.GA3152@michelle.cdnetworks.com> In-Reply-To: <20130115024430.GA3152@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeremie Le Hen , freebsd-net@freebsd.org, Ruslan Makhmatkhanov 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, 15 Jan 2013 06:32:24 -0000 YongHyeon PYUN wrote on 15.01.2013 06:44: > On Mon, Jan 14, 2013 at 03:52:18PM +0400, Ruslan Makhmatkhanov wrote: >> YongHyeon PYUN wrote on 14.01.2013 10:15: >>> On Sat, Jan 12, 2013 at 06:49:13PM +0400, Ruslan Makhmatkhanov wrote: >>>> Ok, I got some details. It's an DFE-520TX (/C1 or rev. C1). I crafted an >>>> patch attached, but whenever kldloading the modified if_vr, I got this: >> >> [...] >> >>>> I also tried to apply VR_Q_NEEDALIGN quirk, but nothing is changed. Any >>>> hints? >>> >>> I recall D-Link was one of notorious vendor which used to >>> completely change its chip set in later revisions without notice. So >>> I'm afraid the controller you have may not be a VIA manufactured >>> one. >>> Could you take a picture of the chip set of controller and let >>> others see it? I guess it could be a RealTek 8139 or 8139C+. >> >> Here they are. Both front and back for the case (see no traces of >> RealTek though): >> >> http://s2.postimage.org/9nvkrlpqx/IMAG1040.jpg >> http://s2.postimage.org/4qi06hnrt/IMAG1041.jpg > > Thanks. Try attached patch and let me know how it works. > If that patch does not work, try setting a loader tunable like the > following. > dev.rl.0.prefer_iomap=0 Terrific! It's now attaching fine, but network over it doesn't seems working (can't ping/access machine via this interface): re0: flags=8843 metric 0 mtu 1500 options=8209b ether 90:94:e4:82:d5:e6 inet 192.168.0.208 netmask 0xffffff00 broadcast 192.168.0.255 inet6 fe80::9294:e4ff:fe82:d5e6%re0 prefixlen 64 scopeid 0x5 nd6 options=29 media: Ethernet autoselect (100baseTX ) status: active re0@pci0:4:1:0: class=0x020000 card=0x11031186 chip=0x42001186 rev=0x10 hdr=0x00 vendor = 'D-Link System Inc' class = network subclass = ethernet I also tried to add dev.rl.0.prefer_iomap=0 to /boot/loader.conf with no difference. I'll try to experiment with this later this day when there will be no active users on this machine, then let you know the results. Thank you! -- Regards, Ruslan Tinderboxing kills... the drives. From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 06:40:23 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 74DC794A; Tue, 15 Jan 2013 06:40:23 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by mx1.freebsd.org (Postfix) with ESMTP id 4C315F42; Tue, 15 Jan 2013 06:40:23 +0000 (UTC) Received: by mail-pb0-f49.google.com with SMTP id un15so2675140pbc.36 for ; Mon, 14 Jan 2013 22:40:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=vs/RKBQ8PC4UY4TjTAzY1G5HhVJwKzAMFdC1a962ox4=; b=n1WRjtgpPRLkPp24Zv0pAyPpamlwESKxMiIabsLUjoZV7uxZCjSqNbPKha7Hy/E4Oq MUVZpEizXZv4FfQ/e2owEGJ3bcCSkfDIWzX1SG+XxNOPy5qEcJE/xH0niPATnA/X0ZnD KOuyf9BpHsm58GApcWLuYgcOmn+5IqLuSy/z5MJ/WwCd3vO1pXgpwTlh/CoWacMYtz+Y q5tlxmPLtsXGdxuDJWS5MNuTWjcMHgWyjsiHB7Ntn9CS4nmp3xqBhWPAw8vjixA7swpo 1Q0uFGSMitXJkrsAFRKiKqhSxN372qhMG1tKBHQAaaxxeqKy/unBlZbz+KBdyhn9Htax akIw== X-Received: by 10.68.137.234 with SMTP id ql10mr260704534pbb.158.1358232017274; Mon, 14 Jan 2013 22:40:17 -0800 (PST) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id o5sm10260300pay.5.2013.01.14.22.40.14 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 14 Jan 2013 22:40:16 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 15 Jan 2013 15:40:11 +0900 From: YongHyeon PYUN Date: Tue, 15 Jan 2013 15:40:11 +0900 To: Ruslan Makhmatkhanov Subject: Re: if_vr(4) and DFE520-TX Message-ID: <20130115064011.GA1434@michelle.cdnetworks.com> References: <50F110AB.1030107@yandex.ru> <50F14880.4090001@yandex.ru> <50F177E9.3040003@yandex.ru> <20130114061553.GA3531@michelle.cdnetworks.com> <50F3F172.5060903@yandex.ru> <20130115024430.GA3152@michelle.cdnetworks.com> <50F4F7E6.7070004@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50F4F7E6.7070004@yandex.ru> User-Agent: Mutt/1.4.2.3i Cc: Jeremie Le Hen , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 06:40:23 -0000 On Tue, Jan 15, 2013 at 10:32:06AM +0400, Ruslan Makhmatkhanov wrote: > YongHyeon PYUN wrote on 15.01.2013 06:44: > >On Mon, Jan 14, 2013 at 03:52:18PM +0400, Ruslan Makhmatkhanov wrote: > >>YongHyeon PYUN wrote on 14.01.2013 10:15: > >>>On Sat, Jan 12, 2013 at 06:49:13PM +0400, Ruslan Makhmatkhanov wrote: > >>>>Ok, I got some details. It's an DFE-520TX (/C1 or rev. C1). I crafted an > >>>>patch attached, but whenever kldloading the modified if_vr, I got this: > >> > >>[...] > >> > >>>>I also tried to apply VR_Q_NEEDALIGN quirk, but nothing is changed. Any > >>>>hints? > >>> > >>>I recall D-Link was one of notorious vendor which used to > >>>completely change its chip set in later revisions without notice. So > >>>I'm afraid the controller you have may not be a VIA manufactured > >>>one. > >>>Could you take a picture of the chip set of controller and let > >>>others see it? I guess it could be a RealTek 8139 or 8139C+. > >> > >>Here they are. Both front and back for the case (see no traces of > >>RealTek though): > >> > >>http://s2.postimage.org/9nvkrlpqx/IMAG1040.jpg > >>http://s2.postimage.org/4qi06hnrt/IMAG1041.jpg > > > >Thanks. Try attached patch and let me know how it works. > >If that patch does not work, try setting a loader tunable like the > >following. > >dev.rl.0.prefer_iomap=0 > > Terrific! It's now attaching fine, but network over it doesn't seems > working (can't ping/access machine via this interface): Please use my patch. I think rl(4) is the right driver for your controller. Jeremie's patch forces re(4) to attach. > > re0: flags=8843 metric 0 mtu > 1500 > options=8209b > ether 90:94:e4:82:d5:e6 > inet 192.168.0.208 netmask 0xffffff00 broadcast 192.168.0.255 > inet6 fe80::9294:e4ff:fe82:d5e6%re0 prefixlen 64 scopeid 0x5 > nd6 options=29 > media: Ethernet autoselect (100baseTX ) > status: active > > re0@pci0:4:1:0: class=0x020000 card=0x11031186 chip=0x42001186 > rev=0x10 hdr=0x00 > vendor = 'D-Link System Inc' > class = network > subclass = ethernet > > I also tried to add dev.rl.0.prefer_iomap=0 to /boot/loader.conf with no > difference. I'll try to experiment with this later this day when there > will be no active users on this machine, then let you know the results. It's not a valid option when you use re(4). > Thank you! From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 06:47:52 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 C3A67A7F; Tue, 15 Jan 2013 06:47:52 +0000 (UTC) (envelope-from cvs-src@yandex.ru) Received: from forward11.mail.yandex.net (forward11.mail.yandex.net [IPv6:2a02:6b8:0:801::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3C494F83; Tue, 15 Jan 2013 06:47:52 +0000 (UTC) Received: from smtp13.mail.yandex.net (smtp13.mail.yandex.net [95.108.130.68]) by forward11.mail.yandex.net (Yandex) with ESMTP id 81F64E80B7C; Tue, 15 Jan 2013 10:47:50 +0400 (MSK) Received: from smtp13.mail.yandex.net (localhost [127.0.0.1]) by smtp13.mail.yandex.net (Yandex) with ESMTP id 48062E405AB; Tue, 15 Jan 2013 10:47:50 +0400 (MSK) Received: from ctsoff2.webstroy.ru (ctsoff2.webstroy.ru [213.27.12.78]) by smtp13.mail.yandex.net (nwsmtp/Yandex) with ESMTP id lneuqBtu-lne8qpTv; Tue, 15 Jan 2013 10:47:49 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1358232470; bh=82ALIr6lfbQI1NPtaA3Y8h+Elmhq4DQ0Fpz4OSgWYtU=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=w35DS2bajFPhZRIE2SlmfTELSLAU+pbm7OjXtk8MTdFgAleoKXWaQ3KfZZcq/wmpp IhrjNWDhBdCnr2oYMwq5pDjPEO5R6uEv3ohdqJcktMgBQk3n/K+1e1X2khUetpO0TZ prwGQE9ctLRdlUoXPgKQCWPx+zL46ULWgONuW0Rs= Message-ID: <50F4FB8A.6090100@yandex.ru> Date: Tue, 15 Jan 2013 10:47:38 +0400 From: Ruslan Makhmatkhanov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130114 Thunderbird/17.0.2 MIME-Version: 1.0 To: pyunyh@gmail.com Subject: Re: if_vr(4) and DFE520-TX References: <50F110AB.1030107@yandex.ru> <50F14880.4090001@yandex.ru> <50F177E9.3040003@yandex.ru> <20130114061553.GA3531@michelle.cdnetworks.com> <50F3F172.5060903@yandex.ru> <20130115024430.GA3152@michelle.cdnetworks.com> <50F4F7E6.7070004@yandex.ru> <20130115064011.GA1434@michelle.cdnetworks.com> In-Reply-To: <20130115064011.GA1434@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeremie Le Hen , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 06:47:52 -0000 YongHyeon PYUN wrote on 15.01.2013 10:40: > On Tue, Jan 15, 2013 at 10:32:06AM +0400, Ruslan Makhmatkhanov wrote: >> YongHyeon PYUN wrote on 15.01.2013 06:44: >>> On Mon, Jan 14, 2013 at 03:52:18PM +0400, Ruslan Makhmatkhanov wrote: >>>> YongHyeon PYUN wrote on 14.01.2013 10:15: >>>>> On Sat, Jan 12, 2013 at 06:49:13PM +0400, Ruslan Makhmatkhanov wrote: >>>>>> Ok, I got some details. It's an DFE-520TX (/C1 or rev. C1). I crafted an >>>>>> patch attached, but whenever kldloading the modified if_vr, I got this: >>>> >>>> [...] >>>> >>>>>> I also tried to apply VR_Q_NEEDALIGN quirk, but nothing is changed. Any >>>>>> hints? >>>>> >>>>> I recall D-Link was one of notorious vendor which used to >>>>> completely change its chip set in later revisions without notice. So >>>>> I'm afraid the controller you have may not be a VIA manufactured >>>>> one. >>>>> Could you take a picture of the chip set of controller and let >>>>> others see it? I guess it could be a RealTek 8139 or 8139C+. >>>> >>>> Here they are. Both front and back for the case (see no traces of >>>> RealTek though): >>>> >>>> http://s2.postimage.org/9nvkrlpqx/IMAG1040.jpg >>>> http://s2.postimage.org/4qi06hnrt/IMAG1041.jpg >>> >>> Thanks. Try attached patch and let me know how it works. >>> If that patch does not work, try setting a loader tunable like the >>> following. >>> dev.rl.0.prefer_iomap=0 >> >> Terrific! It's now attaching fine, but network over it doesn't seems >> working (can't ping/access machine via this interface): > > Please use my patch. I think rl(4) is the right driver for your > controller. Jeremie's patch forces re(4) to attach. To be honest, your and Jeremie patches are identical. Your patch is against if_re/if_rlreg.h too :) >> re0: flags=8843 metric 0 mtu >> 1500 >> options=8209b >> ether 90:94:e4:82:d5:e6 >> inet 192.168.0.208 netmask 0xffffff00 broadcast 192.168.0.255 >> inet6 fe80::9294:e4ff:fe82:d5e6%re0 prefixlen 64 scopeid 0x5 >> nd6 options=29 >> media: Ethernet autoselect (100baseTX ) >> status: active >> >> re0@pci0:4:1:0: class=0x020000 card=0x11031186 chip=0x42001186 >> rev=0x10 hdr=0x00 >> vendor = 'D-Link System Inc' >> class = network >> subclass = ethernet >> >> I also tried to add dev.rl.0.prefer_iomap=0 to /boot/loader.conf with no >> difference. I'll try to experiment with this later this day when there >> will be no active users on this machine, then let you know the results. > > It's not a valid option when you use re(4). > >> Thank you! Yes, it was unmindful copy/paste, sorry. -- Regards, Ruslan Tinderboxing kills... the drives. From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 06:51:15 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 0A3BAB90; Tue, 15 Jan 2013 06:51:15 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by mx1.freebsd.org (Postfix) with ESMTP id BBAEAFA5; Tue, 15 Jan 2013 06:51:14 +0000 (UTC) Received: by mail-pb0-f45.google.com with SMTP id mc8so2660894pbc.4 for ; Mon, 14 Jan 2013 22:51:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=qFZdu9rx6Trr8alvy1WPOxigO9kEk2EgVXxqdrOyxgA=; b=tdRkm3uulKvIEvg3KvvHCPRIzsoxwdBgKZEoM8IFtmpvlyKmvAxfzC9A0RJiObJgJ4 zfpdgkbuhJW1u9y5lVp+9t1XZ8ibji4Lvh9v62ngYm+TntMCWbbN3U68adWqpUvHR4D7 vfx1A7NiUD3jgS6YTw7onJmq4NG9fgCJ79+2Hk1jl34GvrkrXNPb+9S2Ioi5xa6FOIR2 47W5zmeZckQrfvljnRI/g6+Tqh7IYWIiaEuAPaFF0sj4GzFfk4aP09UzgNa121r+kAMb gy4QMp0rGafi7lhoqfD0cb8MBy47J3b77hLdg78DnDu6ozTx1Ltc8mnwoOYRKZc+r/6V k5Wg== X-Received: by 10.66.85.74 with SMTP id f10mr238867472paz.38.1358232668776; Mon, 14 Jan 2013 22:51:08 -0800 (PST) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id sk1sm9672598pbc.0.2013.01.14.22.51.05 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 14 Jan 2013 22:51:08 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 15 Jan 2013 15:51:03 +0900 From: YongHyeon PYUN Date: Tue, 15 Jan 2013 15:51:03 +0900 To: Ruslan Makhmatkhanov Subject: Re: if_vr(4) and DFE520-TX Message-ID: <20130115065103.GC1434@michelle.cdnetworks.com> References: <50F110AB.1030107@yandex.ru> <50F14880.4090001@yandex.ru> <50F177E9.3040003@yandex.ru> <20130114061553.GA3531@michelle.cdnetworks.com> <50F3F172.5060903@yandex.ru> <20130115024430.GA3152@michelle.cdnetworks.com> <50F4F7E6.7070004@yandex.ru> <20130115064011.GA1434@michelle.cdnetworks.com> <50F4FB8A.6090100@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50F4FB8A.6090100@yandex.ru> User-Agent: Mutt/1.4.2.3i Cc: Jeremie Le Hen , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 06:51:15 -0000 On Tue, Jan 15, 2013 at 10:47:38AM +0400, Ruslan Makhmatkhanov wrote: > YongHyeon PYUN wrote on 15.01.2013 10:40: > >On Tue, Jan 15, 2013 at 10:32:06AM +0400, Ruslan Makhmatkhanov wrote: > >>YongHyeon PYUN wrote on 15.01.2013 06:44: > >>>On Mon, Jan 14, 2013 at 03:52:18PM +0400, Ruslan Makhmatkhanov wrote: > >>>>YongHyeon PYUN wrote on 14.01.2013 10:15: > >>>>>On Sat, Jan 12, 2013 at 06:49:13PM +0400, Ruslan Makhmatkhanov wrote: > >>>>>>Ok, I got some details. It's an DFE-520TX (/C1 or rev. C1). I crafted > >>>>>>an > >>>>>>patch attached, but whenever kldloading the modified if_vr, I got > >>>>>>this: > >>>> > >>>>[...] > >>>> > >>>>>>I also tried to apply VR_Q_NEEDALIGN quirk, but nothing is changed. > >>>>>>Any > >>>>>>hints? > >>>>> > >>>>>I recall D-Link was one of notorious vendor which used to > >>>>>completely change its chip set in later revisions without notice. So > >>>>>I'm afraid the controller you have may not be a VIA manufactured > >>>>>one. > >>>>>Could you take a picture of the chip set of controller and let > >>>>>others see it? I guess it could be a RealTek 8139 or 8139C+. > >>>> > >>>>Here they are. Both front and back for the case (see no traces of > >>>>RealTek though): > >>>> > >>>>http://s2.postimage.org/9nvkrlpqx/IMAG1040.jpg > >>>>http://s2.postimage.org/4qi06hnrt/IMAG1041.jpg > >>> > >>>Thanks. Try attached patch and let me know how it works. > >>>If that patch does not work, try setting a loader tunable like the > >>>following. > >>>dev.rl.0.prefer_iomap=0 > >> > >>Terrific! It's now attaching fine, but network over it doesn't seems > >>working (can't ping/access machine via this interface): > > > >Please use my patch. I think rl(4) is the right driver for your > >controller. Jeremie's patch forces re(4) to attach. > > To be honest, your and Jeremie patches are identical. Your patch is > against if_re/if_rlreg.h too :) Hmm, I don't get it. Diff inlined again. Index: sys/pci/if_rlreg.h =================================================================== --- sys/pci/if_rlreg.h (revision 245199) +++ sys/pci/if_rlreg.h (working copy) @@ -1048,6 +1048,11 @@ struct rl_softc { #define DLINK_DEVICEID_530TXPLUS 0x1300 /* + * D-Link DFE-520TX rev. C1 device ID + */ +#define DLINK_DEVICEID_520TX_REVC1 0x4200 + +/* * D-Link DFE-5280T device ID */ #define DLINK_DEVICEID_528T 0x4300 Index: sys/pci/if_rl.c =================================================================== --- sys/pci/if_rl.c (revision 245199) +++ sys/pci/if_rl.c (working copy) @@ -148,6 +148,8 @@ static const struct rl_type rl_devs[] = { "Delta Electronics 8139 10/100BaseTX" }, { ADDTRON_VENDORID, ADDTRON_DEVICEID_8139, RL_8139, "Addtron Technology 8139 10/100BaseTX" }, + { DLINK_VENDORID, DLINK_DEVICEID_520TX_REVC1, RL_8139, + "D-Link DFE-520TX (rev. C1) 10/100BaseTX" }, { DLINK_VENDORID, DLINK_DEVICEID_530TXPLUS, RL_8139, "D-Link DFE-530TX+ 10/100BaseTX" }, { DLINK_VENDORID, DLINK_DEVICEID_690TXD, RL_8139, > > >>re0: flags=8843 metric 0 mtu > >>1500 > >>options=8209b > >> ether 90:94:e4:82:d5:e6 > >> inet 192.168.0.208 netmask 0xffffff00 broadcast 192.168.0.255 > >> inet6 fe80::9294:e4ff:fe82:d5e6%re0 prefixlen 64 scopeid 0x5 > >> nd6 options=29 > >> media: Ethernet autoselect (100baseTX ) > >> status: active > >> > >>re0@pci0:4:1:0: class=0x020000 card=0x11031186 chip=0x42001186 > >>rev=0x10 hdr=0x00 > >> vendor = 'D-Link System Inc' > >> class = network > >> subclass = ethernet > >> > >>I also tried to add dev.rl.0.prefer_iomap=0 to /boot/loader.conf with no > >>difference. I'll try to experiment with this later this day when there > >>will be no active users on this machine, then let you know the results. > > > >It's not a valid option when you use re(4). > > > >>Thank you! > > Yes, it was unmindful copy/paste, sorry. > > -- > Regards, > Ruslan > > Tinderboxing kills... the drives. From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 08:29:54 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 6894BB7; Tue, 15 Jan 2013 08:29:54 +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 F3FD538F; Tue, 15 Jan 2013 08:29:53 +0000 (UTC) Received: from lstewart1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id 478A37E88D; Tue, 15 Jan 2013 19:29:51 +1100 (EST) Message-ID: <50F5137F.1060207@freebsd.org> Date: Tue, 15 Jan 2013 19:29:51 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120613 Thunderbird/13.0 MIME-Version: 1.0 To: John Baldwin Subject: Re: Some questions about the new TCP congestion control code References: <201301141604.29864.jhb@freebsd.org> In-Reply-To: <201301141604.29864.jhb@freebsd.org> 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: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 08:29:54 -0000 Hi John, On 01/15/13 08:04, John Baldwin wrote: > I was looking at TCP congestion control at work recently and noticed a few Poor you ;) > "odd" things in the current code. First, there is this chunk of code in > cc_ack_received() in tcp_input.c: > > static void inline > cc_ack_received(struct tcpcb *tp, struct tcphdr *th, uint16_t type) > { > INP_WLOCK_ASSERT(tp->t_inpcb); > > tp->ccv->bytes_this_ack = BYTES_THIS_ACK(tp, th); > if (tp->snd_cwnd == min(tp->snd_cwnd, tp->snd_wnd)) > tp->ccv->flags |= CCF_CWND_LIMITED; > else > tp->ccv->flags &= ~CCF_CWND_LIMITED; > > > Due to hysterical raisins, snd_cwnd and snd_wnd are u_long values, not > integers, so the call to min() results in truncation on 64-bit hosts. Good catch, but I don't think it matters in practice as neither snd_cwnd or snd_wnd will grow past the 32-bit boundary. > It should probably be ulmin() instead. However, this line seems to be a really > obfuscated way to just write: > > if (tp->snd_cwnd <= tp->snd_wnd) You are correct, though I'd argue the meaning of the existing code as written is clearer compared to your suggested change. > If that is correct, I would vote for changing this to use the much simpler > logic. Agreed. While I find the existing code slightly clearer in meaning, it's not significant enough to warrant keeping it as is when your suggested change is simpler, fixes a bug and achieves the same thing. Happy for you to change it or I can do it if you prefer. > Secondly, in the particular case I was investigating at work (restart of an > idle connnection), the newreno congestion control code in 8.x and later uses a > different algorithm than in 7. Specifically, in 7 TCP would reuse the same > logic used for an initial cwnd (honoring ss_fltsz). In 8 this no longer > happens (instead, 2 is hardcoded). A guess at a possible fix might look > something like this: > > Index: cc_newreno.c > =================================================================== > --- cc_newreno.c (revision 243660) > +++ cc_newreno.c (working copy) > @@ -169,8 +169,21 @@ newreno_after_idle(struct cc_var *ccv) > if (V_tcp_do_rfc3390) > rw = min(4 * CCV(ccv, t_maxseg), > max(2 * CCV(ccv, t_maxseg), 4380)); > +#if 1 > else > rw = CCV(ccv, t_maxseg) * 2; > +#else > + /* XXX: This is missing a lot of stuff that used to be in 7. */ > +#ifdef INET6 > + else if ((isipv6 ? in6_localaddr(&CCV(ccv, t_inpcb->in6p_faddr)) : > + in_localaddr(CCV(ccv, t_inpcb->inp_faddr)))) > +#else > + else if (in_localaddr(CCV(ccv, t_inpcb->inp_faddr))) > +#endif > + rw = V_ss_fltsz_local * CCV(ccv, t_maxseg); > + else > + rw = V_ss_fltsz * CCV(ccv, t_maxseg); > +#endif > > CCV(ccv, snd_cwnd) = min(rw, CCV(ccv, snd_cwnd)); > } > > (But using the #else clause instead of the current #if 1 code). Was this > change in 8 intentional? It was. Unlike connection initialisation which still honours ss_fltsz in cc_conn_init(), restarting an idle connection based on ss_fltsz seemed particularly dubious and as such was omitted from the refactored code. The ultimate goal was to remove the ss_fltsz hack completely and implement a smarter mechanism, but that hasn't quite happened yet. The removal of ss_fltsz from 10.x without providing a replacement mechanism is not ideal and should probably be addressed. I'm guessing you're not using rfc3390 because you want to override the initial window based on specific local knowledge of the path between sender and receiver? Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 08:45: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 DFEB430B for ; Tue, 15 Jan 2013 08:45:06 +0000 (UTC) (envelope-from ray@dlink.ua) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 624C2654 for ; Tue, 15 Jan 2013 08:45:06 +0000 (UTC) Received: from terran (unknown [192.168.99.1]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPA id 1FF08C4927; Tue, 15 Jan 2013 10:44:59 +0200 (EET) Date: Tue, 15 Jan 2013 10:46:09 +0200 From: Aleksandr Rybalko To: pyunyh@gmail.com Subject: Re: if_vr(4) and DFE520-TX Message-Id: <20130115104609.76c20c2dadecd5f27e4b5b03@dlink.ua> In-Reply-To: <20130114061553.GA3531@michelle.cdnetworks.com> References: <50F110AB.1030107@yandex.ru> <50F14880.4090001@yandex.ru> <50F177E9.3040003@yandex.ru> <20130114061553.GA3531@michelle.cdnetworks.com> Organization: D-Link X-Mailer: Sylpheed 3.2.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Ruslan Makhmatkhanov 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, 15 Jan 2013 08:45:06 -0000 On Mon, 14 Jan 2013 15:15:53 +0900 YongHyeon PYUN wrote: > On Sat, Jan 12, 2013 at 06:49:13PM +0400, Ruslan Makhmatkhanov wrote: > > Ok, I got some details. It's an DFE-520TX (/C1 or rev. C1). I crafted an > > patch attached, but whenever kldloading the modified if_vr, I got this: > > > > kernel: vr0: port 0xd100-0xd1ff > > mem 0xf7c11000-0xf7c110ff irq 19 at device 0.0 on pci4 > > kernel: vr0: Quirks: 0x0 > > kernel: vr0: Revision: 0x10 > > kernel: vr0: reset never completed! > > kernel: vr0: attaching PHYs failed > > kernel: device_attach: vr0 attach returned 6 > > kernel: vr0: port 0xd000-0xd0ff > > mem 0xf7c10000-0xf7c100ff irq 16 at device 1.0 on pci4 > > kernel: vr0: Quirks: 0x0 > > kernel: vr0: Revision: 0x10 > > kernel: vr0: reset never completed! > > kernel: vr0: attaching PHYs failed > > kernel: device_attach: vr0 attach returned 6 > > > > I also tried to apply VR_Q_NEEDALIGN quirk, but nothing is changed. Any > > hints? > > I recall D-Link was one of notorious vendor which used to > completely change its chip set in later revisions without notice. So > I'm afraid the controller you have may not be a VIA manufactured > one. > Could you take a picture of the chip set of controller and let > others see it? I guess it could be a RealTek 8139 or 8139C+. Not so hard, just check board H/W revision also :) > > > > > > > Ruslan Makhmatkhanov wrote on 12.01.2013 15:26: > > > > > >Here is also verbose boot log for what it's worth: > > >http://pastebin.com/SnivrtFr > > > > > >Please keep me in cc:, I'm not subscribed. Thanks. > > > > > >Ruslan Makhmatkhanov wrote on 12.01.2013 11:28: > > >>Hello, > > >> > > >>I bought two D-link DFE520-TX ethernet adapters that supposed to work > > >>with if_vr(4) according to man-page. But the driver cannot attach > > >>(tested in 9.1-R and pfSense 2.0.2/2.1 (8.1-R and 8.3-R respectively)). > > >> > > >>none2@pci0:4:0:0: class=0x020000 card=0x11031186 chip=0x42001186 > > >>rev=0x10 hdr=0x00 > > >> vendor = 'D-Link System Inc' > > >> class = network > > >> subclass = ethernet > > >> > > >>Can please anybody suggest proper changes for > > >>/sys/dev/vr/if_vrreg.h|if_vr.c (pci ids would be enought, right?) to > > >>test if it works. Thanks in advance. > > > > > > > > > -- > > Regards, > > Ruslan > > > > Tinderboxing kills... the drives. > > > diff -uN vr.orig/if_vr.c vr/if_vr.c > > --- vr.orig/if_vr.c 2013-01-12 13:19:28.000000000 +0400 > > +++ vr/if_vr.c 2013-01-12 18:42:52.000000000 +0400 > > @@ -138,6 +138,9 @@ > > { DELTA_VENDORID, DELTA_DEVICEID_RHINE_II, > > VR_Q_NEEDALIGN, > > "Delta Electronics Rhine II 10/100BaseTX" }, > > + { DLINK_VENDORID, DLINK_DEVICEID_RHINE_II, > > + 0, > > + "D-Link System Inc 4200 10/100BaseTX" }, > > { ADDTRON_VENDORID, ADDTRON_DEVICEID_RHINE_II, > > VR_Q_NEEDALIGN, > > "Addtron Technology Rhine II 10/100BaseTX" }, > > diff -uN vr.orig/if_vrreg.h vr/if_vrreg.h > > --- vr.orig/if_vrreg.h 2013-01-12 13:19:28.000000000 +0400 > > +++ vr/if_vrreg.h 2013-01-12 14:29:26.000000000 +0400 > > @@ -557,6 +557,16 @@ > > #define DELTA_DEVICEID_RHINE_II 0x1320 > > > > /* > > + * D-Link System Inc device ID. > > + */ > > +#define DLINK_VENDORID 0x1186 > > + > > +/* > > + * D-Link System Inc device IDs. > > + */ > > +#define DLINK_DEVICEID_RHINE_II 0x4200 > > + > > +/* > > * Addtron vendor ID. > > */ > > #define ADDTRON_VENDORID 0x4033 > _______________________________________________ > 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" -- Aleksandr Rybalko From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 08:49:35 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 1CF0F3DF; Tue, 15 Jan 2013 08:49:35 +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 A7E3A683; Tue, 15 Jan 2013 08:49:34 +0000 (UTC) Received: from lstewart1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id 784E17E88D; Tue, 15 Jan 2013 19:49:33 +1100 (EST) Message-ID: <50F5181D.6020508@freebsd.org> Date: Tue, 15 Jan 2013 19:49:33 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120613 Thunderbird/13.0 MIME-Version: 1.0 To: John Baldwin Subject: Re: [PATCH] Don't imply TCP and UDP socket options are bitmasks References: <201301141550.13577.jhb@freebsd.org> In-Reply-To: <201301141550.13577.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=T_FRT_STOCK2, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 08:49:35 -0000 On 01/15/13 07:50, John Baldwin wrote: > The constants used for TCP and UDP socket options (TCP_NODELAY, etc.) are > currently defined as hex values that are individual bits. However, socket > options are never masked together, they are used as a simple enumeration of > discrete values. Using a bitmask forces us to run out of bits and makes it > harder for vendors to try to use a high range of values for local custom > options (hoping that they never conflict with a new option value added in > stock FreeBSD). Yup. Should we be explicitly #defining the boundary between "bits reserved for FreeBSD" and "bits for private vendor use"? > The socket options in do use bitmasks for the low bits because > they map directly to bits so_options, but then they start a simple enumeration > at 0x1000. TCP and UDP socket options do not directly map to bits in a flags > field in the PCB (e.g. TF_NODELAY != TCP_NODELAY). I would like to change the > representation of the constants to be decimal instead of hex and encourage new > options to fill in the gaps between the existing values. This would preserve > the existing ABI but keep things more sane in the future (I believe). The > diff is this: > > Index: netinet/tcp.h > =================================================================== > --- netinet/tcp.h (revision 245225) > +++ netinet/tcp.h (working copy) > @@ -151,18 +151,18 @@ > /* > * User-settable options (used with setsockopt). > */ > -#define TCP_NODELAY 0x01 /* don't delay send to coalesce packets */ > +#define TCP_NODELAY 1 /* don't delay send to coalesce packets */ > #if __BSD_VISIBLE > -#define TCP_MAXSEG 0x02 /* set maximum segment size */ > -#define TCP_NOPUSH 0x04 /* don't push last block of write */ > -#define TCP_NOOPT 0x08 /* don't use TCP options */ > -#define TCP_MD5SIG 0x10 /* use MD5 digests (RFC2385) */ > -#define TCP_INFO 0x20 /* retrieve tcp_info structure */ > -#define TCP_CONGESTION 0x40 /* get/set congestion control algorithm */ > -#define TCP_KEEPINIT 0x80 /* N, time to establish connection */ > -#define TCP_KEEPIDLE 0x100 /* L,N,X start keeplives after this period */ > -#define TCP_KEEPINTVL 0x200 /* L,N interval between keepalives */ > -#define TCP_KEEPCNT 0x400 /* L,N number of keepalives before close */ > +#define TCP_MAXSEG 2 /* set maximum segment size */ > +#define TCP_NOPUSH 4 /* don't push last block of write */ > +#define TCP_NOOPT 8 /* don't use TCP options */ > +#define TCP_MD5SIG 16 /* use MD5 digests (RFC2385) */ > +#define TCP_INFO 32 /* retrieve tcp_info structure */ > +#define TCP_CONGESTION 64 /* get/set congestion control algorithm */ > +#define TCP_KEEPINIT 128 /* N, time to establish connection */ > +#define TCP_KEEPIDLE 256 /* L,N,X start keeplives after this period */ > +#define TCP_KEEPINTVL 512 /* L,N interval between keepalives */ > +#define TCP_KEEPCNT 1024 /* L,N number of keepalives before close */ > > #define TCP_CA_NAME_MAX 16 /* max congestion control name length */ > > Index: netinet/udp.h > =================================================================== > --- netinet/udp.h (revision 245225) > +++ netinet/udp.h (working copy) > @@ -48,7 +48,7 @@ > /* > * User-settable options (used with setsockopt). > */ > -#define UDP_ENCAP 0x01 > +#define UDP_ENCAP 1 > > > /* > Thumbs up from me, modulo a potential tweak to define the boundary for FreeBSD/private use. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 09:05:03 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D98145BA; Tue, 15 Jan 2013 09:05:03 +0000 (UTC) (envelope-from cvs-src@yandex.ru) Received: from forward4h.mail.yandex.net (forward4h.mail.yandex.net [IPv6:2a02:6b8:0:f05::4]) by mx1.freebsd.org (Postfix) with ESMTP id 836FE6FE; Tue, 15 Jan 2013 09:05:03 +0000 (UTC) Received: from smtp1h.mail.yandex.net (smtp1h.mail.yandex.net [84.201.187.144]) by forward4h.mail.yandex.net (Yandex) with ESMTP id 503B51B21B34; Tue, 15 Jan 2013 13:05:02 +0400 (MSK) Received: from smtp1h.mail.yandex.net (localhost [127.0.0.1]) by smtp1h.mail.yandex.net (Yandex) with ESMTP id C1F9B13402EB; Tue, 15 Jan 2013 13:05:01 +0400 (MSK) Received: from ctsoff2.webstroy.ru (ctsoff2.webstroy.ru [213.27.12.78]) by smtp1h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 500CcIB6-510aP8NY; Tue, 15 Jan 2013 13:05:01 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1358240701; bh=cUpx3GTmnlxHqLe/mvi9yg7jsmlI9PmatdSACQW73zI=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=hXAqpiNvGY3rxKh7WOa1JMYcA2LT8HOYE17mvu5hxXq+KDUWGiXCcvTxFtasAvuE/ By4K9NxlXrLxxBo0alGUtXPYc0/Koe6K+3MFF1pVQvhP95N5izYGQnwTE3xegCYzkB F+N1nmTuYlTEa4jT1YvTr5yMDdJEuIBN1d/NoPHY= Message-ID: <50F51BB1.1000105@yandex.ru> Date: Tue, 15 Jan 2013 13:04:49 +0400 From: Ruslan Makhmatkhanov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130114 Thunderbird/17.0.2 MIME-Version: 1.0 To: pyunyh@gmail.com Subject: Re: [SOLVED] if_vr(4) and DFE520-TX [working with patched if_rl] References: <50F110AB.1030107@yandex.ru> <50F14880.4090001@yandex.ru> <50F177E9.3040003@yandex.ru> <20130114061553.GA3531@michelle.cdnetworks.com> <50F3F172.5060903@yandex.ru> <20130115024430.GA3152@michelle.cdnetworks.com> <50F4F7E6.7070004@yandex.ru> <20130115064011.GA1434@michelle.cdnetworks.com> <50F4FB8A.6090100@yandex.ru> <20130115065103.GC1434@michelle.cdnetworks.com> In-Reply-To: <20130115065103.GC1434@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeremie Le Hen , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 09:05:03 -0000 YongHyeon PYUN wrote on 15.01.2013 10:51: > > Hmm, I don't get it. > Diff inlined again. > > Index: sys/pci/if_rlreg.h > =================================================================== > --- sys/pci/if_rlreg.h (revision 245199) > +++ sys/pci/if_rlreg.h (working copy) > @@ -1048,6 +1048,11 @@ struct rl_softc { > #define DLINK_DEVICEID_530TXPLUS 0x1300 > > /* > + * D-Link DFE-520TX rev. C1 device ID > + */ > +#define DLINK_DEVICEID_520TX_REVC1 0x4200 > + > +/* > * D-Link DFE-5280T device ID > */ > #define DLINK_DEVICEID_528T 0x4300 > Index: sys/pci/if_rl.c > =================================================================== > --- sys/pci/if_rl.c (revision 245199) > +++ sys/pci/if_rl.c (working copy) > @@ -148,6 +148,8 @@ static const struct rl_type rl_devs[] = { > "Delta Electronics 8139 10/100BaseTX" }, > { ADDTRON_VENDORID, ADDTRON_DEVICEID_8139, RL_8139, > "Addtron Technology 8139 10/100BaseTX" }, > + { DLINK_VENDORID, DLINK_DEVICEID_520TX_REVC1, RL_8139, > + "D-Link DFE-520TX (rev. C1) 10/100BaseTX" }, > { DLINK_VENDORID, DLINK_DEVICEID_530TXPLUS, RL_8139, > "D-Link DFE-530TX+ 10/100BaseTX" }, > { DLINK_VENDORID, DLINK_DEVICEID_690TXD, RL_8139, >> Hooray! It is working with if_rl with your patch (loader tunable isn't used). Thanks a lot for this! Can this be committed and merged to 8/9? rl1@pci0:4:1:0: class=0x020000 card=0x11031186 chip=0x42001186 rev=0x10 hdr=0x00 vendor = 'D-Link System Inc' class = network subclass = ethernet rl1: flags=8843 metric 0 mtu 1500 options=2008 ether 90:94:e4:82:d5:e6 inet 192.168.0.208 netmask 0xffffff00 broadcast 192.168.0.255 nd6 options=29 media: Ethernet autoselect (100baseTX ) status: active Ping and all other working fine. -- Regards, Ruslan Tinderboxing kills... the drives. From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 10:42:31 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 36B4E346; Tue, 15 Jan 2013 10:42:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 84B35B33; Tue, 15 Jan 2013 10:42:30 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0FAgIEW060553; Tue, 15 Jan 2013 12:42:18 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0FAgIEW060553 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0FAgGpf060552; Tue, 15 Jan 2013 12:42:16 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 15 Jan 2013 12:42:16 +0200 From: Konstantin Belousov To: Bryan Venteicher Subject: Re: To SMP or not to SMP Message-ID: <20130115104216.GY2561@kib.kiev.ua> References: <201301141657.58727.jhb@freebsd.org> <1893331462.132.1358201529856.JavaMail.root@daemoninthecloset.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="m9Vkydzf3ccYCnyC" Content-Disposition: inline In-Reply-To: <1893331462.132.1358201529856.JavaMail.root@daemoninthecloset.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-net@freebsd.org, Peter Jeremy , John Baldwin 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, 15 Jan 2013 10:42:31 -0000 --m9Vkydzf3ccYCnyC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 14, 2013 at 04:12:09PM -0600, Bryan Venteicher wrote: >=20 >=20 > ----- Original Message ----- > > From: "John Baldwin" > > To: freebsd-net@freebsd.org > > Cc: "Konstantin Belousov" , "Bryan Venteicher" , "Peter Jeremy" > > > > Sent: Monday, January 14, 2013 3:57:58 PM > > Subject: Re: To SMP or not to SMP > >=20 > > On Monday, January 14, 2013 4:07:56 pm Konstantin Belousov wrote: > > > On Mon, Jan 14, 2013 at 03:07:50PM -0500, John Baldwin wrote: > > > > On Sunday, January 13, 2013 1:15:13 am Bryan Venteicher wrote: > > > > >=20 > > > > > ----- Original Message ----- > > > > > > From: "John Baldwin" > > > > > > To: freebsd-net@freebsd.org > > > > > > Cc: "Barney Cordoba" , "Peter > > > > > > Jeremy" > > > > > > > > Sent: Friday, January 11, 2013 9:39:17 AM > > > > > > Subject: Re: To SMP or not to SMP > > > > > >=20 > > > > > > On Thursday, January 10, 2013 02:36:59 PM Peter Jeremy wrote: > > > > > > > On 2013-Jan-07 18:25:58 -0800, Barney Cordoba > > > > > > > > > > > > > wrote: > > > > > > > >I have a situation where I have to run 9.1 on an old > > > > > > > >single core > > > > > > > >box. Does anyone have a handle on whether it's better to > > > > > > > >build a > > > > > > > >non > > > > > > > >SMP kernel or to just use a standard SMP build with just > > > > > > > >the one > > > > > > > >core? > > > > > > >=20 > > > > > > > Another input for this decision is kern/173322. Currently > > > > > > > on x86, > > > > > > > atomic operations within kernel modules are implemented > > > > > > > using calls > > > > > > > to code in the kernel, which do or don't use lock prefixes > > > > > > > depending > > > > > > > on whethur the kernel was built as SMP. My proposed change > > > > > > > changes > > > > > > > kernel modules to inline atomic operations but always > > > > > > > include lock > > > > > > > prefixes (effectively reverting r49999). I'm appreciate > > > > > > > anyone who > > > > > > > feels like testing the impact of this change. > > > > > >=20 > > > > > > Presumably a locked atomic op is cheaper than a function call > > > > > > then? > > > > > > The > > > > > > current setup assumes the opposite. > > > > > >=20 > > > > > > I think we should actually do this for atomics in modules on > > > > > > x86: > > > > > >=20 > > > > > > 1) If a module is built standalone, it should do whichever is > > > > > > cheaper: > > > > > > a function call or always use "LOCK". > > > > > >=20 > > > > > > 2) If a module is built as part of the kernel build, it > > > > > > should use > > inlined > > > > > > atomics that match what the kernel does. Thus, modules > > > > > > built with > > a > > > > > > non-SMP kernel would use inlined atomic ops that do not > > > > > > use LOCK. > > We > > > > > > have a way to detect this now (some HAVE_FOO #define added > > > > > > in the > > past > > > > > > few years) that we didn't back when this bit of atomic.h > > > > > > was > > > > > > written. > > > > > > > > > > >=20 > > > > > It would be nice to have the LOCK variants available even on UP > > > > > kernels in non-hackish way. For VirtIO, we need to handle an > > > > > guest > > > > > UP kernel running on an SMP host. Whether this is an #define > > > > > that > > > > > forces the SMP atomics to be inlined, or if they're exposed > > > > > with > > > > > an _smp suffix. > > > Could you please, clarify why does UP kernel needs it ? > > > Shouldn't the hypervisor context switching provide neccessary > > > serialization > > > anyway ? > >=20 > > I thought this, too, but in the case of virtio you are presumably > > sychronizing with other threads in the hypervisor itself which might > > be running concurrently on another physical CPU. > >=20 >=20 > Yes, that is the case to be concerned about. Although, thinking > about this a bit more, in VirtIO (at least the current spec), all > the shared fields are updated by either the host or guest, not > both, so a UP kernel can get by without the LOCK, correct? >=20 I did not see the spec, so I cannot argue. On the other hands, the barriers have nothing to do with shared access to the same memory location. Barriers prevent seeing paradoxical results from memory accesses, in particular, they ensure that compiler and hardware do not reorder the memory access sequences in the unwanted way. That said, I think that a model where some self-contained blob is only writen by one agent, and only read by another, does not require any barriers on x86 at all. The architecture specifies that the only reordering the hardware is allowed to not hide are reads which could pass writes. --m9Vkydzf3ccYCnyC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ9TKHAAoJEJDCuSvBvK1BewMQAKDUu7Iqtg1+TO0VC2vRaXQg l7m3FW9g3gAgRpFSYX4MREiC4o8CiRLUpCW7rBVdWg4Ohb8hxSRBNeKk4aHvX1MK i8rLKoKoolsTUZnDQV55cEVwMBBu9MMdVUtzTsG8SFBtU5wf/fiwzk99wp66qZK/ gAEm6G0U3Ws5GCI8hB2nKvOxYYjO+bhNWQifWLdZSYLdwpu14AD5o0f9LWwKoVmW rW1t+S00L0+u1ffterdzJyWOJCnu02+AYw8YrMH1nmeNAIU+ioVD7rlJ3kSMwWPa VarJ0Ls2TwwTfmmdLFib+gfPQ+ZxB04zZdfbvU2BqFamNKs5OKtQWvMQaPoeqGJ8 3qrGm5YvMg9ByvV+/pCMAGofwNn4OWvaDLCOOQwCNVqagUiuzNjiuo/OsT2WCya+ ++y7iOCDzwpoviW0BuLShqaVfql3sw3zUm7LjQUe44J8RYeTdm/lKShDbum84CC+ ADwrdW0qG4gIeHe74sTEJXge70YDtrKo1HqrkzQAQ4UR5biG6EzQRASNMIcgCVLh SIYYChZ2UwNw/zYtaGDL6b62QLMkqSwT3FVfrXWafXlYhP4FF92xdPfQQVVxVVFx Az7EweS3qTDA8d2+mqGboVkWVhlyYhO4RzqOTKDWUbbsBcUDj4RHuZFgZpY5L6gd H2pkQdSX+jZVsKq68ZEj =FF8Z -----END PGP SIGNATURE----- --m9Vkydzf3ccYCnyC-- From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 12:47:58 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 A427CE14 for ; Tue, 15 Jan 2013 12:47:58 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by mx1.freebsd.org (Postfix) with ESMTP id 8320D3EC for ; Tue, 15 Jan 2013 12:47:58 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.84,473,1355126400"; d="scan'208";a="7947982" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 15 Jan 2013 04:47:52 -0800 Received: from vmwexceht05-prd.hq.netapp.com (vmwexceht05-prd.hq.netapp.com [10.106.77.35]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r0FClq7d015493 for ; Tue, 15 Jan 2013 04:47:52 -0800 (PST) Received: from VMWEXCEHT06-PRD.hq.netapp.com (10.106.77.104) by vmwexceht05-prd.hq.netapp.com (10.106.77.35) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 15 Jan 2013 04:47:51 -0800 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.51]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.02.0328.009; Tue, 15 Jan 2013 04:47:52 -0800 From: "Eggert, Lars" To: "freebsd-net@freebsd.org" Subject: static kernel with mod_cc? Thread-Topic: static kernel with mod_cc? Thread-Index: AQHN8x6HVw4BAkjodEiXofOIlqMBmg== Date: Tue, 15 Jan 2013 12:47:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 12:47:58 -0000 Hi, mod_cc(4) says: Algorithm modules can be compiled into the kernel or loaded as kernel modules using the kld(4) facility. Maybe I'm dense, but I can't figure out how to statically compile mod_cc mo= dules into the kernel? (I'm using a PAE kernel w/o modules.) Hints appreciated. Thanks, Lars= From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 13:09:02 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 5E49F614 for ; Tue, 15 Jan 2013 13:09:02 +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 0A4B2739 for ; Tue, 15 Jan 2013 13:09:02 +0000 (UTC) Received: from lstewart1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id 8FD787E84A; Wed, 16 Jan 2013 00:09:00 +1100 (EST) Message-ID: <50F554EC.6070303@freebsd.org> Date: Wed, 16 Jan 2013 00:09:00 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120613 Thunderbird/13.0 MIME-Version: 1.0 To: "Eggert, Lars" Subject: Re: static kernel with mod_cc? 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: Tue, 15 Jan 2013 13:09:02 -0000 Hi Lars, On 01/15/13 23:47, Eggert, Lars wrote: > Hi, > > mod_cc(4) says: > > Algorithm modules can be compiled into the kernel or loaded as kernel > modules using the kld(4) facility. > > Maybe I'm dense, but I can't figure out how to statically compile > mod_cc modules into the kernel? (I'm using a PAE kernel w/o > modules.) > > Hints appreciated. You're not dense - the build glue to allow an algorithm to be specified in a kernel config file doesn't exist. It probably should. The hacky way to achieve what you want would be to edit /sys/conf/files and manually add a line like so below the cc_newreno.c line: netinet/cc/cc_.c optional inet | inet6 That will compile the module into the kernel, assuming "options INET" or "options INET6" is in your kernel config file. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 15:12:40 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 F0E9DDC0; Tue, 15 Jan 2013 15:12:40 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by mx1.freebsd.org (Postfix) with ESMTP id CFB46EB2; Tue, 15 Jan 2013 15:12:40 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.84,473,1355126400"; d="scan'208";a="7992358" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 15 Jan 2013 07:12:40 -0800 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r0FFCdZr006773; Tue, 15 Jan 2013 07:12:40 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.51]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0328.009; Tue, 15 Jan 2013 07:12:39 -0800 From: "Eggert, Lars" To: Lawrence Stewart Subject: Re: static kernel with mod_cc? Thread-Topic: static kernel with mod_cc? Thread-Index: AQHN8x6HVw4BAkjodEiXofOIlqMBmphK4tYAgAAiiwA= Date: Tue, 15 Jan 2013 15:12:38 +0000 Message-ID: References: <50F554EC.6070303@freebsd.org> In-Reply-To: <50F554EC.6070303@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 15:12:41 -0000 Hi, On Jan 15, 2013, at 14:09, Lawrence Stewart wrote: > You're not dense - the build glue to allow an algorithm to be specified > in a kernel config file doesn't exist. ah, that explains it. I guess it doesn't exist for siftr either? > The hacky way to achieve what you want would be to edit > /sys/conf/files and manually add a line like so below the > cc_newreno.c line: >=20 > netinet/cc/cc_.c optional inet | inet6 >=20 > That will compile the module into the kernel, assuming "options INET" or > "options INET6" is in your kernel config file. Thanks, will try! Lars From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 19:28: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 0A56EE18; Tue, 15 Jan 2013 19:28:41 +0000 (UTC) (envelope-from bryanv@daemoninthecloset.org) Received: from torment.daemoninthecloset.org (ip-static-94-242-209-234.as5577.net [94.242.209.234]) by mx1.freebsd.org (Postfix) with ESMTP id AAFEEFD; Tue, 15 Jan 2013 19:28:40 +0000 (UTC) Received: from sage.daemoninthecloset.org (unknown [70.114.209.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sage.daemoninthecloset.org", Issuer "daemoninthecloset.org" (verified OK)) by torment.daemoninthecloset.org (Postfix) with ESMTPS id 19E1142C083F; Tue, 15 Jan 2013 20:30:33 +0100 (CET) X-Virus-Scanned: amavisd-new at daemoninthecloset.org Received: from sage.daemoninthecloset.org (sage.daemoninthecloset.org [127.0.1.1]) by sage.daemoninthecloset.org (Postfix) with ESMTP id 0F3927B24A; Tue, 15 Jan 2013 13:28:26 -0600 (CST) Date: Tue, 15 Jan 2013 13:28:25 -0600 (CST) From: Bryan Venteicher To: Konstantin Belousov Message-ID: <1470989805.288.1358278105697.JavaMail.root@daemoninthecloset.org> In-Reply-To: <20130115104216.GY2561@kib.kiev.ua> Subject: Re: To SMP or not to SMP MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.51.1.14] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - GC23 (Mac)/7.2.0_GA_2669) Cc: freebsd-net@freebsd.org, Peter Jeremy , John Baldwin 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, 15 Jan 2013 19:28:41 -0000 ----- Original Message ----- > From: "Konstantin Belousov" > To: "Bryan Venteicher" > Cc: "John Baldwin" , "Peter Jeremy" , freebsd-net@freebsd.org > Sent: Tuesday, January 15, 2013 4:42:16 AM > Subject: Re: To SMP or not to SMP > > On Mon, Jan 14, 2013 at 04:12:09PM -0600, Bryan Venteicher wrote: > > > > > > ----- Original Message ----- > > > From: "John Baldwin" > > > To: freebsd-net@freebsd.org > > > Cc: "Konstantin Belousov" , "Bryan > > > Venteicher" , "Peter Jeremy" > > > > > > Sent: Monday, January 14, 2013 3:57:58 PM > > > Subject: Re: To SMP or not to SMP > > > > > > On Monday, January 14, 2013 4:07:56 pm Konstantin Belousov wrote: > > > > On Mon, Jan 14, 2013 at 03:07:50PM -0500, John Baldwin wrote: > > > > > On Sunday, January 13, 2013 1:15:13 am Bryan Venteicher > > > > > wrote: > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "John Baldwin" > > > > > > > To: freebsd-net@freebsd.org > > > > > > > Cc: "Barney Cordoba" , "Peter > > > > > > > Jeremy" > > > > > > > > > > Sent: Friday, January 11, 2013 9:39:17 AM > > > > > > > Subject: Re: To SMP or not to SMP > > > > > > > > > > > > > > On Thursday, January 10, 2013 02:36:59 PM Peter Jeremy > > > > > > > wrote: > > > > > > > > On 2013-Jan-07 18:25:58 -0800, Barney Cordoba > > > > > > > > > > > > > > > wrote: > > > > > > > > >I have a situation where I have to run 9.1 on an old > > > > > > > > >single core > > > > > > > > >box. Does anyone have a handle on whether it's better > > > > > > > > >to > > > > > > > > >build a > > > > > > > > >non > > > > > > > > >SMP kernel or to just use a standard SMP build with > > > > > > > > >just > > > > > > > > >the one > > > > > > > > >core? > > > > > > > > > > > > > > > > Another input for this decision is kern/173322. > > > > > > > > Currently > > > > > > > > on x86, > > > > > > > > atomic operations within kernel modules are implemented > > > > > > > > using calls > > > > > > > > to code in the kernel, which do or don't use lock > > > > > > > > prefixes > > > > > > > > depending > > > > > > > > on whethur the kernel was built as SMP. My proposed > > > > > > > > change > > > > > > > > changes > > > > > > > > kernel modules to inline atomic operations but always > > > > > > > > include lock > > > > > > > > prefixes (effectively reverting r49999). I'm > > > > > > > > appreciate > > > > > > > > anyone who > > > > > > > > feels like testing the impact of this change. > > > > > > > > > > > > > > Presumably a locked atomic op is cheaper than a function > > > > > > > call > > > > > > > then? > > > > > > > The > > > > > > > current setup assumes the opposite. > > > > > > > > > > > > > > I think we should actually do this for atomics in modules > > > > > > > on > > > > > > > x86: > > > > > > > > > > > > > > 1) If a module is built standalone, it should do > > > > > > > whichever is > > > > > > > cheaper: > > > > > > > a function call or always use "LOCK". > > > > > > > > > > > > > > 2) If a module is built as part of the kernel build, it > > > > > > > should use > > > inlined > > > > > > > atomics that match what the kernel does. Thus, > > > > > > > modules > > > > > > > built with > > > a > > > > > > > non-SMP kernel would use inlined atomic ops that do > > > > > > > not > > > > > > > use LOCK. > > > We > > > > > > > have a way to detect this now (some HAVE_FOO #define > > > > > > > added > > > > > > > in the > > > past > > > > > > > few years) that we didn't back when this bit of > > > > > > > atomic.h > > > > > > > was > > > > > > > written. > > > > > > > > > > > > > > > > > > > It would be nice to have the LOCK variants available even > > > > > > on UP > > > > > > kernels in non-hackish way. For VirtIO, we need to handle > > > > > > an > > > > > > guest > > > > > > UP kernel running on an SMP host. Whether this is an > > > > > > #define > > > > > > that > > > > > > forces the SMP atomics to be inlined, or if they're exposed > > > > > > with > > > > > > an _smp suffix. > > > > Could you please, clarify why does UP kernel needs it ? > > > > Shouldn't the hypervisor context switching provide neccessary > > > > serialization > > > > anyway ? > > > > > > I thought this, too, but in the case of virtio you are presumably > > > sychronizing with other threads in the hypervisor itself which > > > might > > > be running concurrently on another physical CPU. > > > > > > > Yes, that is the case to be concerned about. Although, thinking > > about this a bit more, in VirtIO (at least the current spec), all > > the shared fields are updated by either the host or guest, not > > both, so a UP kernel can get by without the LOCK, correct? > > > I did not see the spec, so I cannot argue. On the other hands, the > barriers have nothing to do with shared access to the same memory > location. Barriers prevent seeing paradoxical results from memory > accesses, in particular, they ensure that compiler and hardware do > not reorder the memory access sequences in the unwanted way. > > That said, I think that a model where some self-contained blob is > only writen by one agent, and only read by another, does not require > any barriers on x86 at all. The architecture specifies that the only > reordering the hardware is allowed to not hide are reads which could > pass writes. > I need to refresh from the IA32 manuals, but I'm pretty sure LOCK doesn't end up matter for VirtIO since blobs are updated by either the guest or host. But I think SMP still ends up being required for x86 since atomic_load_acq_foo() on UP has only a compiler membar. From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 20:27:53 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 89B7588D; Tue, 15 Jan 2013 20:27:53 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 62B0063F; Tue, 15 Jan 2013 20:27:53 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9C860B9AD; Tue, 15 Jan 2013 15:27:52 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: [PATCH] Don't imply TCP and UDP socket options are bitmasks Date: Tue, 15 Jan 2013 14:16:07 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <201301141550.13577.jhb@freebsd.org> <50F5181D.6020508@freebsd.org> In-Reply-To: <50F5181D.6020508@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301151416.07231.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 15 Jan 2013 15:27:52 -0500 (EST) Cc: Lawrence Stewart , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 20:27:53 -0000 On Tuesday, January 15, 2013 3:49:33 am Lawrence Stewart wrote: > On 01/15/13 07:50, John Baldwin wrote: > > The constants used for TCP and UDP socket options (TCP_NODELAY, etc.) are > > currently defined as hex values that are individual bits. However, socket > > options are never masked together, they are used as a simple enumeration of > > discrete values. Using a bitmask forces us to run out of bits and makes it > > harder for vendors to try to use a high range of values for local custom > > options (hoping that they never conflict with a new option value added in > > stock FreeBSD). > > Yup. Should we be explicitly #defining the boundary between "bits > reserved for FreeBSD" and "bits for private vendor use"? Oh, we could if you wanted. I'm using 0x1000 locally for both TCP and UDP, but those are completely arbitrary values. Saner ones might be 0x8000000 if we want to do that explicitly. We could perhaps just say that is true for all socket option levels (that is, just define one SO_VENDOR constant or some such but say it applies to all levels)? -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 20:27:54 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 CB80688F; Tue, 15 Jan 2013 20:27:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7111E641; Tue, 15 Jan 2013 20:27:54 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C42ECB918; Tue, 15 Jan 2013 15:27:53 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: Some questions about the new TCP congestion control code Date: Tue, 15 Jan 2013 14:27:50 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <201301141604.29864.jhb@freebsd.org> <50F5137F.1060207@freebsd.org> In-Reply-To: <50F5137F.1060207@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301151427.50932.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 15 Jan 2013 15:27:53 -0500 (EST) Cc: Lawrence Stewart 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, 15 Jan 2013 20:27:54 -0000 On Tuesday, January 15, 2013 3:29:51 am Lawrence Stewart wrote: > Hi John, > > On 01/15/13 08:04, John Baldwin wrote: > > I was looking at TCP congestion control at work recently and noticed a few > > Poor you ;) > > > "odd" things in the current code. First, there is this chunk of code in > > cc_ack_received() in tcp_input.c: > > > > static void inline > > cc_ack_received(struct tcpcb *tp, struct tcphdr *th, uint16_t type) > > { > > INP_WLOCK_ASSERT(tp->t_inpcb); > > > > tp->ccv->bytes_this_ack = BYTES_THIS_ACK(tp, th); > > if (tp->snd_cwnd == min(tp->snd_cwnd, tp->snd_wnd)) > > tp->ccv->flags |= CCF_CWND_LIMITED; > > else > > tp->ccv->flags &= ~CCF_CWND_LIMITED; > > > > > > Due to hysterical raisins, snd_cwnd and snd_wnd are u_long values, not > > integers, so the call to min() results in truncation on 64-bit hosts. > > Good catch, but I don't think it matters in practice as neither snd_cwnd > or snd_wnd will grow past the 32-bit boundary. I have a psyhcotic case using cc_cubic where it seems to grow without bound, though that is a bug in and of itself (and this change did not fix that issue). I ended up not using cc_cubic (more below) and haven't been able to track down the root cause of the delay. I can probably provide a test case to reproduce this if you are interested. > > It should probably be ulmin() instead. However, this line seems to be a really > > obfuscated way to just write: > > > > if (tp->snd_cwnd <= tp->snd_wnd) > > You are correct, though I'd argue the meaning of the existing code as > written is clearer compared to your suggested change. > > > If that is correct, I would vote for changing this to use the much simpler > > logic. > > Agreed. While I find the existing code slightly clearer in meaning, it's > not significant enough to warrant keeping it as is when your suggested > change is simpler, fixes a bug and achieves the same thing. Happy for > you to change it or I can do it if you prefer. I'll leave that to you, thanks. > > Secondly, in the particular case I was investigating at work (restart of an > > idle connnection), the newreno congestion control code in 8.x and later uses a > > different algorithm than in 7. Specifically, in 7 TCP would reuse the same > > logic used for an initial cwnd (honoring ss_fltsz). In 8 this no longer > > happens (instead, 2 is hardcoded). A guess at a possible fix might look > > something like this: > > > > Index: cc_newreno.c > > =================================================================== > > --- cc_newreno.c (revision 243660) > > +++ cc_newreno.c (working copy) > > @@ -169,8 +169,21 @@ newreno_after_idle(struct cc_var *ccv) > > if (V_tcp_do_rfc3390) > > rw = min(4 * CCV(ccv, t_maxseg), > > max(2 * CCV(ccv, t_maxseg), 4380)); > > +#if 1 > > else > > rw = CCV(ccv, t_maxseg) * 2; > > +#else > > + /* XXX: This is missing a lot of stuff that used to be in 7. */ > > +#ifdef INET6 > > + else if ((isipv6 ? in6_localaddr(&CCV(ccv, t_inpcb->in6p_faddr)) : > > + in_localaddr(CCV(ccv, t_inpcb->inp_faddr)))) > > +#else > > + else if (in_localaddr(CCV(ccv, t_inpcb->inp_faddr))) > > +#endif > > + rw = V_ss_fltsz_local * CCV(ccv, t_maxseg); > > + else > > + rw = V_ss_fltsz * CCV(ccv, t_maxseg); > > +#endif > > > > CCV(ccv, snd_cwnd) = min(rw, CCV(ccv, snd_cwnd)); > > } > > > > (But using the #else clause instead of the current #if 1 code). Was this > > change in 8 intentional? > > It was. Unlike connection initialisation which still honours ss_fltsz in > cc_conn_init(), restarting an idle connection based on ss_fltsz seemed > particularly dubious and as such was omitted from the refactored code. > > The ultimate goal was to remove the ss_fltsz hack completely and > implement a smarter mechanism, but that hasn't quite happened yet. The > removal of ss_fltsz from 10.x without providing a replacement mechanism > is not ideal and should probably be addressed. > > I'm guessing you're not using rfc3390 because you want to override the > initial window based on specific local knowledge of the path between > sender and receiver? Correct, in 7.x we had cranked ss_fltsz up to a really high number to prevent the congestion window from collapsing when the connection was idle. We have a bit of a unique workload in that we are using TCP to reliably forward a latency-sensitive datagram stream across a WAN connection with high bandwidth and high RTT. Most of congestion control seems tuned to bulk transfers rather than this sort of use case. The solution we have settled on here is to add a new TCP socket option to disable idle handling so that when an idle connection restarts it keeps its prior congestion window. One other thing I noticed which is may or may not be odd during this, is that if you have a connection with TCP_NODELAY enabled and you fill your cwnd and then you get an ACK back for an earlier small segment (less than MSS), TCP will not send out a "short" segment for the amount of window space released. Instead, it will wait until a full MSS of space is available before sending a packet. I'm not sure if that is the correct behavior with TCP_NODELAY or if we should send "short" segments in that case. Anyway, I'll post a patch of the new socket option I described to see if it is something we want to add. It is an opt-in thing of course and not enabled by default. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 20:27:55 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 4F7C9891 for ; Tue, 15 Jan 2013 20:27:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2EBA9642 for ; Tue, 15 Jan 2013 20:27:55 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 978DAB948; Tue, 15 Jan 2013 15:27:54 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: [PATCH] Don't imply TCP and UDP socket options are bitmasks Date: Tue, 15 Jan 2013 14:32:15 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <201301141550.13577.jhb@freebsd.org> <201301141656.37175.jhb@freebsd.org> <50F483E8.2040107@mu.org> In-Reply-To: <50F483E8.2040107@mu.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301151432.15347.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 15 Jan 2013 15:27:54 -0500 (EST) Cc: Alfred Perlstein 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, 15 Jan 2013 20:27:55 -0000 On Monday, January 14, 2013 5:17:12 pm Alfred Perlstein wrote: > On 1/14/13 4:56 PM, John Baldwin wrote: > > On Monday, January 14, 2013 4:42:16 pm Alfred Perlstein wrote: > >> Wouldn't a comment over the code suffice? > >> > >> Something like your email as a header would actually work very nicely! > >> > >> I think just using decimal would be more confusing than explicitly > >> calling it out like: > >> > >> /* begin enumerated (not bitmask) socket option specifiers */ > >> #define TCP_MAXSEG 0x02 /* set maximum segment size */ > >> #define TCP_NOPUSH 0x04 /* don't push last block of write */ > >> #define TCP_NOOPT 0x08 /* don't use TCP options */ > >> #define TCP_MD5SIG 0x10 /* use MD5 digests (RFC2385) */ > >> /* end enumerated socket option specifiers */ > > I have a patch I'll post next which will add a new option as '3'. I think that > > will make it more obvious and avoid having new options follow the old pattern. > > > Any objection to adding the contents of that email as a comment > section? It really would help. We don't generally do this for other enumerations like ioctl values as it is generally obvious to the reader. I think for UDP having one constant called '1' should be obvious enough. TCP might indeed warrany a comment since it has several existing values that are powers of 2. How about this: /* * User-settable options (used with setsockopt). These are discrete * values and should not be masked together. Many values appear to be * bitmasks for legacy reasons. */ -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 20:51:25 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 357AC34F for ; Tue, 15 Jan 2013 20:51:25 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by mx1.freebsd.org (Postfix) with ESMTP id A5C0B7AE for ; Tue, 15 Jan 2013 20:51:24 +0000 (UTC) Received: by mail-la0-f44.google.com with SMTP id fr10so646046lab.3 for ; Tue, 15 Jan 2013 12:51:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wx/AxtN3kYcT15nER8fpeQ9QRzFY67ccwfGNyt9Znwg=; b=Yc1esCF/fxupqEXG6f3tQMPcZsdxenoRanqb6xQ6Q1szC3RyikAgsX6k3IoW5Wh9Ur agr52JHJmA6CiJo+YwRWgb0LKZxEzfKHpa+q/SnO8Ivi5eM9s4B9eUC4OPx6focciwdm ujX4dOqLvRiylKRylB3NfuK7cLCem47S3JJvY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=wx/AxtN3kYcT15nER8fpeQ9QRzFY67ccwfGNyt9Znwg=; b=hVVrVMsLIF/9Pidr77ji8sM96celaHdDvf/5K6a8tHx+EvYdAoEvdt46eH7pzCreXy AHI4gptkfevZqnit9+hSEngyxOsdqTsjdlTZazO1yip0RU7+uqFYAkpbg8pey04x2xKS aAFf18xZgrD7okoRJmmD5T9f7lJF5r1DK2AUeTW1HO1EhKs/SHBNE/TJPV7bWGgdO0+6 5G5fIVJRZl6D4tqu0hiT/O2VSIpy2q9FbV+UBacwDZ4VjcY3d07lEQEspDr11RqCTbFN QsWs5dCqw0CJviw6W5CzwQW9b3UzCGVlwP63JHdGPMMDZqafpHoxQUAp2WMAKY4HIXBy po3w== Received: by 10.112.82.136 with SMTP id i8mr2427831lby.74.1358283077746; Tue, 15 Jan 2013 12:51:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.30.131 with HTTP; Tue, 15 Jan 2013 12:50:47 -0800 (PST) In-Reply-To: <201301141550.13577.jhb@freebsd.org> References: <201301141550.13577.jhb@freebsd.org> From: Eitan Adler Date: Tue, 15 Jan 2013 15:50:47 -0500 Message-ID: Subject: Re: [PATCH] Don't imply TCP and UDP socket options are bitmasks To: John Baldwin Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmmXjsi6SV3gp/wa6tiwk7DNvJcA96Dh/Usal/X7kO1Bk+VxXOCJ8iHJ3ybXliplHZIY2do Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 20:51:25 -0000 On 14 January 2013 15:50, John Baldwin wrote: > Using a bitmask forces us to run out of bits and makes it > harder for vendors to try to use a high range of values for local custom > options (hoping that they never conflict with a new option value added in > stock FreeBSD). We should explicitly decide and #define the boundary value for custom options. -- Eitan Adler From owner-freebsd-net@FreeBSD.ORG Wed Jan 16 01:31:39 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 66E822C4 for ; Wed, 16 Jan 2013 01:31:39 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-ea0-f176.google.com (mail-ea0-f176.google.com [209.85.215.176]) by mx1.freebsd.org (Postfix) with ESMTP id 06FF1C2C for ; Wed, 16 Jan 2013 01:31:35 +0000 (UTC) Received: by mail-ea0-f176.google.com with SMTP id a13so2971eaa.7 for ; Tue, 15 Jan 2013 17:31:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=EMHQL6hhEWH59khu31ffsyfpFiBz12fatrqN3DOuXGA=; b=gJlCIP3RR47XILte67bIqnWuyG0bqLmOsFPM0OyIJltfwHZ8e0Io0Hss3Up2yg1eUP GIUcTCOGHN5lI5wGtGRP9OR+JE2I/YafLCi4gh+2/S9xWx6SmN4U2iVPr30pisKtRO5Q PlhAl6pIGd3qFiam9pxm4P+cVsH1P+n0GscOwSvss3KC0+PX9TfIoG9DkApUsQkCXgX4 NIEn0RGU/aPYvlL7OIT7VL8vuokUHROZA7d9UmZ9L43LFbOjj4IugavEwokNU0ia9/22 p8NZrjh77sBdM85fxW7As/0ayFEO8wYAarqetjRx0Bq1N32fKrQWgmNr4H7iCpWUhuYm 9uFQ== MIME-Version: 1.0 Received: by 10.14.225.72 with SMTP id y48mr245086646eep.46.1358299404872; Tue, 15 Jan 2013 17:23:24 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.14.0.2 with HTTP; Tue, 15 Jan 2013 17:23:24 -0800 (PST) Date: Tue, 15 Jan 2013 17:23:24 -0800 X-Google-Sender-Auth: 4Tl_Ya13TIFNE9Aoqdc8vGPh-QE Message-ID: Subject: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() From: Luigi Rizzo To: head@freebsd.org, "freebsd-net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: 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: Wed, 16 Jan 2013 01:31:39 -0000 Hi, i found a couple of problems in dev/e1000/if_lem.c::lem_handle_rxtx() , (compare with dev/e1000/if_em.c::em_handle_que() for better understanding): 1. in if_em.c::em_handle_que(), when em_rxeof() exceeds the rx_process_limit, the task is rescheduled so it can complete the work. Conversely, in if_lem.c::lem_handle_rxtx() the lem_rxeof() is only run once, and if there are more pending packets the only chance to drain them is to receive (many) more interrupts. This is a relatively serious problem, because the receiver has a hard time recovering. I'd like to commit a fix to this same as it is done in e1000. 2. in if_em.c::em_handle_que(), interrupts are reenabled unconditionally, whereas lem_handle_rxtx() only enables them if IFF_DRV_RUNNING is set. I cannot really tell what is the correct way here, so I'd like to put a comment there unless there is a good suggestion on what to do. Accesses to the intr register are race-prone anyways (disabled in fastintr, enabled in the rxtx task without holding any lock, and generally accessed under EM_CORE_LOCK in other places), and presumably enabling/disabling the interrupts around activations of the taks is just an optimization (and on a VM, it is actually a pessimization due to the huge cost of VM exits). cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Jan 16 02:25:52 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 268A9FB5; Wed, 16 Jan 2013 02:25:52 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by mx1.freebsd.org (Postfix) with ESMTP id EFAE2ED0; Wed, 16 Jan 2013 02:25:51 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id hz1so484186pad.40 for ; Tue, 15 Jan 2013 18:25:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=6LQr86jNV3FPcpCiY8vcuveB9dTpH3462Jd44eyk+QE=; b=QwSLW2ZFBNknjXrJMUOMbR3lMnhEtE3EDj55085eCkxI4wZlnaXdBe132ynKKsRTcz 97g4lWUdrpbMBRObJO16BNvt1RBz7ZfMqAgHZY3ytbtAXSSffASRsyQU5+Bv4QqDTArx sHRHyyukjQbeaatXoCjDFTOIweOEaeisS69lkKIcag5u0EATT4N0twCB04xyv7ggYJko fvI4Qlw/GdNBURpwRPlKHCRN8ROKO7cycDY3g70/BWp/T8dxZS0op11qebLbnAdkxUF2 /C1kUI1ncWNclSVlhU7QhR7v6oKCrQzly/4aRroAnQVVG/LOnJXKnPLeUZQNx/8bPGXX AUAQ== X-Received: by 10.68.203.129 with SMTP id kq1mr49851090pbc.30.1358303150861; Tue, 15 Jan 2013 18:25:50 -0800 (PST) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id qf7sm11283491pbb.49.2013.01.15.18.25.47 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 15 Jan 2013 18:25:50 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 16 Jan 2013 11:25:44 +0900 From: YongHyeon PYUN Date: Wed, 16 Jan 2013 11:25:44 +0900 To: Ruslan Makhmatkhanov Subject: Re: [SOLVED] if_vr(4) and DFE520-TX [working with patched if_rl] Message-ID: <20130116022544.GB3171@michelle.cdnetworks.com> References: <50F14880.4090001@yandex.ru> <50F177E9.3040003@yandex.ru> <20130114061553.GA3531@michelle.cdnetworks.com> <50F3F172.5060903@yandex.ru> <20130115024430.GA3152@michelle.cdnetworks.com> <50F4F7E6.7070004@yandex.ru> <20130115064011.GA1434@michelle.cdnetworks.com> <50F4FB8A.6090100@yandex.ru> <20130115065103.GC1434@michelle.cdnetworks.com> <50F51BB1.1000105@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50F51BB1.1000105@yandex.ru> User-Agent: Mutt/1.4.2.3i Cc: Jeremie Le Hen , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 02:25:52 -0000 On Tue, Jan 15, 2013 at 01:04:49PM +0400, Ruslan Makhmatkhanov wrote: > YongHyeon PYUN wrote on 15.01.2013 10:51: > > > >Hmm, I don't get it. > >Diff inlined again. > > > >Index: sys/pci/if_rlreg.h > >=================================================================== > >--- sys/pci/if_rlreg.h (revision 245199) > >+++ sys/pci/if_rlreg.h (working copy) > >@@ -1048,6 +1048,11 @@ struct rl_softc { > > #define DLINK_DEVICEID_530TXPLUS 0x1300 > > > > /* > >+ * D-Link DFE-520TX rev. C1 device ID > >+ */ > >+#define DLINK_DEVICEID_520TX_REVC1 0x4200 > >+ > >+/* > > * D-Link DFE-5280T device ID > > */ > > #define DLINK_DEVICEID_528T 0x4300 > >Index: sys/pci/if_rl.c > >=================================================================== > >--- sys/pci/if_rl.c (revision 245199) > >+++ sys/pci/if_rl.c (working copy) > >@@ -148,6 +148,8 @@ static const struct rl_type rl_devs[] = { > > "Delta Electronics 8139 10/100BaseTX" }, > > { ADDTRON_VENDORID, ADDTRON_DEVICEID_8139, RL_8139, > > "Addtron Technology 8139 10/100BaseTX" }, > >+ { DLINK_VENDORID, DLINK_DEVICEID_520TX_REVC1, RL_8139, > >+ "D-Link DFE-520TX (rev. C1) 10/100BaseTX" }, > > { DLINK_VENDORID, DLINK_DEVICEID_530TXPLUS, RL_8139, > > "D-Link DFE-530TX+ 10/100BaseTX" }, > > { DLINK_VENDORID, DLINK_DEVICEID_690TXD, RL_8139, > >> > > Hooray! It is working with if_rl with your patch (loader tunable isn't > used). Thanks a lot for this! > > Can this be committed and merged to 8/9? > Yes, committed in r245485. I will MFC to stable 9/8 after a week. > rl1@pci0:4:1:0: class=0x020000 card=0x11031186 chip=0x42001186 > rev=0x10 hdr=0x00 > vendor = 'D-Link System Inc' > class = network > subclass = ethernet > > > rl1: flags=8843 metric 0 mtu 1500 > options=2008 > ether 90:94:e4:82:d5:e6 > inet 192.168.0.208 netmask 0xffffff00 broadcast 192.168.0.255 > nd6 options=29 > media: Ethernet autoselect (100baseTX ) > status: active > > Ping and all other working fine. > Thanks for testing! > -- > Regards, > Ruslan > > Tinderboxing kills... the drives. From owner-freebsd-net@FreeBSD.ORG Wed Jan 16 05:43:57 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 9645DE12 for ; Wed, 16 Jan 2013 05:43:57 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) by mx1.freebsd.org (Postfix) with ESMTP id 42F1A99E for ; Wed, 16 Jan 2013 05:43:56 +0000 (UTC) Received: by mail-vc0-f177.google.com with SMTP id fo14so730301vcb.36 for ; Tue, 15 Jan 2013 21:43:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6YuEv5Hy9TZqSuti1FqHGAl76UkjOn4GKP2vQR9deyo=; b=v+mqkTtY1qyyD5iW3wmPTUL9tNR0ZvcOkA+1uaY8Qf1uiJhyUDLpJG5aeplfVyLapy +CHUDefcZ7AHVp5tvvDeuMJq2LwCiMeYwHbh3wpzgmgMU/Mz/6wwaejSbX77wQ/tjr2U C6hjm/7PazD6vFiG+0hLvb+yFYbqAeChgJuZoO78Vc4Ziyb6jSI6cUEF8F0dI4bQBZ7V JF6U/2Pj65nTCajIwUzpxIC02pLPIBn85qMVqY56GLWGMwcLcsarlLxRr/P1dYAoQe+6 fYIEf8hZzOtaxu8t6Am2ts6V0WczobbSMHXyahwd0hIwCrWNSGlOVrdqUfNwYBj0tjSr CSZg== MIME-Version: 1.0 Received: by 10.221.11.205 with SMTP id pf13mr106604185vcb.70.1358315034769; Tue, 15 Jan 2013 21:43:54 -0800 (PST) Received: by 10.220.50.6 with HTTP; Tue, 15 Jan 2013 21:43:54 -0800 (PST) In-Reply-To: References: Date: Tue, 15 Jan 2013 21:43:54 -0800 Message-ID: Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() From: Jack Vogel To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" , head@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, 16 Jan 2013 05:43:57 -0000 OK, will look at this as soon as I can. Jack On Tue, Jan 15, 2013 at 5:23 PM, Luigi Rizzo wrote: > Hi, > i found a couple of problems in > dev/e1000/if_lem.c::lem_handle_rxtx() , > (compare with dev/e1000/if_em.c::em_handle_que() for better understanding): > > 1. in if_em.c::em_handle_que(), when em_rxeof() exceeds the > rx_process_limit, the task is rescheduled so it can complete the work. > Conversely, in if_lem.c::lem_handle_rxtx() the lem_rxeof() is > only run once, and if there are more pending packets the only > chance to drain them is to receive (many) more interrupts. > > This is a relatively serious problem, because the receiver has > a hard time recovering. > > I'd like to commit a fix to this same as it is done in e1000. > > 2. in if_em.c::em_handle_que(), interrupts are reenabled unconditionally, > whereas lem_handle_rxtx() only enables them if IFF_DRV_RUNNING is set. > > I cannot really tell what is the correct way here, so I'd like > to put a comment there unless there is a good suggestion on > what to do. > > Accesses to the intr register are race-prone anyways > (disabled in fastintr, enabled in the rxtx task without > holding any lock, and generally accessed under EM_CORE_LOCK > in other places), and presumably enabling/disabling the > interrupts around activations of the taks is just an > optimization (and on a VM, it is actually a pessimization > due to the huge cost of VM exits). > > cheers > luigi > From owner-freebsd-net@FreeBSD.ORG Wed Jan 16 07:14:05 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 213273A0 for ; Wed, 16 Jan 2013 07:14:05 +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 D16BBE48 for ; Wed, 16 Jan 2013 07:14:04 +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 9BD6B7E820; Wed, 16 Jan 2013 18:13:56 +1100 (EST) Message-ID: <50F65334.8030407@freebsd.org> Date: Wed, 16 Jan 2013 18:13:56 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Eggert, Lars" Subject: Re: static kernel with mod_cc? References: <50F554EC.6070303@freebsd.org> 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: Wed, 16 Jan 2013 07:14:05 -0000 On 01/16/13 02:12, Eggert, Lars wrote: > Hi, > > On Jan 15, 2013, at 14:09, Lawrence Stewart wrote: >> You're not dense - the build glue to allow an algorithm to be specified >> in a kernel config file doesn't exist. > > ah, that explains it. I guess it doesn't exist for siftr either? Correct, though I believe it should be trivial to fix for both siftr and the mod_cc modules. I might have a go and post a patch for testing. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Wed Jan 16 14:19:09 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 695D8D26 for ; Wed, 16 Jan 2013 14:19:09 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm23-vm2.bullet.mail.ne1.yahoo.com (nm23-vm2.bullet.mail.ne1.yahoo.com [98.138.91.211]) by mx1.freebsd.org (Postfix) with ESMTP id 1FCE3B68 for ; Wed, 16 Jan 2013 14:19:08 +0000 (UTC) Received: from [98.138.90.52] by nm23.bullet.mail.ne1.yahoo.com with NNFMP; 16 Jan 2013 14:19:01 -0000 Received: from [98.138.89.251] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 16 Jan 2013 14:19:01 -0000 Received: from [127.0.0.1] by omp1043.mail.ne1.yahoo.com with NNFMP; 16 Jan 2013 14:19:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 892358.66938.bm@omp1043.mail.ne1.yahoo.com Received: (qmail 52964 invoked by uid 60001); 16 Jan 2013 14:19:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1358345941; bh=fcmZ0cIIWGc6QgARu78Ez+nA+rAY9U9CDOttPS/VASc=; 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=vClkeOqWu/2Wra6NDivKZyT3jcZkdnTdkrQQ6YoJDJi9Tetz+TwTkfuNnpsE/7L1W3laD//CzL3WH5F9+eMo1GwsUvTGUcMgRdOIqtAQvCLThymgb9p4F9+FeE9tpCrBuZpOrjw7ma11nkJDTjmzMZIaWYsXl3XayIE7rVdyx5A= 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=ps2e0pRJuVl+LwyCT1fmqCTPKfRjE7zfQeuZ+zLLmYbN9USlbC5k+eITbcD+W9XFo5GoRdxfIKoDhl6b0nGPkLXlO9tCREf/aWIZTYR57iuDhNcM5YN2io7VvsimpgLjutBJBx57X79lceccVAo6gfyXXC9IQhlRfIFC0Td+myk=; X-YMail-OSG: 1c7djLIVM1nSv5H5XjR8YHrPr2kNnJpMkOB9SM4XOpfrhAd 4HaQE82x2.w.RIn5TMCMyIWdjrCBZJV2n8fuEL7_e_pcCKPub7yBVZT9Oys2 dKoqcKLYUqc4aFEKpHvxp3FfN7H0gKpXojIZtNZUPyZYhySa8re1CNR9Ibnu N4URWzQqEbLrLt.9LLisdvlaqbuePuKSS9XgpUneuuXy3FheMWQvpZN4_jTb yQh188MJMuS.hnpas.8RhIVrFYjQ7E9XDLSIsKW8DyewX1bjVUWnwpbev9UJ 1aqeDhnWMkU6EIR.s4fFqBipowyEaVLiIv8Pk2lfmvZXHDYFC0uB80MLbBdt tu_eNq8U77YTjTP34FUco3TvksmaxZSkkA8PwUyf.UKYqNeNEdH3kopxTqaQ K3YGdQdBf060giWzJTaRQocb58bdmOk5R0qEa_.rLxwmpBFQLqWgj.ddD6fI 2y9KemR_SWWYIxCJi9BlyePT5f_u05LfuanrszcO3bhDEGPafpIFeZO7QVku phpmZQx7kL3DekSihY7Q_dAF3ksWQ Received: from [174.48.128.27] by web121604.mail.ne1.yahoo.com via HTTP; Wed, 16 Jan 2013 06:19:01 PST X-Rocket-MIMEInfo: 001.001, CgotLS0gT24gVHVlLCAxLzE1LzEzLCBMdWlnaSBSaXp6byA8cml6em9AaWV0LnVuaXBpLml0PiB3cm90ZToKCj4gRnJvbTogTHVpZ2kgUml6em8gPHJpenpvQGlldC51bmlwaS5pdD4KPiBTdWJqZWN0OiB0d28gcHJvYmxlbXMgaW4gZGV2L2UxMDAwL2lmX2xlbS5jOjpsZW1faGFuZGxlX3J4dHgoKQo.IFRvOiBoZWFkQGZyZWVic2Qub3JnLCAiZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmciIDxmcmVlYnNkLW5ldEBmcmVlYnNkLm9yZz4KPiBDYzogIkphY2sgVm9nZWwiIDxqZnZvZ2VsQGdtYWlsLmNvbT4KPiBEYXQBMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.130.494 Message-ID: <1358345941.38671.YahooMailClassic@web121604.mail.ne1.yahoo.com> Date: Wed, 16 Jan 2013 06:19:01 -0800 (PST) From: Barney Cordoba Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() To: Luigi Rizzo 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 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, 16 Jan 2013 14:19:09 -0000 =0A=0A--- On Tue, 1/15/13, Luigi Rizzo wrote:=0A=0A> F= rom: Luigi Rizzo =0A> Subject: two problems in dev/e100= 0/if_lem.c::lem_handle_rxtx()=0A> To: head@freebsd.org, "freebsd-net@freebs= d.org" =0A> Cc: "Jack Vogel" = =0A> Date: Tuesday, January 15, 2013, 8:23 PM=0A> Hi,=0A> i found a couple = of problems in=0A> =A0 =A0 =A0 =A0=0A> dev/e1000/if_lem.c::lem_handle_rxtx(= ) ,=0A> (compare with dev/e1000/if_em.c::em_handle_que() for better=0A> und= erstanding):=0A> =0A> 1. in if_em.c::em_handle_que(), when em_rxeof() excee= ds the=0A> =A0 rx_process_limit, the task is rescheduled so it can=0A> comp= lete the work.=0A> =A0 Conversely, in if_lem.c::lem_handle_rxtx() the=0A> l= em_rxeof() is=0A> =A0 only run once, and if there are more pending packets= =0A> the only=0A> =A0 chance to drain them is to receive (many) more=0A> in= terrupts.=0A> =0A> =A0 This is a relatively serious problem, because the=0A= > receiver has=0A> =A0 a hard time recovering.=0A> =0A> =A0 I'd like to com= mit a fix to this same as it is done=0A> in e1000.=0A> =0A> 2. in if_em.c::= em_handle_que(), interrupts are reenabled=0A> unconditionally,=0A> =A0=A0= =A0whereas lem_handle_rxtx() only enables=0A> them if IFF_DRV_RUNNING is se= t.=0A> =0A> =A0=A0=A0I cannot really tell what is the correct=0A> way here,= so I'd like=0A> =A0=A0=A0to put a comment there unless there is a=0A> good= suggestion on=0A> =A0=A0=A0what to do.=0A> =0A> =A0=A0=A0Accesses to the i= ntr register are=0A> race-prone anyways=0A> =A0=A0=A0(disabled in fastintr,= enabled in the rxtx=0A> task without=0A> =A0=A0=A0holding any lock, and ge= nerally accessed=0A> under EM_CORE_LOCK=0A> =A0=A0=A0in other places), and = presumably=0A> enabling/disabling the=0A> =A0=A0=A0interrupts around activa= tions of the taks=0A> is just an=0A> =A0=A0=A0optimization (and on a VM, it= is actually=0A> a pessimization=0A> =A0=A0=A0due to the huge cost of VM ex= its).=0A> =0A> cheers=0A> luigi=0A=0AThis is not really a big deal; this is= how things works for a million =0Ayears before we had task queues.=0A=0AIn= tel controllers have built in interrupt moderation (unless you're on an=0AI= SA bus or something), so interrupt storms aren't possible. Typical default= =0Ais 6K ints per second, so you can't get another interrupt for 1/6000th o= f=0Aa second whether there's more work to do or not.=0A=0AThe "work" parame= ter should be an indicator that something is happening too=0Aslow, which ca= n happen with a shaper that's taking a lot more time than=0Anormal to proce= ss packets. =0A=0ASystems should have a maximum pps engineered into its tun= ing depending on=0Athe cpu to avoid live-lock on legacy systems. the defaul= t work limit of=0A100 is too low on a gigabit system. =0A=0Aqueuing tasks a= ctually creates more overhead in the system, not less. The=0Aissue is wheth= er the process_limit * interrupt_moderation is set to a =0Apps that's suita= ble for your system. =0A=0ASetting low work limits isn't really a good idea= unless you have some other=0Atime sensitive kernel task. Usually networkin= g is a priority, so setting=0Aarbitrary work limits makes less sense than q= ueuing an additional task,=0Awhich defeats the purpose of interrupt moderat= ion.=0A=0ABC From owner-freebsd-net@FreeBSD.ORG Wed Jan 16 19:51:51 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 7946C144 for ; Wed, 16 Jan 2013 19:51:51 +0000 (UTC) (envelope-from hunter@comsys.com.ua) Received: from mail.ice-tech.com.ua (mail.ice-tech.com.ua [77.120.117.100]) by mx1.freebsd.org (Postfix) with ESMTP id 38B0591A for ; Wed, 16 Jan 2013 19:51:51 +0000 (UTC) Received: from 94.244.147.77.nash.net.ua ([94.244.147.77] helo=hunters-MacBook-Pro.local) by mail.ice-tech.com.ua with esmtpa (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TvYQd-000NSx-JY for freebsd-net@FreeBSD.org; Wed, 16 Jan 2013 21:13:43 +0200 Message-ID: <50F6FBC5.8060300@comsys.com.ua> Date: Wed, 16 Jan 2013 21:13:09 +0200 From: Sergey Smitienko User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-net@FreeBSD.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 94.244.147.77 X-SA-Exim-Mail-From: hunter@comsys.com.ua X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.ice-tech.com.ua X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,TVD_RCVD_IP autolearn=unavailable version=3.3.2 Subject: pf with divert is not working properly. FreeBSD 9.1 X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail.ice-tech.com.ua) 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, 16 Jan 2013 19:51:51 -0000 Hello. I think I found a bug in divert sockets processing in pf, or maybe I'm missing something. Here is my setup, machine 192.168.250.103 is a DNS server and udp traffic coming to port 53 gets diverted to a test application. Test application is very simple, it just prints some info on the packet and reinjects it back to the kernel. Then divertion is done by IPFW, all works as expected. IPFW rule is "divert 1025 udp from any to 192.168.250.103 dst-port 53". Then I divert packets using pf rule "pass in log quick on em0 inet proto udp from any to 192.168.250.103 port 53 divert-to 127.0.0.1 port 1025", I'm starting to get a loop of the same packet comming back from divert socket again and again. If I change my sento() call to n = sendto(fd, packet, n, 0, (struct sockaddr*) &org, sizeof(org));, packet riches DNS server, but then I'm getting DNS reply in my divert socket and reply is getting looped all over again. I've also tried sample code from OpenBSD divert man page and I'm getting same loop once again. Here is my test code: #include #include #include #include #include #include #include #include #include #include #include void run (int port) { int fd; struct sockaddr_in sin; struct sockaddr_in org; int len, n, on=1; struct ip* ip; struct udphdr* udp; char *packet; packet = malloc(65536); if (packet == NULL) { warn ("malloc()"); exit(1); } ip = (struct ip*) packet; fd = socket(PF_INET, SOCK_RAW, IPPROTO_DIVERT); if (fd < 0) { warn ("socket(divert)"); exit(1); } sin.sin_len = sizeof(struct sockaddr_in); sin.sin_family = AF_INET; sin.sin_port=htons(port); sin.sin_addr.s_addr=inet_addr("127.0.0.1"); len = sizeof(struct sockaddr_in); if (bind(fd, (struct sockaddr *)&sin, len)<0) { warn("binding"); exit(1); } while (1) { len = sizeof(struct sockaddr_in); if (getsockname(fd, (struct sockaddr*) &org, &len) < 0) { warn("getsockname"); continue; } memset(packet, 0, 65536); memset(&sin, 0, sizeof(sin)); len = sizeof(sin); n = recvfrom(fd, packet, 65536, 0, (struct sockaddr*) &sin, &len); if (n < 0) { warn("recvfrom"); continue; } if (n < sizeof (struct ip)) continue; printf ("Got %d bytes from %s:%d | ", n, inet_ntoa(sin.sin_addr), ntohs(sin.sin_port)); printf ("%s:%d\n", inet_ntoa(org.sin_addr), ntohs(org.sin_port)); printf ("%s -> ", inet_ntoa(ip->ip_src)); printf ("%s ", inet_ntoa(ip->ip_dst)); printf ("TTL %d, PROTO %d, hlen %d, CSUM %x\n", ip->ip_ttl, ip->ip_p, ip->ip_hl, ip->ip_sum); udp = (struct udphdr*) (packet + ip->ip_hl*4); printf ("UDP src_port %d, dst_port %d\n", ntohs(udp->uh_sport), ntohs(udp->uh_dport)); n = sendto(fd, packet, n, 0, (struct sockaddr*) &sin, sizeof(sin)); if (n < 0 ) { warn("sendto"); } } } int main(void) { run (1025); } -- Sergey Smitienko From owner-freebsd-net@FreeBSD.ORG Thu Jan 17 03:04:39 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 95821F61 for ; Thu, 17 Jan 2013 03:04:39 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 512C9345 for ; Thu, 17 Jan 2013 03:04:38 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id BAA1A7300A; Thu, 17 Jan 2013 03:55:02 +0100 (CET) Date: Thu, 17 Jan 2013 03:55:02 +0100 From: Luigi Rizzo To: Barney Cordoba Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() Message-ID: <20130117025502.GA57613@onelab2.iet.unipi.it> References: <1358345941.38671.YahooMailClassic@web121604.mail.ne1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1358345941.38671.YahooMailClassic@web121604.mail.ne1.yahoo.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 03:04:39 -0000 On Wed, Jan 16, 2013 at 06:19:01AM -0800, Barney Cordoba wrote: > > > --- On Tue, 1/15/13, Luigi Rizzo wrote: > > > From: Luigi Rizzo > > Subject: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() > > To: head@freebsd.org, "freebsd-net@freebsd.org" > > Cc: "Jack Vogel" > > Date: Tuesday, January 15, 2013, 8:23 PM > > Hi, > > i found a couple of problems in > > ? ? ? ? > > dev/e1000/if_lem.c::lem_handle_rxtx() , > > (compare with dev/e1000/if_em.c::em_handle_que() for better > > understanding): > > > > 1. in if_em.c::em_handle_que(), when em_rxeof() exceeds the > > ? rx_process_limit, the task is rescheduled so it can > > complete the work. > > ? Conversely, in if_lem.c::lem_handle_rxtx() the > > lem_rxeof() is > > ? only run once, and if there are more pending packets > > the only > > ? chance to drain them is to receive (many) more > > interrupts. > > > > ? This is a relatively serious problem, because the > > receiver has > > ? a hard time recovering. > > > > ? I'd like to commit a fix to this same as it is done > > in e1000. > > > > 2. in if_em.c::em_handle_que(), interrupts are reenabled > > unconditionally, > > ???whereas lem_handle_rxtx() only enables > > them if IFF_DRV_RUNNING is set. > > > > ???I cannot really tell what is the correct > > way here, so I'd like > > ???to put a comment there unless there is a > > good suggestion on > > ???what to do. > > > > ???Accesses to the intr register are > > race-prone anyways > > ???(disabled in fastintr, enabled in the rxtx > > task without > > ???holding any lock, and generally accessed > > under EM_CORE_LOCK > > ???in other places), and presumably > > enabling/disabling the > > ???interrupts around activations of the taks > > is just an > > ???optimization (and on a VM, it is actually > > a pessimization > > ???due to the huge cost of VM exits). > > > > cheers > > luigi > > This is not really a big deal; this is how things works for a million > years before we had task queues. i agree that the second issue is not a big deal. The first one, on the contrary, is a real problem no matter how you set the 'work' parameter (unless you make it large enough to drain the entire queue in one call). cheers luigi From owner-freebsd-net@FreeBSD.ORG Thu Jan 17 04:54:58 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 68DDBE2 for ; Thu, 17 Jan 2013 04:54:58 +0000 (UTC) (envelope-from dspisak@agiosat.net) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by mx1.freebsd.org (Postfix) with ESMTP id 46284320 for ; Thu, 17 Jan 2013 04:54:57 +0000 (UTC) Received: by mail-pb0-f53.google.com with SMTP id un1so513344pbc.40 for ; Wed, 16 Jan 2013 20:54:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:content-type:x-gm-message-state; bh=LO8SwCHj8yjGop75/XEimvTx0OuF8zoZ+odSLk2FrQQ=; b=fMPDlzurKaNrbaLgdth/G2YsxW7qtqh8oqbgiO+pWmeuVtAqxUP/FWLB7aU/EXHPd3 94VyPwLq0RSISQMCu3G08Vsxbdy37JxMo4cJVVLZ8wJGVTLUJGjK1AFnVmqSfUCI50nB 4Xhvh8Atfq5nVTz+bCSL7c5fk9+4IxueZEdDCgXVqB+2RC0vywSI/enYyVuFEGtXBL0g DO0GzXjVM1J8iy6E7GWFxffqWECY7V4xKzDDYbBKkKVvnmM3lYdfE4yzfVkzwRMH8G+1 agafLmNsDUKwbeu9D3sNvA3y7wyKBHffgPLU7T7fPP2Rn0Z2llXm1PXwKjovaBDr+3Lh QiQg== X-Received: by 10.68.132.10 with SMTP id oq10mr9955204pbb.18.1358398490877; Wed, 16 Jan 2013 20:54:50 -0800 (PST) Received: from [192.168.123.154] (rrcs-74-62-198-26.west.biz.rr.com. [74.62.198.26]) by mx.google.com with ESMTPS id is3sm329200pbc.6.2013.01.16.20.54.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Jan 2013 20:54:50 -0800 (PST) Message-ID: <50F78416.8080901@agiosat.net> Date: Wed, 16 Jan 2013 20:54:46 -0800 From: Daniel Spisak User-Agent: Postbox 3.0.6 (Windows/20121031) MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Freebsd 8.3-RELEASE kernel panics when Xorp-1.8.6 tries to shutdown X-Gm-Message-State: ALoCoQlxqd4fikJ0h4PIX/BtJ8b7A9h68IDLSvOEc5OUlrHIm/ZmVolsd4ypbPKWj9btLHpYsKUN Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Keith Simonsen 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, 17 Jan 2013 04:54:58 -0000 Hi there, I'm new to the list! Myself and a colleague have been trying to use Xorp 1.8.6 (we pulled the source from the git repo about a two months ago) to handle multicast routing over GRE tunnels for a rather convoluted scenario. In the course of trying to get that setup working (which will be another separate email to the list) we seem to be running into behavior from Xorp that is causing kernel panics to happen on FreeBSD 8.3-RELEASE. Currently, we are able to startup Xorp normally with no apparent problems. However, as soon as we try to shutdown the Xorp service or initiate a system reboot the system will kernel panic. We are running Xorp on ALIX1.D single board computers. You can see more about the hardware specs here: http://pcengines.ch/alix1d.htm I have created a file dump of some of the kernel panics along with some kdbg backtraces for developers to take a look at (along with a kernel.debug for our kernel build). If I am reading the backtraces right, it looks like there might be an issue being caused by IGMP somehow. Perhaps a mismatch between v2 and v3? http://www.mediafire.com/?ojxdc172mp7q6 I'm pretty new to Xorp and multicast so its possible I've missed something here. I've gone ahead and used send-pr to submit the error and you can find it here: http://www.freebsd.org/cgi/query-pr.cgi?pr=175365 Output from fbsd for interfaces: dispatch-dev# ifconfig -a vr0: flags=8a43 metric 0 mtu 1500 options=8280b ether 00:0d:b9:0e:32:d4 inet XX.XX.XXX.XX netmask 0xfffffffc broadcast XX.XX.XXX.XX inet 192.168.10.2 netmask 0xffffff00 broadcast 192.168.10.255 inet 10.13.8.253 netmask 0xffffff80 broadcast 10.13.8.255 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff000000 enc0: flags=0<> metric 0 mtu 1536 pflog0: flags=0<> metric 0 mtu 33200 gre0: flags=9010 metric 0 mtu 1476 If anyone has any input/insight as to what is causing the kernel panics and how to fix it, that would be great. Thanks! -- Daniel Spisak Network Engineer Agiosat Government Services dspisak@agiosat.net From owner-freebsd-net@FreeBSD.ORG Thu Jan 17 06:33:07 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B9DBF182 for ; Thu, 17 Jan 2013 06:33:07 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 7C1937DC for ; Thu, 17 Jan 2013 06:33:06 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id DCBBF7300A; Thu, 17 Jan 2013 07:32:32 +0100 (CET) Date: Thu, 17 Jan 2013 07:32:32 +0100 From: Luigi Rizzo To: Jack Vogel Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() Message-ID: <20130117063232.GA59734@onelab2.iet.unipi.it> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "freebsd-net@freebsd.org" , head@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 06:33:07 -0000 On Tue, Jan 15, 2013 at 09:43:54PM -0800, Jack Vogel wrote: > OK, will look at this as soon as I can. > > Jack below is a short patch that reschedule the task if the queue has not been drained. Tested on qemu. I can do the commit if you like. cheers luigi Index: ../head/sys/dev/e1000/if_lem.c =================================================================== --- ../head/sys/dev/e1000/if_lem.c (revision 245218) +++ ../head/sys/dev/e1000/if_lem.c (working copy) @@ -1337,12 +1411,16 @@ if (ifp->if_drv_flags & IFF_DRV_RUNNING) { - lem_rxeof(adapter, adapter->rx_process_limit, NULL); + bool more = lem_rxeof(adapter, adapter->rx_process_limit, NULL); EM_TX_LOCK(adapter); lem_txeof(adapter); if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) lem_start_locked(ifp); EM_TX_UNLOCK(adapter); + if (more) { + taskqueue_enqueue(adapter->tq, &adapter->rxtx_task); + return; + } } if (ifp->if_drv_flags & IFF_DRV_RUNNING) From owner-freebsd-net@FreeBSD.ORG Thu Jan 17 16:09:00 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 DD18BD7C for ; Thu, 17 Jan 2013 16:09:00 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm35-vm0.bullet.mail.ne1.yahoo.com (nm35-vm0.bullet.mail.ne1.yahoo.com [98.138.229.96]) by mx1.freebsd.org (Postfix) with ESMTP id 922A9AB3 for ; Thu, 17 Jan 2013 16:09:00 +0000 (UTC) Received: from [98.138.90.49] by nm35.bullet.mail.ne1.yahoo.com with NNFMP; 17 Jan 2013 16:08:52 -0000 Received: from [98.138.89.192] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 17 Jan 2013 16:08:52 -0000 Received: from [127.0.0.1] by omp1050.mail.ne1.yahoo.com with NNFMP; 17 Jan 2013 16:08:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 659372.29399.bm@omp1050.mail.ne1.yahoo.com Received: (qmail 70523 invoked by uid 60001); 17 Jan 2013 16:08:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1358438932; bh=vzjtEm9Rj88WFZVT/PObedljCRTy/k8/eu32HVc3s2U=; 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=nJ4SyJVy9qJCP2K3bpOcl3W7tJ0lS8im/9bcmrgcZjLpPtSRbmVn4NPfppCHLAwWlZmsEdvU1e/urbsMg7eI/zqmIkAt3mPMc6zC82RXvY8VKawLcNwEyJOYbjRgKyu+sJkf8ya0xUt3KIYoL1/G2OoWsUfUHj2ejE6muqm1spM= 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=LkEi8KW/2h2S4ubVZ40e67v6bx3kkm9CaudTU/DFKOFDsuDZBFpT3aHf+kVJfCRD9H0W/YuBIoFWthaqwjEsnYWZLiyuOqIwdzkfy1Zn7nI9n5U2yABSWpTlX0R5s8R9FJuKZPQHbjMogTHKnhzUscMcoNYCohx24F9BWwCQHiM=; X-YMail-OSG: 12bo4XQVM1mvY.IV63tXkb5BR8pwRlhHHd1UBjcgZAHIor8 wC2VAcsZjsXNjZZGFRuaUfyMjMy4RxkCpAwzxJpwA4U9rN5Evy8Ndr5er7VG 7TCznlob3amOIYX7HfWrM2ppAOhLCIwgOycr7_i185mFANjnYdTS6axYFwgd STzpEXLRyxgHiZpJqA1Ex2yKXWEsAOP5UT.JdCfexTTJsWcjCCkCtiKJH4lh hbxpnSNSJ6aq2tLMyLGvn3kTHVa7mwPSNSUKUOJhJlG.xAA8mOs5UQM5VcQB 2l0nGHVWZWJV9O9BzN8vtoNUOxPMHpN42sZjmWsgF.Nu_FOkbz7ABX0mQEok QirVj6YK2Zdmb26x.4XjieCMP5iJWvHWi0cxEq8iiu1IV6nPIJH.g4jCqZRF _yA6gR2ioYTQtJ700u7bjfIddNTuCePRHJq9mSqpOA3SGFUOCRH1N2vOGWfZ oUGngibOak2vMprebn5rZ_V6Fr3tse_EEuoi5f96_6_7esCUI4nZDfQfChoq LRs0P9eFQZTza3OL7SwaMUf1SObNQ Received: from [174.48.128.27] by web121601.mail.ne1.yahoo.com via HTTP; Thu, 17 Jan 2013 08:08:52 PST X-Rocket-MIMEInfo: 001.001, DQoNCi0tLSBPbiBXZWQsIDEvMTYvMTMsIEx1aWdpIFJpenpvIDxyaXp6b0BpZXQudW5pcGkuaXQ.IHdyb3RlOg0KDQo.IEZyb206IEx1aWdpIFJpenpvIDxyaXp6b0BpZXQudW5pcGkuaXQ.DQo.IFN1YmplY3Q6IFJlOiB0d28gcHJvYmxlbXMgaW4gZGV2L2UxMDAwL2lmX2xlbS5jOjpsZW1faGFuZGxlX3J4dHgoKQ0KPiBUbzogIkJhcm5leSBDb3Jkb2JhIiA8YmFybmV5X2NvcmRvYmFAeWFob28uY29tPg0KPiBDYzogZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmcNCj4gRGF0ZTogV2VkbmVzZGF5LCBKYW51YXJ5IDEBMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.130.494 Message-ID: <1358438932.56236.YahooMailClassic@web121601.mail.ne1.yahoo.com> Date: Thu, 17 Jan 2013 08:08:52 -0800 (PST) From: Barney Cordoba Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() To: Luigi Rizzo In-Reply-To: <20130117025502.GA57613@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 16:09:00 -0000 --- On Wed, 1/16/13, Luigi Rizzo wrote: > From: Luigi Rizzo > Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() > To: "Barney Cordoba" > Cc: freebsd-net@freebsd.org > Date: Wednesday, January 16, 2013, 9:55 PM > On Wed, Jan 16, 2013 at 06:19:01AM > -0800, Barney Cordoba wrote: > > > > > > --- On Tue, 1/15/13, Luigi Rizzo > wrote: > > > > > From: Luigi Rizzo > > > Subject: two problems in > dev/e1000/if_lem.c::lem_handle_rxtx() > > > To: head@freebsd.org, > "freebsd-net@freebsd.org" > > > > Cc: "Jack Vogel" > > > Date: Tuesday, January 15, 2013, 8:23 PM > > > Hi, > > > i found a couple of problems in > > > ? ? ? ? > > > dev/e1000/if_lem.c::lem_handle_rxtx() , > > > (compare with dev/e1000/if_em.c::em_handle_que() > for better > > > understanding): > > > > > > 1. in if_em.c::em_handle_que(), when em_rxeof() > exceeds the > > > ? rx_process_limit, the task is rescheduled so it > can > > > complete the work. > > > ? Conversely, in if_lem.c::lem_handle_rxtx() the > > > lem_rxeof() is > > > ? only run once, and if there are more pending > packets > > > the only > > > ? chance to drain them is to receive (many) more > > > interrupts. > > > > > > ? This is a relatively serious problem, because > the > > > receiver has > > > ? a hard time recovering. > > > > > > ? I'd like to commit a fix to this same as it is > done > > > in e1000. > > > > > > 2. in if_em.c::em_handle_que(), interrupts are > reenabled > > > unconditionally, > > > ???whereas lem_handle_rxtx() only enables > > > them if IFF_DRV_RUNNING is set. > > > > > > ???I cannot really tell what is the correct > > > way here, so I'd like > > > ???to put a comment there unless there is a > > > good suggestion on > > > ???what to do. > > > > > > ???Accesses to the intr register are > > > race-prone anyways > > > ???(disabled in fastintr, enabled in the rxtx > > > task without > > > ???holding any lock, and generally accessed > > > under EM_CORE_LOCK > > > ???in other places), and presumably > > > enabling/disabling the > > > ???interrupts around activations of the taks > > > is just an > > > ???optimization (and on a VM, it is actually > > > a pessimization > > > ???due to the huge cost of VM exits). > > > > > > cheers > > > luigi > > > > This is not really a big deal; this is how things works > for a million > > years before we had task queues. > > i agree that the second issue is not a big deal. > > The first one, on the contrary, is a real problem no matter > how you set the 'work' parameter (unless you make it large > enough to drain the entire queue in one call). Which should be the goal, except in extreme circumstances. Having more packets than "work" should be the extreme case and not the norm. All work should do is normalize bursts of packets. If you're consistently over work then either your work parameter is too low, or your interrupt moderation is too wide. Adding a cleanup task simply compensates for bad tuning. BC From owner-freebsd-net@FreeBSD.ORG Thu Jan 17 16:45: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 E6165FEF for ; Thu, 17 Jan 2013 16:45:06 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 6F4A0E3B for ; Thu, 17 Jan 2013 16:45:06 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 3E9227300A; Thu, 17 Jan 2013 17:44:32 +0100 (CET) Date: Thu, 17 Jan 2013 17:44:32 +0100 From: Luigi Rizzo To: Barney Cordoba Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() Message-ID: <20130117164432.GA64619@onelab2.iet.unipi.it> References: <20130117025502.GA57613@onelab2.iet.unipi.it> <1358438932.56236.YahooMailClassic@web121601.mail.ne1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1358438932.56236.YahooMailClassic@web121601.mail.ne1.yahoo.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 16:45:07 -0000 On Thu, Jan 17, 2013 at 08:08:52AM -0800, Barney Cordoba wrote: > > > --- On Wed, 1/16/13, Luigi Rizzo wrote: > > > From: Luigi Rizzo > > Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() > > To: "Barney Cordoba" > > Cc: freebsd-net@freebsd.org > > Date: Wednesday, January 16, 2013, 9:55 PM > > On Wed, Jan 16, 2013 at 06:19:01AM > > -0800, Barney Cordoba wrote: > > > > > > > > > --- On Tue, 1/15/13, Luigi Rizzo > > wrote: > > > > > > > From: Luigi Rizzo > > > > Subject: two problems in > > dev/e1000/if_lem.c::lem_handle_rxtx() > > > > To: head@freebsd.org, > > "freebsd-net@freebsd.org" > > > > > > Cc: "Jack Vogel" > > > > Date: Tuesday, January 15, 2013, 8:23 PM > > > > Hi, > > > > i found a couple of problems in > > > > ? ? ? ? > > > > dev/e1000/if_lem.c::lem_handle_rxtx() , > > > > (compare with dev/e1000/if_em.c::em_handle_que() > > for better > > > > understanding): > > > > > > > > 1. in if_em.c::em_handle_que(), when em_rxeof() > > exceeds the > > > > ? rx_process_limit, the task is rescheduled so it > > can > > > > complete the work. > > > > ? Conversely, in if_lem.c::lem_handle_rxtx() the > > > > lem_rxeof() is > > > > ? only run once, and if there are more pending > > packets > > > > the only > > > > ? chance to drain them is to receive (many) more > > > > interrupts. > > > > > > > > ? This is a relatively serious problem, because > > the > > > > receiver has > > > > ? a hard time recovering. > > > > > > > > ? I'd like to commit a fix to this same as it is > > done > > > > in e1000. > > > > > > > > 2. in if_em.c::em_handle_que(), interrupts are > > reenabled > > > > unconditionally, > > > > ???whereas lem_handle_rxtx() only enables > > > > them if IFF_DRV_RUNNING is set. > > > > > > > > ???I cannot really tell what is the correct > > > > way here, so I'd like > > > > ???to put a comment there unless there is a > > > > good suggestion on > > > > ???what to do. > > > > > > > > ???Accesses to the intr register are > > > > race-prone anyways > > > > ???(disabled in fastintr, enabled in the rxtx > > > > task without > > > > ???holding any lock, and generally accessed > > > > under EM_CORE_LOCK > > > > ???in other places), and presumably > > > > enabling/disabling the > > > > ???interrupts around activations of the taks > > > > is just an > > > > ???optimization (and on a VM, it is actually > > > > a pessimization > > > > ???due to the huge cost of VM exits). > > > > > > > > cheers > > > > luigi > > > > > > This is not really a big deal; this is how things works > > for a million > > > years before we had task queues. > > > > i agree that the second issue is not a big deal. > > > > The first one, on the contrary, is a real problem no matter > > how you set the 'work' parameter (unless you make it large > > enough to drain the entire queue in one call). > > Which should be the goal, except in extreme circumstances. Having more > packets than "work" should be the extreme case and not the norm. not really. . Once "work" is O(100), you have already heavily amortized all the constant costs related to scheduling, and performance improvements are marginal if you increase it further. Instead, you start to have extreme burstiness everywhere -- on the CPU, on the input queues for sockets/shapers, on the CPU (the thread running the handler cannot do anything else), and even on the NIC unless you advance the RDT (receive queue tail) a little bit at a tie to make room for newly incoming packets. So you really want to yield every now and then to smooth the bursts. I should mention i am running tests in such "extreme circumstances", bombing the guest in kvm with over 400Kpps (maximum-sized frames). And yes it can handle them. Hopefully you'll hear about this soon :) cheers luigi From owner-freebsd-net@FreeBSD.ORG Thu Jan 17 16:48: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 2C37113F for ; Thu, 17 Jan 2013 16:48:32 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by mx1.freebsd.org (Postfix) with ESMTP id A0A73E66 for ; Thu, 17 Jan 2013 16:48:31 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id hm2so2433636wib.4 for ; Thu, 17 Jan 2013 08:48:25 -0800 (PST) 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=I4GmsZbAsvGNLnLukaw7tfs6LKOJp73W2yqDkKscP08=; b=H1iBrhVrRlmtwQPBP0XZMZtRNcEo0PXjUURPzuGxiVLHk+K8crL3thCBG+yYcIGVKU yqh34Vem1/t8G5A6iUog+ZsCobao2obMLXRFwR4l5iGlNZ2KZVUVye414d47yVhU62fk VgG/WQ1uqd+OZigoVrKMkzHx9LaIFMRSiNYTFvyK8zvT8Za8ehUuk5vtNA6Ta+rCuJdx BFqYaXx2VcB2MijHVaZP+xQMI3jgDSKWDN0uuPHMlnvAui1AJkfCXg90Nh71tHHiuZGq iuhj7BeEGltHAeHylLxMohMLtnTf3Jl6LxMhlvrN+UwkxM6oC+4M8XFYo3CBk2kD8wLr nBeQ== MIME-Version: 1.0 X-Received: by 10.180.33.44 with SMTP id o12mr17331231wii.28.1358441305232; Thu, 17 Jan 2013 08:48:25 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Thu, 17 Jan 2013 08:48:25 -0800 (PST) In-Reply-To: <1358438932.56236.YahooMailClassic@web121601.mail.ne1.yahoo.com> References: <20130117025502.GA57613@onelab2.iet.unipi.it> <1358438932.56236.YahooMailClassic@web121601.mail.ne1.yahoo.com> Date: Thu, 17 Jan 2013 08:48:25 -0800 X-Google-Sender-Auth: Byp7Df3C1b3CU9Vs5etwnckerrY Message-ID: Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() From: Adrian Chadd To: Barney Cordoba Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Luigi Rizzo 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, 17 Jan 2013 16:48:32 -0000 There's also the subtle race condition in TX and RX handling that re-queuing the taskqueue gets around. Which is: * The hardware is constantly receiving frames , right until you blow the FIFO away by filling it up; * The RX thread receives a bunch of frames; * .. and processes them; * .. once it's done processing, the hardware may have read some more frames in the meantime; * .. and the hardware may have generated a mitigated interrupt which you're ignoring, since you're processing frames; * So if your architecture isn't 100% paranoid, you may end up having to wait for the next interrupt to handle what's currently in the queue. Now if things are done correct: * The hardware generates a mitigated interrupt * The mask register has that bit disabled, so you don't end up receiving it; * You finish your RX queue processing, and there's more stuff that's appeared in the FIFO (hence why the hardware has generated another mitigated interrupt); * You unmask the interrupt; * .. and the hardware immediately sends you the MSI or signals an interrupt; * .. thus you re-enter the RX processing thread almost(!) immediately. However as the poster(s) have said, the interrupt mask/unmask in the intel driver(s) may not be 100% correct, so you're going to end up with situations where interrupts are missed. The reason why this wasn't a big deal in the deep/distant past is because we didn't used to have kernel preemption, or multiple kernel threads running, or an overly aggressive scheduler trying to parallelise things as much as possible. A lot of net80211/ath bugs have popped out of the woodwork specifically because of the above changes to the kernel. They were bugs before, but people didn't hit them. Adrian From owner-freebsd-net@FreeBSD.ORG Thu Jan 17 17:45:01 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 01AC3C8B; Thu, 17 Jan 2013 17:45:01 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id B5CEC66B; Thu, 17 Jan 2013 17:45:00 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id BA2B97300A; Thu, 17 Jan 2013 18:44:27 +0100 (CET) Date: Thu, 17 Jan 2013 18:44:27 +0100 From: Luigi Rizzo To: Adrian Chadd Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() Message-ID: <20130117174427.GA65218@onelab2.iet.unipi.it> References: <20130117025502.GA57613@onelab2.iet.unipi.it> <1358438932.56236.YahooMailClassic@web121601.mail.ne1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Barney Cordoba , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 17:45:01 -0000 On Thu, Jan 17, 2013 at 08:48:25AM -0800, Adrian Chadd wrote: > There's also the subtle race condition in TX and RX handling that > re-queuing the taskqueue gets around. > > Which is: > > * The hardware is constantly receiving frames , right until you blow > the FIFO away by filling it up; > * The RX thread receives a bunch of frames; > * .. and processes them; > * .. once it's done processing, the hardware may have read some more > frames in the meantime; (in the "lem" driver this cannot happen until you release some rx slots, which only happens once at the end of the lem_rxeof() routine, not long before re-enabling interrupts) > * .. and the hardware may have generated a mitigated interrupt which > you're ignoring, since you're processing frames; > * So if your architecture isn't 100% paranoid, you may end up having > to wait for the next interrupt to handle what's currently in the > queue. > > Now if things are done correct: > > * The hardware generates a mitigated interrupt > * The mask register has that bit disabled, so you don't end up receiving it; > * You finish your RX queue processing, and there's more stuff that's > appeared in the FIFO (hence why the hardware has generated another > mitigated interrupt); > * You unmask the interrupt; > * .. and the hardware immediately sends you the MSI or signals an interrupt; > * .. thus you re-enter the RX processing thread almost(!) immediately. the problem i was actually seeing are slightly different, namely: - once the driver lags behind, it does not have a chance to recover even if there are CPU cycles available, because both interrupt rate and packets per interrupt are capped. - much worse, once the input stream stops, you have a huge backlog that is not drained. And if, say, you try to ping the machine, the incoming packet is behind another 3900 packets, so the first interrupt drains 100 (but not the ping request, so no response), you keep going for a while, eventually the external world sees the machine as not responding and stops even trying to talk to it. cheers luigi From owner-freebsd-net@FreeBSD.ORG Thu Jan 17 19:04:56 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 357E8A42 for ; Thu, 17 Jan 2013 19:04:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id B5AABAC5 for ; Thu, 17 Jan 2013 19:04:54 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id hn14so2525570wib.3 for ; Thu, 17 Jan 2013 11:04:53 -0800 (PST) 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=t8ZCjdr7t4lgl+hfKwlMsNTwEdcQcLENKwk2MgsTo2Y=; b=xljRuaKAFcEe6N56WTrNX6ighiXsgfBpvTIiEVmF78j1Yusicvt2uFnlq3nWxHPa0l 2DaBu2wvkn3EQIdxhkV1WdEShURfjWmLNavCLMkTXiY+Kjw/DwIWBfWJjtZxTDYTFH2F rANEUPddUMB7hUD90k5i4/pkyekNmKKFjLfnI5ftQnfGDKKf7IoysHv2sp4gJ8T23h2U HwgJrIM9J3XN7VDZJekOsSDEORDCi203EzF2yn7SfePYxcVXmrl5zy4Pzly35qOJvE4X JGNa95aiL0LgZLYxtvtzi52+bm5HBcXHBrtHG06ZIja/X74IjDk8gS0ahDyEmmXiCoZN 1rPQ== MIME-Version: 1.0 X-Received: by 10.195.13.67 with SMTP id ew3mr10213585wjd.59.1358449493378; Thu, 17 Jan 2013 11:04:53 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Thu, 17 Jan 2013 11:04:53 -0800 (PST) In-Reply-To: <20130117174427.GA65218@onelab2.iet.unipi.it> References: <20130117025502.GA57613@onelab2.iet.unipi.it> <1358438932.56236.YahooMailClassic@web121601.mail.ne1.yahoo.com> <20130117174427.GA65218@onelab2.iet.unipi.it> Date: Thu, 17 Jan 2013 11:04:53 -0800 X-Google-Sender-Auth: 7OQ-tHf77zbpNU_ihzw_UQRqCcQ Message-ID: Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() From: Adrian Chadd To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Cc: Barney Cordoba , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 19:04:56 -0000 On 17 January 2013 09:44, Luigi Rizzo wrote: > (in the "lem" driver this cannot happen until you release some > rx slots, which only happens once at the end of the lem_rxeof() routine, > not long before re-enabling interrupts) Right. >> * .. and the hardware immediately sends you the MSI or signals an interrupt; >> * .. thus you re-enter the RX processing thread almost(!) immediately. > > the problem i was actually seeing are slightly different, namely: > - once the driver lags behind, it does not have a chance to recover > even if there are CPU cycles available, because both interrupt > rate and packets per interrupt are capped. Right, but the interrupt isn't being continuously asserted whilst there are packets there. You just get a single interrupt when the queue has frames in it, and you won't get a further interrupt for whatever the mitigation period is (or ever, if you fill up the RX FIFO, right?) > - much worse, once the input stream stops, you have a huge backlog that > is not drained. And if, say, you try to ping the machine, > the incoming packet is behind another 3900 packets, so the first > interrupt drains 100 (but not the ping request, so no response), > you keep going for a while, eventually the external world sees the > machine as not responding and stops even trying to talk to it. Right, so you do need to do what you're doing - but I still think there's a possibility of a race there. Namely that your queue servicing does reach the end of the list (and so you don't immediately reschedule the taskqueue) but some more frames have arrived. You have to wait for the next mitigated interrupt for that. Adrian From owner-freebsd-net@FreeBSD.ORG Thu Jan 17 19:32:46 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 98D9E7E6 for ; Thu, 17 Jan 2013 19:32:46 +0000 (UTC) (envelope-from stevek@juniper.net) Received: from postoffice.novexsolutions.com (beastie.novexsolutions.com [204.109.60.25]) by mx1.freebsd.org (Postfix) with ESMTP id 707BCCF7 for ; Thu, 17 Jan 2013 19:32:46 +0000 (UTC) X-Authentication-Warning: webmail.novexsolutions.com: www set sender to stevek@juniper.net using -f To: Subject: Re: Proposal for changes to network device drivers and network stack (RFC) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 17 Jan 2013 14:23:24 -0500 From: "Stephen J. Kiernan" Organization: Juniper Networks, Inc. In-Reply-To: References: Message-ID: X-Sender: stevek@juniper.net User-Agent: Roundcube Webmail/0.7.2 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, 17 Jan 2013 19:32:46 -0000 The network stack as a module patch has been separated out and can be found in the following location: http://people.freebsd.org/~marcel/Juniper/netstack-v2.diff Details about these changes: 1. Network stack module support infrastructure kern/{kern_netstack.c,netstack_if.m,netstack.h} Network stack modules are declared using the NETSTACK_MODULE macro. Netstack classes are expected to be singletons. Currently, only a single network stack is allowed to be registered at a time. 2. Infrastructure to register UUID sources kern/kern_uuid.c net/netuuid.c sys/uuid.h: The uuid_node() function uses the node generated by first UUID source that returns with a success code, otherwise it generates a random multicast address. As part of these changes, selection of UUID based on MAC address has been moved to net/netuuid.c and it is registered as a UUID source. 3. Infrastructure to register IOCGROUPs in order to handle group-specific socket ioctls kern/sys_socket.c,net/{if.c,route.c} sys/socketvar.h This eliminates the explicit checks and calls for specific IOCGROUPs in soo_ioctl(). (Looking for comments about the naming, I'm not married to the name in any way and suggestions for better names is welcome.) Currently, the interface ioctl ('i') and route ioctl ('r') calls are registered using SO_IOCGROUP_SET. 4. Dynamically register the 'setfib' syscall kern/init_sysent.c net/route.c Registration of 'setfib' is done from net/route.c::route_init() instead of having an explicit entry in the sysent table. 5. Dynamically register SCTP syscalls kern/{init_sysent.c,uipc_syscalls.c} compat/freebsd32/freebsd32_sysent.c netinet/sctp_syscalls.c sys/socketvar.h Dynamically register the SCTP syscalls "sctp_peeloff", "sctp_generic_sendmsg", "sctp_generic_sendmsg_iov", and "sctp_generic_recvmsg" instead of having explicit entries in the sysent and freebsd32_sysent tables. Moved implementation of said syscalls from kern/uipc_syscalls.c to a new file named netinet/sctp_syscalls.c. Made getsock_cap() available outside of uipc_syscalls.c via socketvar.h (Junos network stack needs it, so making it available.) 6. Changes to kern_proc.c kern/kern_prot.c,netinet/in_prot.c,sys/systm.h Moved cr_canseeinpcb() to new file netinet/in_prot.c, as it is network stack related and only available when INET or INET6 is defined. Change the names for cr_seeotheruids() and cr_seeothergids() to cr_canseeotheruids() and cr_canseeothergids(), repectively, and make them available outside of kern_prot.c. 7. Create a netstack module kern/{uipc_socket.c,vfs_default.c,vfs_export.c} mk/bsd.own.mk modules/netstack net/{if_gre.c,netstack.c} netpfil/ipfw/ip_fw2.c netpfil/pf/pf_ioctl.c netinet/ip_gre.c Add SCTP to the MK_*_SUPPORT variables that need to be set. Add dependency on the netstack module. Added vfs_stdcheckexp() to kern/vfs_default.c which calls the netstack vfs_stdcheckexp method. Moved socket FIB assignment from the process to the netstack socreate method. Moved VFS "export" handling to netstack methods and changed vfs_export() and vfs_setpublicfs() to call the respective netstack methods. The netstack module includes INET, INET6, and SCTP support. Note: The only issue with including SCTP support, there is currently a dependency set on the crypto module. This is because SCTP needs SHA1 and SHA2-256 support. However, this could be provided by a number of different modules, so depending on crypto module might not be the best choice. Any thoughts on this? 8. Remove SO_SETFIB processing from sosetop and move it to ctloutput functions kern/uipc_socket.c net/route.[ch] netinet/{ip_output.c,raw_ip.c} netinet6/ip6_output.c Remove SO_SETFIB processing from sosetopt and move it instead to the ip_ctloutput(), ip6_ctloutput(), and rip_ctloutput() functions. Introduce the rtsosetfib() function to set so_fibnum, as appropriate. The *_ctloutput functions call the RT_SOSETFIB macro in order to call rtsosetfib() only when sockopt level is SOL_SOCKET and name is SO_SETFIB. 9. Define INET and INET6 in CFLAGS instead of relying on opt_inet.h and opt_inet6.h in modules modules/{carp,em,if_gre,ipdivert,ipfw,netstack,pf,pfsync,toecore}/Makefile Use CFLAGS to define INET and INET6 based on MK_INET_SUPPORT and MK_INET6_SUPPORT, respectively, instead of relying on opt_inet.h and opt_inet6.h. We need to do this in orer to be able to build NIC driver modules and the network stack as modules when the base kernel does not have netstack compiled in. 10. Make accept filters part of the standard files conf/files kern/{uipc_accf.c,uipc_socket.c} netinet/in_proto.c Make accept filters part of the standard files, as they could be used by things other than INET (and it eliminates a dependency on INET for uipc_socket.c) Move net.inet.accf.unloadable to net.accf.unloadable Add net.inet.accf node to in_proto.c in order to support existing accept filter sysctls. 11. Split IPv4 and IPv6-specific jail functions to netinet and netinet6, respectively. kern/kern_jail.c netinet/in_jail.c netinet6/in6_jail.c sys/jail.h Split IPv4 and IPv6-specific functions from kern/kern_jail.c into netinet/in_jail.c and netinet6/in6_jail.c, respectively. Change _prison_check_ipv[4|6]() to prison_check_ipv[4|6]_locked() and expose them via jail.h Change qcmp_v[4|6]() to prison_qcmp_v[4|6] and expose them via jail.h -- Stephen J. Kiernan Juniper Networks, Inc. stevek_at_juniper.net From owner-freebsd-net@FreeBSD.ORG Thu Jan 17 19:38:07 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E666E8DB for ; Thu, 17 Jan 2013 19:38:07 +0000 (UTC) (envelope-from stevek@juniper.net) Received: from postoffice.novexsolutions.com (beastie.novexsolutions.com [204.109.60.25]) by mx1.freebsd.org (Postfix) with ESMTP id B4CAAD36 for ; Thu, 17 Jan 2013 19:38:07 +0000 (UTC) X-Authentication-Warning: webmail.novexsolutions.com: www set sender to stevek@juniper.net using -f To: Subject: Re: [JNPR] Proposal for changes to network device drivers and network stack (RFC) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 17 Jan 2013 14:38:06 -0500 From: "Stephen J. Kiernan" Organization: Juniper Networks, Inc. In-Reply-To: References: Message-ID: X-Sender: stevek@juniper.net User-Agent: Roundcube Webmail/0.7.2 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, 17 Jan 2013 19:38:08 -0000 On Jan 17, 2013 14:23, Stephen J. Kiernan wrote: > The network stack as a module patch has been separated out and can be > found in the following location: > http://people.freebsd.org/~marcel/Juniper/netstack-v2.diff > > Details about these changes: I also forgot to mention in the previous e-mail. The patch also includes moving zlib.[ch] and zlibutil.h out of net and into sys/libkern (for the .c) and sys/sys (for the .h). It really doesn't make much sense for that code to live in net, especially when so many things which are not the network stack utilize it. That means that all kernel code that previously included net/zlib.h or net/zlibutil.h now needs to use sys/zlib.h or sys/zlibutil.h, respectively. Is that going to be a problem? Should simple stubs be added in the original locations in net/ to include the one in sys/ now? Note that there were only about a dozen source files in the kernel that needed changing. -- Stephen J. Kiernan Juniper Networks, Inc. stevek_at_juniper.net From owner-freebsd-net@FreeBSD.ORG Thu Jan 17 21:11:40 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E022F3C1 for ; Thu, 17 Jan 2013 21:11:40 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2233E12F for ; Thu, 17 Jan 2013 21:11:39 +0000 (UTC) Received: (qmail 49511 invoked from network); 17 Jan 2013 22:33:52 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 17 Jan 2013 22:33:52 -0000 Message-ID: <50F868FF.5060506@networx.ch> Date: Thu, 17 Jan 2013 22:11:27 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Stephen J. Kiernan" Subject: Re: Proposal for changes to network device drivers and network stack (RFC) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 21:11:40 -0000 On 17.01.2013 20:23, Stephen J. Kiernan wrote: > The network stack as a module patch has been separated out and can be found in the following location: > http://people.freebsd.org/~marcel/Juniper/netstack-v2.diff This is quite some work and a lot of changes which will a moment to review. Can you describe the concept and the terminology you're using here some more? What is a netstack module and what is its scope? How does it relate to VNET? What is an IOCGROUP? etc. All this is probably obvious to you but not yet for us. -- Andre > Details about these changes: > > 1. Network stack module support infrastructure > > kern/{kern_netstack.c,netstack_if.m,netstack.h} > > Network stack modules are declared using the NETSTACK_MODULE macro. > Netstack classes are expected to be singletons. Currently, only a single network stack is > allowed to be registered at a time. > > 2. Infrastructure to register UUID sources > > kern/kern_uuid.c > net/netuuid.c > sys/uuid.h: > > The uuid_node() function uses the node generated by first UUID source that returns with a > success code, otherwise it generates a random multicast address. > As part of these changes, selection of UUID based on MAC address has been moved to > net/netuuid.c and it is registered as a UUID source. > > 3. Infrastructure to register IOCGROUPs in order to handle group-specific socket ioctls > > kern/sys_socket.c,net/{if.c,route.c} > sys/socketvar.h > > This eliminates the explicit checks and calls for specific IOCGROUPs in soo_ioctl(). > > (Looking for comments about the naming, I'm not married to the name in any way and suggestions > for better names is welcome.) > > Currently, the interface ioctl ('i') and route ioctl ('r') calls are registered using > SO_IOCGROUP_SET. > > 4. Dynamically register the 'setfib' syscall > > kern/init_sysent.c > net/route.c > > Registration of 'setfib' is done from net/route.c::route_init() instead of having an explicit > entry in the sysent table. > > 5. Dynamically register SCTP syscalls > > kern/{init_sysent.c,uipc_syscalls.c} > compat/freebsd32/freebsd32_sysent.c > netinet/sctp_syscalls.c > sys/socketvar.h > > Dynamically register the SCTP syscalls "sctp_peeloff", "sctp_generic_sendmsg", > "sctp_generic_sendmsg_iov", and "sctp_generic_recvmsg" instead of having explicit entries in the > sysent and freebsd32_sysent tables. > > Moved implementation of said syscalls from kern/uipc_syscalls.c to a new file named > netinet/sctp_syscalls.c. > > Made getsock_cap() available outside of uipc_syscalls.c via socketvar.h (Junos network stack > needs it, so making it available.) > > 6. Changes to kern_proc.c > > kern/kern_prot.c,netinet/in_prot.c,sys/systm.h > > Moved cr_canseeinpcb() to new file netinet/in_prot.c, as it is network stack related and only > available when INET or INET6 is defined. > > Change the names for cr_seeotheruids() and cr_seeothergids() to cr_canseeotheruids() and > cr_canseeothergids(), repectively, and make them available outside of kern_prot.c. > > 7. Create a netstack module > > kern/{uipc_socket.c,vfs_default.c,vfs_export.c} > mk/bsd.own.mk > modules/netstack > net/{if_gre.c,netstack.c} > netpfil/ipfw/ip_fw2.c > netpfil/pf/pf_ioctl.c > netinet/ip_gre.c > > Add SCTP to the MK_*_SUPPORT variables that need to be set. > Add dependency on the netstack module. > Added vfs_stdcheckexp() to kern/vfs_default.c which calls the netstack vfs_stdcheckexp method. > Moved socket FIB assignment from the process to the netstack socreate method. > Moved VFS "export" handling to netstack methods and changed vfs_export() and vfs_setpublicfs() > to call the respective netstack methods. > > The netstack module includes INET, INET6, and SCTP support. > > Note: The only issue with including SCTP support, there is currently a dependency set on the > crypto module. This is because SCTP needs SHA1 and SHA2-256 support. However, this could be provided > by a number of different modules, so depending on crypto module might not be the best choice. > Any thoughts on this? > > 8. Remove SO_SETFIB processing from sosetop and move it to ctloutput functions > > kern/uipc_socket.c > net/route.[ch] > netinet/{ip_output.c,raw_ip.c} > netinet6/ip6_output.c > > Remove SO_SETFIB processing from sosetopt and move it instead to the ip_ctloutput(), > ip6_ctloutput(), and rip_ctloutput() functions. > Introduce the rtsosetfib() function to set so_fibnum, as appropriate. > The *_ctloutput functions call the RT_SOSETFIB macro in order to call rtsosetfib() only when > sockopt level is SOL_SOCKET and name is SO_SETFIB. > > 9. Define INET and INET6 in CFLAGS instead of relying on opt_inet.h and opt_inet6.h in modules > > modules/{carp,em,if_gre,ipdivert,ipfw,netstack,pf,pfsync,toecore}/Makefile > > Use CFLAGS to define INET and INET6 based on MK_INET_SUPPORT and MK_INET6_SUPPORT, > respectively, instead of relying on opt_inet.h and opt_inet6.h. > We need to do this in orer to be able to build NIC driver modules and the network stack as > modules when the base kernel does not have netstack compiled in. > > 10. Make accept filters part of the standard files > > conf/files > kern/{uipc_accf.c,uipc_socket.c} > netinet/in_proto.c > > Make accept filters part of the standard files, as they could be used by things other than INET > (and it eliminates a dependency on INET for uipc_socket.c) > Move net.inet.accf.unloadable to net.accf.unloadable > Add net.inet.accf node to in_proto.c in order to support existing accept filter sysctls. > > 11. Split IPv4 and IPv6-specific jail functions to netinet and netinet6, respectively. > > kern/kern_jail.c > netinet/in_jail.c > netinet6/in6_jail.c > sys/jail.h > > Split IPv4 and IPv6-specific functions from kern/kern_jail.c into netinet/in_jail.c and > netinet6/in6_jail.c, respectively. > > Change _prison_check_ipv[4|6]() to prison_check_ipv[4|6]_locked() and expose them via jail.h > Change qcmp_v[4|6]() to prison_qcmp_v[4|6] and expose them via jail.h > > -- > Stephen J. Kiernan > Juniper Networks, Inc. > stevek_at_juniper.net > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Thu Jan 17 22:02:39 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 B1D859CA for ; Thu, 17 Jan 2013 22:02:39 +0000 (UTC) (envelope-from stevek@juniper.net) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by mx1.freebsd.org (Postfix) with ESMTP id 8715A800 for ; Thu, 17 Jan 2013 22:02:39 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUPh0/xKKKBniI2vWvqUm7f4UskikYzJx@postini.com; Thu, 17 Jan 2013 14:02:39 PST Received: from stevek-ubuntu (172.25.4.212) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Thu, 17 Jan 2013 13:53:28 -0800 Date: Thu, 17 Jan 2013 16:53:23 -0500 From: Steve Kiernan To: Andre Oppermann Subject: Re: Proposal for changes to network device drivers and network stack (RFC) Message-ID: <20130117165323.5bfb8ff5@stevek-ubuntu> In-Reply-To: <50F868FF.5060506@networx.ch> References: <50F868FF.5060506@networx.ch> Organization: Juniper Networks Inc. X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 22:02:39 -0000 On Thu, 17 Jan 2013 22:11:27 +0100 Andre Oppermann wrote: > On 17.01.2013 20:23, Stephen J. Kiernan wrote: > > The network stack as a module patch has been separated out and can be found in the following location: > > http://people.freebsd.org/~marcel/Juniper/netstack-v2.diff > > This is quite some work and a lot of changes which will a moment to review. > > Can you describe the concept and the terminology you're using here some more? > What is a netstack module and what is its scope? How does it relate to VNET? > What is an IOCGROUP? etc. All this is probably obvious to you but not yet for > us. Sure, not a problem. First, I will repeat here what Anu sent out previously as a description of the netstack changes. > Today, not compiling networking stack related files in the kernel breaks > the kernel build due to dependencies the OS has on the network stack > (calling into functions in the network stack). Network stack module isn't > there. We've added these in JUNOS. The benefits for us are obvious (we can > load our own version of network stack if we desire!), but most likely this > functionality will benefit others too. > > The detailed implementation is indicated later in this email. In short the > changes are: > > - Load network stack as a module. For now via loader, not dynamically > loaded. (Is there interest in dynamic loading?). > - To facilitate calling network stack functionality from the generic > kernel, a new interface has been defined with the kobj framework. > - Some files and tunables needed to move to generic kernel areas (accept > filters) > - Generic socket code calls into network stack for interface and route > related ioctls. Network stack now registers these ioctl groups > - Other changes: uuid generation (register/query uuid sources), fib/sctp > system calls (moved to network stack code, with system calls register > dynamically). What we want to be able to do is select either the FreeBSD network stack or some other network stack (currently from the boot loader.) In order to do this, we need to be able to build a FreeBSD kernel without the network stack and have the network stack as a KLD. When the network stack is a module, it must be loaded early before the kernel boots due to limitations in the implementation of some parts of the kernel (for example, the domain handling in uipc_domain.c.) Also, with the changes for the netstack module, the ioctl group code uses a similar method to avoid having to locking during runtime by not allowing registration once things are finalized. By IOCGROUP, I mean the macro that is defined in sys/ioccom.h, which I assume is supposed to mean ioctl group. I then use that name as a basis for registering ioctl extensions based on the IOCGROUP. Since it is handled from the socket code, I used SO_ as a prefix for the macro name, thus the SO_IOCGROUP_SET() macro was born. As for VNET, I haven't done anything special for that. However any other network stack may not have VNET support. Although Mikolaj Golub noted in a previous reply to the original e-mail that Anu sent out that there are issues with virtualized global variables in modules. I did not check to see if the patch that was mentioned has been incorporated yet. All that was done to support the network stack as a module was to move network specific pieces in sys/kern to the appropriate net* directory instead. Any place in the base kernel code that needed to call into the network stack was then changed to use the netstack kobj to call through, which has default routines for when no network stack is loaded. The only current caveat with the changes are there's still some additional work that needs to be done for jails when using the network stack as a module. However, if the network stack is compiled into the kernel (via the NETSTACK option, which is part of the DEFAULTS kernel configuration file with these changes) then there is no problems with using jails. Hopefully this explained things well enough. Let me know if you need anything else specificly answered. -- Stephen J. Kiernan Juniper Networks, Inc. stevek_at_juniper.net From owner-freebsd-net@FreeBSD.ORG Thu Jan 17 23:08:11 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3406B76 for ; Thu, 17 Jan 2013 23:08:11 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id C5137B3A for ; Thu, 17 Jan 2013 23:08:10 +0000 (UTC) Received: by mail-we0-f169.google.com with SMTP id t11so354768wey.14 for ; Thu, 17 Jan 2013 15:08:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to:x-gm-message-state; bh=B9caUxz3FGUEgalPqtSPMNzHA/ESdSC7vD7MaWD6Uvg=; b=ktxjBEKLhgXScaIDez4+EkgzQXwzcQnZHMceSB/mxZJh5cIhgx7jgMdDpbUPc0twsZ u6M7wv+TucjYZLco0q/b6L0PNyCSvvB8YaZQs+pi6RGj88WcdbjEPjwah3qrlUb1zU9r EAOZgpNS7A5XA3E46WGKBxGDWN5EnnaaJwkOeEbmP1lrbMR/daOjlsuQRPqTyiRberGM /nczimHm6sVveYeOyo8puVQ3xyj/57jst4H543DpIqn/jjvWASq7APrPpz9PlEujZaog fy3jSg8ne8JWdWP1ZZW82ckXrUFSy5m3KJo00+V8YOS8wkwXJm0rr8Kt72ugGeq6lnWX q9Lw== X-Received: by 10.194.236.68 with SMTP id us4mr11165986wjc.11.1358464089945; Thu, 17 Jan 2013 15:08:09 -0800 (PST) Received: from [10.208.188.183] ([92.90.16.102]) by mx.google.com with ESMTPS id df2sm824725wib.0.2013.01.17.15.08.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Jan 2013 15:08:08 -0800 (PST) References: <50F868FF.5060506@networx.ch> <20130117165323.5bfb8ff5@stevek-ubuntu> In-Reply-To: <20130117165323.5bfb8ff5@stevek-ubuntu> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <6AC27A59-9B9E-4D60-A5E4-E9C8FEF50F1D@my.gd> X-Mailer: iPhone Mail (9A405) From: Damien Fleuriot Subject: Re: Proposal for changes to network device drivers and network stack (RFC) Date: Fri, 18 Jan 2013 00:07:06 +0100 To: Steve Kiernan X-Gm-Message-State: ALoCoQnij1/qwu5sWYtvQVb6O744cH87QqxJgwqTK8vsAmhtrG8Han3mutqdEWTrIgDEk4wYSr+r Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 23:08:11 -0000 On 17 Jan 2013, at 22:53, Steve Kiernan wrote: > On Thu, 17 Jan 2013 22:11:27 +0100 > Andre Oppermann wrote: >=20 >> On 17.01.2013 20:23, Stephen J. Kiernan wrote: >>> The network stack as a module patch has been separated out and can be fo= und in the following location: >>> http://people.freebsd.org/~marcel/Juniper/netstack-v2.diff >>=20 >> This is quite some work and a lot of changes which will a moment to revie= w. >>=20 >> Can you describe the concept and the terminology you're using here some m= ore? >> What is a netstack module and what is its scope? How does it relate to V= NET? >> What is an IOCGROUP? etc. All this is probably obvious to you but not ye= t for >> us. >=20 > Sure, not a problem. First, I will repeat here what Anu sent out previousl= y as a description of the netstack changes. >=20 >> Today, not compiling networking stack related files in the kernel breaks >> the kernel build due to dependencies the OS has on the network stack >> (calling into functions in the network stack). Network stack module isn't= >> there. We've added these in JUNOS. The benefits for us are obvious (we ca= n >> load our own version of network stack if we desire!), but most likely thi= s >> functionality will benefit others too. >>=20 >> The detailed implementation is indicated later in this email. In short th= e >> changes are: >>=20 >> - Load network stack as a module. For now via loader, not dynamically >> loaded. (Is there interest in dynamic loading?). I speak only for myself but I think dynamic loading would avoid a lot of tro= uble with/for people who don't read UPDATING carefully and forget to adjust l= oader.conf... From owner-freebsd-net@FreeBSD.ORG Thu Jan 17 23:11: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 CBC6F152 for ; Thu, 17 Jan 2013 23:11:13 +0000 (UTC) (envelope-from dspisak@agiosat.net) Received: from mail-da0-f43.google.com (mail-da0-f43.google.com [209.85.210.43]) by mx1.freebsd.org (Postfix) with ESMTP id A1180B60 for ; Thu, 17 Jan 2013 23:11:13 +0000 (UTC) Received: by mail-da0-f43.google.com with SMTP id u36so1333491dak.30 for ; Thu, 17 Jan 2013 15:11:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:x-gm-message-state; bh=/ktkXC0xkO4mNWH2yPztB0xIQd2OoihFLVpWPe6Kf7w=; b=PLoBiVB6l0A+osM0JYFfrOwoS5N8kWcEZc6zlTB+2mJpgR1Aqq7ytt/Sh7bseDGkGj CJKV3tQq2OwqHTS+UFQL0M8Wuwms2uoihbSZx6WpGuP9xITgA3M3IjJKsf5qMJS8MnEg oic13n/7k2HiBSogT+hvx/dOuKDXnpUapBY9OssisBCyP9qYca0DynsRMlLrW07K9hbp gHYba5MPsFbfCav6CEldrexjGjf42avtvA8EAXt7O2/KpbYIxiE8YObbYZR9QCoRCXYM z7N7pqu8HBi6SorYBMsr31u9MvvUKOoz7FxUVuV1jfztal+nS3FjeuIic1JuvewfPl3L zcBA== X-Received: by 10.68.189.163 with SMTP id gj3mr18034854pbc.110.1358464267120; Thu, 17 Jan 2013 15:11:07 -0800 (PST) Received: from [192.168.123.154] (rrcs-74-62-198-26.west.biz.rr.com. [74.62.198.26]) by mx.google.com with ESMTPS id bv10sm2121365pab.14.2013.01.17.15.11.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Jan 2013 15:11:06 -0800 (PST) Message-ID: <50F88509.5040602@agiosat.net> Date: Thu, 17 Jan 2013 15:11:05 -0800 From: Daniel Spisak User-Agent: Postbox 3.0.6 (Windows/20121031) MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Freebsd 8.3-RELEASE kernel panics when Xorp-1.8.6 tries to shutdown References: <50F78416.8080901@agiosat.net> In-Reply-To: <50F78416.8080901@agiosat.net> X-Gm-Message-State: ALoCoQlTpxuZY/AhUZq5WYVAPK+gRjVLoRe6twAhPlwYqy/31OEsfeLqZWAD0GfzS46IsgB/l5kd Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Thu, 17 Jan 2013 23:11:13 -0000 Is anyone that is familiar with the FreeBSD multicast networking code able to speak up here regarding these kernel panics? Thanks. > Daniel Spisak > Wednesday, January 16, 2013 8:54 PM > Hi there, I'm new to the list! > > Myself and a colleague have been trying to use Xorp 1.8.6 (we pulled > the source from the git repo about a two months ago) to handle > multicast routing over GRE tunnels for a rather convoluted scenario. > In the course of trying to get that setup working (which will be > another separate email to the list) we seem to be running into > behavior from Xorp that is causing kernel panics to happen on FreeBSD > 8.3-RELEASE. > > Currently, we are able to startup Xorp normally with no apparent > problems. However, as soon as we try to shutdown the Xorp service or > initiate a system reboot the system will kernel panic. We are running > Xorp on ALIX1.D single board computers. You can see more about the > hardware specs here: > > http://pcengines.ch/alix1d.htm > > I have created a file dump of some of the kernel panics along with > some kdbg backtraces for developers to take a look at (along with a > kernel.debug for our kernel build). If I am reading the backtraces > right, it looks like there might be an issue being caused by IGMP > somehow. Perhaps a mismatch between v2 and v3? > > http://www.mediafire.com/?ojxdc172mp7q6 > > I'm pretty new to Xorp and multicast so its possible I've missed > something here. I've gone ahead and used send-pr to submit the error > and you can find it here: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=175365 > > Output from fbsd for interfaces: > > dispatch-dev# ifconfig -a > vr0: flags=8a43 > metric 0 mtu 1500 > > options=8280b > ether 00:0d:b9:0e:32:d4 > inet XX.XX.XXX.XX netmask 0xfffffffc broadcast XX.XX.XXX.XX > inet 192.168.10.2 netmask 0xffffff00 broadcast 192.168.10.255 > inet 10.13.8.253 netmask 0xffffff80 broadcast 10.13.8.255 > media: Ethernet autoselect (100baseTX ) > status: active > lo0: flags=8049 metric 0 mtu 16384 > options=3 > inet 127.0.0.1 netmask 0xff000000 > enc0: flags=0<> metric 0 mtu 1536 > pflog0: flags=0<> metric 0 mtu 33200 > gre0: flags=9010 metric 0 mtu 1476 > > If anyone has any input/insight as to what is causing the kernel > panics and how to fix it, that would be great. Thanks! > -- Daniel Spisak Network Engineer dspisak@agiosat.net From owner-freebsd-net@FreeBSD.ORG Thu Jan 17 23:22:37 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 C993B5C2 for ; Thu, 17 Jan 2013 23:22:37 +0000 (UTC) (envelope-from stevek@juniper.net) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by mx1.freebsd.org (Postfix) with ESMTP id 8148DC37 for ; Thu, 17 Jan 2013 23:22:34 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKUPiHuXV7JU0Zpv7m30LDmhidP8f+UZbA@postini.com; Thu, 17 Jan 2013 15:22:37 PST Received: from stevek-ubuntu (172.25.4.212) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Thu, 17 Jan 2013 15:21:50 -0800 Date: Thu, 17 Jan 2013 18:21:45 -0500 From: Steve Kiernan To: Damien Fleuriot Subject: Re: Proposal for changes to network device drivers and network stack (RFC) Message-ID: <20130117182145.0d174c82@stevek-ubuntu> In-Reply-To: <6AC27A59-9B9E-4D60-A5E4-E9C8FEF50F1D@my.gd> References: <50F868FF.5060506@networx.ch> <20130117165323.5bfb8ff5@stevek-ubuntu> <6AC27A59-9B9E-4D60-A5E4-E9C8FEF50F1D@my.gd> Organization: Juniper Networks Inc. X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 23:22:37 -0000 On Fri, 18 Jan 2013 00:07:06 +0100 Damien Fleuriot wrote: > > On 17 Jan 2013, at 22:53, Steve Kiernan wrote: > > > On Thu, 17 Jan 2013 22:11:27 +0100 > > Andre Oppermann wrote: > > > >> On 17.01.2013 20:23, Stephen J. Kiernan wrote: > >>> The network stack as a module patch has been separated out and can be found in the following location: > >>> http://people.freebsd.org/~marcel/Juniper/netstack-v2.diff > >> > >> This is quite some work and a lot of changes which will a moment to review. > >> > >> Can you describe the concept and the terminology you're using here some more? > >> What is a netstack module and what is its scope? How does it relate to VNET? > >> What is an IOCGROUP? etc. All this is probably obvious to you but not yet for > >> us. > > > > Sure, not a problem. First, I will repeat here what Anu sent out previously as a description of the netstack changes. > > > >> Today, not compiling networking stack related files in the kernel breaks > >> the kernel build due to dependencies the OS has on the network stack > >> (calling into functions in the network stack). Network stack module isn't > >> there. We've added these in JUNOS. The benefits for us are obvious (we can > >> load our own version of network stack if we desire!), but most likely this > >> functionality will benefit others too. > >> > >> The detailed implementation is indicated later in this email. In short the > >> changes are: > >> > >> - Load network stack as a module. For now via loader, not dynamically > >> loaded. (Is there interest in dynamic loading?). > > I speak only for myself but I think dynamic loading would avoid a lot of trouble with/for people who don't read UPDATING carefully and forget to adjust loader.conf... By default, the network stack is compiled into the kernel. This is so functionality isn't changed by default, but building the network stack as a module is supported. So, unless someone wants to replace the network stack (and thus compile a kernel without networking), they get the network stack be default. This is what I added the NETSTACK option to DEFAULTS. One would need to use "nooptions NETSTACK" to turn it off. -- Stephen J. Kiernan Juniper Networks, Inc. stevek_at_juniper.net From owner-freebsd-net@FreeBSD.ORG Fri Jan 18 01:46:55 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 72AAAE4 for ; Fri, 18 Jan 2013 01:46:55 +0000 (UTC) (envelope-from sales1@pingbrother.com) Received: from mikroweb.hu (mikroweb.hu [194.152.143.74]) by mx1.freebsd.org (Postfix) with ESMTP id 1090F29E for ; Fri, 18 Jan 2013 01:46:54 +0000 (UTC) Received: from [10.1.171.21] by mikroweb.hu with esmtp (Exim 4.77) (envelope-from ) id 1TvzUt-0002F0-SB for freebsd-net@freebsd.org; Fri, 18 Jan 2013 01:07:53 +0100 MIME-Version: 1.0 Subject: What breed of a dog can text you? To: freebsd-net@freebsd.org From: PingBrother Networking Date: Fri, 18 Jan 2013 01:07:37 +0100 Message-ID: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Description: Mail message body 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: sales1@pingbrother.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 01:46:55 -0000 = = =

= = is watching your devices = - MONITORING - CONTROL - WATCHDOG = = = What breed of a dog can text you? = =85a PingBrother watchdog. = Easy! Check out our video demo to see how smart our watchdog device is. = = = = What is PingBrother? Click to play. = = Click here for the full length video demo. = Order your sample now at sales@pingbrother.com = = EPIW 104 for 109 EUR (list price) = EPIW 104P for 135 EUR (list price For quantity based discount prices please see our = product comparison table with prices: USD / EUR. = For more information on our products and services please visit our website: = www.pingbrother.com = subscribe unsubscribe = = = = = = PingBrother is = a 4 port industrial 10/100 passive POE ethernet switch and IP watchdog wit= h built in web based GUI. It is an intelligent device, which watches a lot= of qualities of its environment, such as input voltage, temperature, curre= nt consumption of the connected POE devices, operability of any network dev= ices (ping, http availability), water leakage or condensation. = It gives a user defined response, for example turns off /on or reset the p= ower of the POE ethernet ports, controls any connected device by its relay = contact, and/or sends an email. PingBrother can work on nearly any low voltage (8-56V DC or 9-42V AC), and = can distribute its input power to any kind of connected standard or non sta= ndard POE devices (PD). = PingBrother can manage other, non-IP devices through the relay contacts co= nnected to the terminal blocks. = = =20 From owner-freebsd-net@FreeBSD.ORG Fri Jan 18 10:54:28 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D0AE7D72 for ; Fri, 18 Jan 2013 10:54:28 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 81C90E59 for ; Fri, 18 Jan 2013 10:54:28 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Tw9aq-0006tt-MV for freebsd-net@freebsd.org; Fri, 18 Jan 2013 11:54:40 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 18 Jan 2013 11:54:40 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 18 Jan 2013 11:54:40 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Subject: Re: VMware vmxnet2 driver Date: Fri, 18 Jan 2013 11:54:12 +0100 Lines: 39 Message-ID: References: <975792706.137.1358145587551.JavaMail.root@daemoninthecloset.org> <1873789450.140.1358145734760.JavaMail.root@daemoninthecloset.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig24C4E56464DCB29C62455C42" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120812 Thunderbird/14.0 In-Reply-To: <1873789450.140.1358145734760.JavaMail.root@daemoninthecloset.org> X-Enigmail-Version: 1.4.3 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, 18 Jan 2013 10:54:28 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig24C4E56464DCB29C62455C42 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 14/01/2013 07:42, Bryan Venteicher wrote: > Any testing or performance data is welcome. For bulk TCP transfers, if_= vic > will tend to be faster than em (~1/2 a magnitude) due to TSO, but I don= 't > think that warrants merging into HEAD yet. Considering that from your description the current situation is: * The driver isn't *worse* than either em or the "official" VMWare driver (right?) * There is currently no vmxnet driver at all in HEAD =2E.. I don't think including the driver will harm anyone or anything, bu= t it may make things a bit simpler when configuring VMs. --------------enig24C4E56464DCB29C62455C42 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlD5KdUACgkQ/QjVBj3/HSzUHACfWj86vfhQAXTk4dBM/tnOTKcM P/0AniNlCrll9WeIJEqEtT9a21GBIzOY =bdxn -----END PGP SIGNATURE----- --------------enig24C4E56464DCB29C62455C42-- From owner-freebsd-net@FreeBSD.ORG Fri Jan 18 12:47:37 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 6951B40D for ; Fri, 18 Jan 2013 12:47:37 +0000 (UTC) (envelope-from venkatduvvuru.ml@gmail.com) Received: from mail-da0-f50.google.com (mail-da0-f50.google.com [209.85.210.50]) by mx1.freebsd.org (Postfix) with ESMTP id 4C0EE6AA for ; Fri, 18 Jan 2013 12:47:37 +0000 (UTC) Received: by mail-da0-f50.google.com with SMTP id h15so1620818dan.23 for ; Fri, 18 Jan 2013 04:47:36 -0800 (PST) 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=Yp7TwzRdlb1QFjurEheD0xxp9qOYZC2SihIftDBzXk4=; b=pXHo/CzNXRxfvlf+gHq1TSj9W8ut9R0KH2v2cFvys+XX5BbR76a4350lhiHevW0a66 OnVLlnzfD7PrDYTWlz05AzGbL34A52BaThOBMQ/Cb9j0z9a02KtS3Ndm2MV6ae2jux8B GuBRNz3WuCVdGkK8eqZHI8L5AkBU4zI9D7M2uPugxhjDBktW+xzZPgEsRNtidG+XOCk7 CCE7Bfg+wkwMrZbL7hZRInf0k/HG6tklYZJpFHfQyuAhGvTUj6nUZhp/OzsRitaJkku6 TqNhcaKRs5YsmOMZNOPOm/JTxIf4E2NFViiKujYAEMFY+EnP/8ss7Ng6/HW5TPzn7EWN gtVA== MIME-Version: 1.0 X-Received: by 10.68.227.33 with SMTP id rx1mr4907586pbc.67.1358512837540; Fri, 18 Jan 2013 04:40:37 -0800 (PST) Received: by 10.66.100.196 with HTTP; Fri, 18 Jan 2013 04:40:37 -0800 (PST) Date: Fri, 18 Jan 2013 18:10:37 +0530 Message-ID: Subject: oce patches for freebsd-9.1 From: Venkat Duvvuru 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: Fri, 18 Jan 2013 12:47:37 -0000 Hi, I have to submit some patches for Emulex's "oce" driver. Could you please let me know if http://www.freebsd.org/send-pr.html is the correct way of submitting them? /Venkat From owner-freebsd-net@FreeBSD.ORG Fri Jan 18 14:12:34 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 A261291A for ; Fri, 18 Jan 2013 14:12:34 +0000 (UTC) (envelope-from seanwbruno@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7E74F9FA for ; Fri, 18 Jan 2013 14:12:34 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rr4so228023pbb.27 for ; Fri, 18 Jan 2013 06:12:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:from:reply-to:to:cc:in-reply-to:references :content-type:date:message-id:mime-version:x-mailer; bh=sw0MxgxMfes86ffT6+ai24ZfJa5i3s4/OHYz5b1Prcs=; b=IV9qPXWawQeDb6TobH8cBVUlNynHz+WwOdKgDiGAwYk7YOVuonhFa3BytIAInUDT+o W8sjHBl0R3V4g+tqiCfS7BZ8eAZmDzZmkpNsU/BH+BQOyi2923J7WRRsfvo63tyWUcl+ dbcl2+zdQ0o/9CqlV2p5/YYTMR6vE4hYpg84BjxahZeAg5onj3JUB9qiOInhT8b4msiA Z/aLb82SmDvZXcLORUjjz3O9Is26oXX2fxoHpneAKyrELR+aQKZSanQnz4eIsN8Kby5H ECmul0rY9u6WRnPKkQiMhaczuMVEFcXD3VxSNYSJWvPwys4m1PvWIXSohpLWKnOzWzmI 9k1A== X-Received: by 10.68.239.104 with SMTP id vr8mr5721964pbc.59.1358518348612; Fri, 18 Jan 2013 06:12:28 -0800 (PST) Received: from [192.168.1.205] (c-71-202-40-63.hsd1.ca.comcast.net. [71.202.40.63]) by mx.google.com with ESMTPS id ql9sm3155872pbc.61.2013.01.18.06.12.26 (version=SSLv3 cipher=RC4-SHA bits=128/128); Fri, 18 Jan 2013 06:12:27 -0800 (PST) Subject: Re: oce patches for freebsd-9.1 From: Sean Bruno To: Venkat Duvvuru In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-qWXklYFztAb7jxFQNWpq" Date: Fri, 18 Jan 2013 06:12:25 -0800 Message-ID: <1358518345.3216.4.camel@powernoodle> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 14:12:34 -0000 --=-qWXklYFztAb7jxFQNWpq Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2013-01-18 at 18:10 +0530, Venkat Duvvuru wrote: > Hi, > I have to submit some patches for Emulex's "oce" driver. Could you pleas= e > let me know if http://www.freebsd.org/send-pr.html is the correct way of > submitting them? >=20 > /Venkat Yes please. That would be the first place so that they are saved! If you can, please set the assign-to to "freebsd-net" and that way the patch will show up on the mailing list. Sean --=-qWXklYFztAb7jxFQNWpq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAABAgAGBQJQ+VhJAAoJEBkJRdwI6BaHPuoIAJL+3igIPEa1iE79lwipk2q/ VL+AkuwsfzaVCBtfTAXEh9Q9rwxSHnwDEfMGhb58RsqJit4oRjBRqTWMdAmLa0W0 Bkq9+wWFBDGmEiSU1EqEvZV2yK4ehxRQQh+HJiOr2stryQJYlrePLYAvExHLgJkk ydOmL2o3mlHExg/h+whm59jkxjX/SxymQY6UIpgRtnwSQQmQWrM7YxiIgpofhOyN TLW2Dlw4cAkN9YsKYT6kVjViXXYQQY8flhBDBkJrndX0yIZCKZqRtNHWISs3n7eA LaxaOtD3hm8o+GiGB914Yn2Vg1uRBl3U7vDGVP7laDc62AbMPUNQguMYfRjGW+I= =ChW4 -----END PGP SIGNATURE----- --=-qWXklYFztAb7jxFQNWpq-- From owner-freebsd-net@FreeBSD.ORG Fri Jan 18 14:30:23 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1FD3677 for ; Fri, 18 Jan 2013 14:30:23 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm33-vm8.bullet.mail.ne1.yahoo.com (nm33-vm8.bullet.mail.ne1.yahoo.com [98.138.229.72]) by mx1.freebsd.org (Postfix) with ESMTP id D3F85AFC for ; Fri, 18 Jan 2013 14:30:22 +0000 (UTC) Received: from [98.138.90.51] by nm33.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jan 2013 14:30:16 -0000 Received: from [98.138.89.254] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jan 2013 14:30:16 -0000 Received: from [127.0.0.1] by omp1046.mail.ne1.yahoo.com with NNFMP; 18 Jan 2013 14:30:16 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 826768.88800.bm@omp1046.mail.ne1.yahoo.com Received: (qmail 56221 invoked by uid 60001); 18 Jan 2013 14:30:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1358519416; bh=Nu7pTW4v/J5nMIohhxuwGv8bTUBis0K5WDRr5itZgpg=; 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=X6OFCrtA3nRxsTBv72WiLWhCLps5BcdNnSkgPI0twjhTzLtnJCD16cnIIE1JlidR0OnGlBFNWUTXrvdIRxrqzvUScGx08GHwuwZ6G/8MOoSzCriPxeEkyE70lmvmEuP8dZao86mdrgSxus49ougG9WicfcL88NbfQdBG/l9V1Ok= 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=hpyMMPcbnzQe0LxY0T5PK2+wvkCAXO236ZrJKQqCj7gpRO7rlbwvW/xnyik+4cG01U9zZgmxTh6hMBlN/RcOgzHHkakuZSfIxwjf/ZzEXAq4lhUSu7X66n3DO/zTGNAeCyuA0BxF4AuxkoLyFS0pgDq3hfk/bYqv3RlA9zD5yMY=; X-YMail-OSG: NwpVQmcVM1lIVtqyA7Gtoczv2ItKBvbY7orjayA75WGYkQA 9MRagQFGS7GTa9sDAG7DOxzeTIiaobXXePn7tQKmi.WTZfxO_fBxHZaEiFVW iwTzCplMz8YhYVJNTBmXQvjQsyqV_Jo9VwAoqyGyuxfaDhQJ78FPcF06yNYA ilMvAkLZ5xfvd5WKkz00Thz50XwwpUWVNJsITcEqGmtbRKKZehCIFa5xgFeL PbSO_amomai7KINKW2bgZvm4DhDTuxp_f_y_GsSwg4XLPWZZZRR6V6kIfj31 8dU810V1cXlDwBlejtowX3GgP9UzKuPAZdPl8pEl_IlEm8dax7MB1IxEuzn2 lsTBjJZyJsTbJfyClyudg00k5sVcCsu1qJsmVtFDnLb.gZ1kEE2.I60vVHgM C4FY16QieaaCB.H5PStG495DmBhXQPx_v9lJHGGjYMQezHbmQtgoVVsGWr9x fvHautLKZCZu.QzpJwDlN2huuLuffAefOUqzjlvQS_N83Gdz1BuV77BeMLfz E38NfWMCYjFWy2u9lCRcLg9JgIHgG Received: from [174.48.128.27] by web121606.mail.ne1.yahoo.com via HTTP; Fri, 18 Jan 2013 06:30:16 PST X-Rocket-MIMEInfo: 001.001, DQoNCi0tLSBPbiBUaHUsIDEvMTcvMTMsIEFkcmlhbiBDaGFkZCA8YWRyaWFuQGZyZWVic2Qub3JnPiB3cm90ZToNCg0KPiBGcm9tOiBBZHJpYW4gQ2hhZGQgPGFkcmlhbkBmcmVlYnNkLm9yZz4NCj4gU3ViamVjdDogUmU6IHR3byBwcm9ibGVtcyBpbiBkZXYvZTEwMDAvaWZfbGVtLmM6OmxlbV9oYW5kbGVfcnh0eCgpDQo.IFRvOiAiQmFybmV5IENvcmRvYmEiIDxiYXJuZXlfY29yZG9iYUB5YWhvby5jb20.DQo.IENjOiAiTHVpZ2kgUml6em8iIDxyaXp6b0BpZXQudW5pcGkuaXQ.LCBmcmVlYnNkLW5ldEBmcmUBMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.130.494 Message-ID: <1358519416.46817.YahooMailClassic@web121606.mail.ne1.yahoo.com> Date: Fri, 18 Jan 2013 06:30:16 -0800 (PST) From: Barney Cordoba Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() To: Adrian Chadd In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-net@freebsd.org, Luigi Rizzo 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, 18 Jan 2013 14:30:23 -0000 --- On Thu, 1/17/13, Adrian Chadd wrote: > From: Adrian Chadd > Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() > To: "Barney Cordoba" > Cc: "Luigi Rizzo" , freebsd-net@freebsd.org > Date: Thursday, January 17, 2013, 11:48 AM > There's also the subtle race > condition in TX and RX handling that > re-queuing the taskqueue gets around. > > Which is: > > * The hardware is constantly receiving frames , right until > you blow > the FIFO away by filling it up; > * The RX thread receives a bunch of frames; > * .. and processes them; > * .. once it's done processing, the hardware may have read > some more > frames in the meantime; > * .. and the hardware may have generated a mitigated > interrupt which > you're ignoring, since you're processing frames; > * So if your architecture isn't 100% paranoid, you may end > up having > to wait for the next interrupt to handle what's currently in > the > queue. > > Now if things are done correct: > > * The hardware generates a mitigated interrupt > * The mask register has that bit disabled, so you don't end > up receiving it; > * You finish your RX queue processing, and there's more > stuff that's > appeared in the FIFO (hence why the hardware has generated > another > mitigated interrupt); > * You unmask the interrupt; > * .. and the hardware immediately sends you the MSI or > signals an interrupt; > * .. thus you re-enter the RX processing thread almost(!) > immediately. > > However as the poster(s) have said, the interrupt > mask/unmask in the > intel driver(s) may not be 100% correct, so you're going to > end up > with situations where interrupts are missed. > > The reason why this wasn't a big deal in the deep/distant > past is > because we didn't used to have kernel preemption, or > multiple kernel > threads running, or an overly aggressive scheduler trying > to > parallelise things as much as possible. A lot of > net80211/ath bugs > have popped out of the woodwork specifically because of the > above > changes to the kernel. They were bugs before, but people > didn't hit > them. > I don't see the distinction between the rx thread getting re-scheduled "immediately" vs introducing another thread. In fact you increase missed interrupts by this method. The entire point of interrupt moderation is to tune the intervals where a driver is processed. You might as well just not have a work limit and process until your done. The idea that "gee, I've been taking up too much cpu, I'd better yield" to just queue a task and continue soon after doesn't make much sense to me. BC From owner-freebsd-net@FreeBSD.ORG Fri Jan 18 14:30: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 36095133 for ; Fri, 18 Jan 2013 14:30:48 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm20-vm5.bullet.mail.ne1.yahoo.com (nm20-vm5.bullet.mail.ne1.yahoo.com [98.138.91.242]) by mx1.freebsd.org (Postfix) with ESMTP id EB865B09 for ; Fri, 18 Jan 2013 14:30:47 +0000 (UTC) Received: from [98.138.90.57] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jan 2013 14:30:40 -0000 Received: from [98.138.87.10] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jan 2013 14:30:40 -0000 Received: from [127.0.0.1] by omp1010.mail.ne1.yahoo.com with NNFMP; 18 Jan 2013 14:30:40 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 437099.29022.bm@omp1010.mail.ne1.yahoo.com Received: (qmail 92146 invoked by uid 60001); 18 Jan 2013 14:30:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1358519440; bh=Nu7pTW4v/J5nMIohhxuwGv8bTUBis0K5WDRr5itZgpg=; 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=ctFg64m4r2Grb08W6o7Kn6x/swgDFaMdbd7UtPOUEU++ZYkJNP/oe7WtWp4FUZOUTW9eDq+/0NV6SMsKIPEgFRnRB6DUz/MD4TAGodgusNmEP1+e6cozc5htRsfyRVkj2nNA+cK8QTdxEFpsofJfvh87NB74UIj+6KS/gOH5Ydg= 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=r3XUcdJWfqjkbmz6N6h+jTOw3tmQU6BvTdmFbGXoK7XhycMuYYlL1aiHxGTvxFms0/YuOwCvS2liFcvVAOyYGkNVeuoNQZAbrNzU4Y2JtUY7ZtsPJ6JifNsPqKStZRP9bSyou4VHf/psYdqr/Eu/QoEGr40k9BFb5wvQ9gMeOHs=; X-YMail-OSG: m4rxVdQVM1nmDWZvtuEEj.O62_VVFaFtIzC.Xmkr4YMykPh 098BGPQlsyp5WZYDGQeXzUp5VTmiCxZ7iicZaVpWME.f7hP_n.hFVOXKfIMC AlbSME46AeBtaLBcWzs9RQBbp98Qq7Do0ltl1v.EvJQDBh1t73f49LOw2769 5EJcFm8IBEGfOMIB99_dd.p2IS7aTvtxvIkdpMRFFgzMo3NxB088r7F05bC0 eB3OQut2oKq62jNushnPk7kRvtRaOTyLID41oHCdkAAopxcW1gC2RCwDtT1k 8SjWMfJNnTqlQVvk.YHAVU8sguwYjx1BfrrpsuyczRIUJay.OmKGdTut_l1V DBIuY9.Pf8RvWhm1_D.638mKvGFBrGLREvt5suZQw.bsH7gmJelgqFgqyflQ i6tWMgK03_TVPvIvYMAtKuzXbn_I_O9o1f3yzyz.XM488HUZJxJKjJo3jKKy a_VR.kW.ALpDDIsDjYc1D9T3kkyFamwuc5URYXZDnGISt5xjUtXMLklh1hGC yCmQNKQszSxnExi0ym3HoEcsxc1xS Received: from [174.48.128.27] by web121605.mail.ne1.yahoo.com via HTTP; Fri, 18 Jan 2013 06:30:40 PST X-Rocket-MIMEInfo: 001.001, DQoNCi0tLSBPbiBUaHUsIDEvMTcvMTMsIEFkcmlhbiBDaGFkZCA8YWRyaWFuQGZyZWVic2Qub3JnPiB3cm90ZToNCg0KPiBGcm9tOiBBZHJpYW4gQ2hhZGQgPGFkcmlhbkBmcmVlYnNkLm9yZz4NCj4gU3ViamVjdDogUmU6IHR3byBwcm9ibGVtcyBpbiBkZXYvZTEwMDAvaWZfbGVtLmM6OmxlbV9oYW5kbGVfcnh0eCgpDQo.IFRvOiAiQmFybmV5IENvcmRvYmEiIDxiYXJuZXlfY29yZG9iYUB5YWhvby5jb20.DQo.IENjOiAiTHVpZ2kgUml6em8iIDxyaXp6b0BpZXQudW5pcGkuaXQ.LCBmcmVlYnNkLW5ldEBmcmUBMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.130.494 Message-ID: <1358519440.88044.YahooMailClassic@web121605.mail.ne1.yahoo.com> Date: Fri, 18 Jan 2013 06:30:40 -0800 (PST) From: Barney Cordoba Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() To: Adrian Chadd In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-net@freebsd.org, Luigi Rizzo 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, 18 Jan 2013 14:30:48 -0000 --- On Thu, 1/17/13, Adrian Chadd wrote: > From: Adrian Chadd > Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() > To: "Barney Cordoba" > Cc: "Luigi Rizzo" , freebsd-net@freebsd.org > Date: Thursday, January 17, 2013, 11:48 AM > There's also the subtle race > condition in TX and RX handling that > re-queuing the taskqueue gets around. > > Which is: > > * The hardware is constantly receiving frames , right until > you blow > the FIFO away by filling it up; > * The RX thread receives a bunch of frames; > * .. and processes them; > * .. once it's done processing, the hardware may have read > some more > frames in the meantime; > * .. and the hardware may have generated a mitigated > interrupt which > you're ignoring, since you're processing frames; > * So if your architecture isn't 100% paranoid, you may end > up having > to wait for the next interrupt to handle what's currently in > the > queue. > > Now if things are done correct: > > * The hardware generates a mitigated interrupt > * The mask register has that bit disabled, so you don't end > up receiving it; > * You finish your RX queue processing, and there's more > stuff that's > appeared in the FIFO (hence why the hardware has generated > another > mitigated interrupt); > * You unmask the interrupt; > * .. and the hardware immediately sends you the MSI or > signals an interrupt; > * .. thus you re-enter the RX processing thread almost(!) > immediately. > > However as the poster(s) have said, the interrupt > mask/unmask in the > intel driver(s) may not be 100% correct, so you're going to > end up > with situations where interrupts are missed. > > The reason why this wasn't a big deal in the deep/distant > past is > because we didn't used to have kernel preemption, or > multiple kernel > threads running, or an overly aggressive scheduler trying > to > parallelise things as much as possible. A lot of > net80211/ath bugs > have popped out of the woodwork specifically because of the > above > changes to the kernel. They were bugs before, but people > didn't hit > them. > I don't see the distinction between the rx thread getting re-scheduled "immediately" vs introducing another thread. In fact you increase missed interrupts by this method. The entire point of interrupt moderation is to tune the intervals where a driver is processed. You might as well just not have a work limit and process until your done. The idea that "gee, I've been taking up too much cpu, I'd better yield" to just queue a task and continue soon after doesn't make much sense to me. BC From owner-freebsd-net@FreeBSD.ORG Fri Jan 18 14:38:30 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 7E756596 for ; Fri, 18 Jan 2013 14:38:30 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm23-vm4.bullet.mail.ne1.yahoo.com (nm23-vm4.bullet.mail.ne1.yahoo.com [98.138.91.183]) by mx1.freebsd.org (Postfix) with ESMTP id 4BE8EC29 for ; Fri, 18 Jan 2013 14:38:30 +0000 (UTC) Received: from [98.138.90.55] by nm23.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jan 2013 14:35:04 -0000 Received: from [98.138.89.233] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jan 2013 14:35:04 -0000 Received: from [127.0.0.1] by omp1048.mail.ne1.yahoo.com with NNFMP; 18 Jan 2013 14:35:04 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 423574.32388.bm@omp1048.mail.ne1.yahoo.com Received: (qmail 571 invoked by uid 60001); 18 Jan 2013 14:35:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1358519704; bh=Q2fQbejkciLakSxDqQTPKhlT7+g0bObGGOpbv94ivD4=; 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=dlS19GrpGRFSXnP2MpiYV/+1knUNfr72iBtDZ216ht+UgEZjHP7PIrGkinDqyEFIeqFcQNZ82LqbD8pT6fbaB3psnJU5GMpWnTtxhVau6yY5jmcn1xJ/UCUiQpX6TApBFxyTo6EJ7d9/oMW/Rt6SF3YdosQnx9Gvfk+SuFaSu1E= 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=lIp16mJDhiHjAubSELenpkCxW5GlkiesZKo55vUUTokGLg258h3h2MRld5BJB814wXO2oTJr5zOC33vYMVuo4d+qR67nCGOIJTH5RMb9gRd85Bfku4COucpxTNdqIbxlPwsJDh+FqVwDv2fFcFr+ALLTSGFwrVteIOUUoFl6rk4=; X-YMail-OSG: KWBebAUVM1lxvZo7q0bQIrICFuC5GrKcHpEcLfrHWNhpW8m 0Xg0LO2mHOit8ML7qaBhbG6FJgmNXY62HHfd.L4hXHvQ53NskBWpV8LNsV0i _CTr3W_BK2iYA78qe_XtRJHOTKyq.ECx6frE.vUl2etVeofdly2usi2EzoOq 2M1zHyDSXxhcXe_kQiBlTygnwvJhKhsvu8W_GGfTpGOtyDE5lIhwDKr8u0.u KzU2GbNMnIlemVSpLFdmpi3h0VfO0z8rXpM99xnf_.idfLEU9TiIJkubXygQ ClCEBGnLaJZd5aplIygKQJDZkNdgbAZPP_hSt3h89SdsJLFEUUK8MJZnQRqU 5Uv8TOHNs.4RIsP5eh5l1X5eMcTf9TZuzmFo5KYuHNfx6GCjkW0YX.WFm1C2 4rCNUTpeKlXTdpUAfO1fdyxjtF5cHzk600b975SO.6gQ8trVcWMJnkObAVEe ORFb8kXLyQSBmWxgAuIyIhTbdAmEtLu9m4wUU9KfuqyVwb86RXR75r_Q4pHR Fzc2JVWWegpM6Fp7QO80c7b8ydWb6 Received: from [174.48.128.27] by web121605.mail.ne1.yahoo.com via HTTP; Fri, 18 Jan 2013 06:35:04 PST X-Rocket-MIMEInfo: 001.001, DQoNCi0tLSBPbiBUaHUsIDEvMTcvMTMsIEFkcmlhbiBDaGFkZCA8YWRyaWFuQGZyZWVic2Qub3JnPiB3cm90ZToNCg0KPiBGcm9tOiBBZHJpYW4gQ2hhZGQgPGFkcmlhbkBmcmVlYnNkLm9yZz4NCj4gU3ViamVjdDogUmU6IHR3byBwcm9ibGVtcyBpbiBkZXYvZTEwMDAvaWZfbGVtLmM6OmxlbV9oYW5kbGVfcnh0eCgpDQo.IFRvOiAiTHVpZ2kgUml6em8iIDxyaXp6b0BpZXQudW5pcGkuaXQ.DQo.IENjOiAiQmFybmV5IENvcmRvYmEiIDxiYXJuZXlfY29yZG9iYUB5YWhvby5jb20.LCBmcmVlYnNkLW5ldEBmcmUBMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.130.494 Message-ID: <1358519704.98312.YahooMailClassic@web121605.mail.ne1.yahoo.com> Date: Fri, 18 Jan 2013 06:35:04 -0800 (PST) From: Barney Cordoba Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() To: Luigi Rizzo , 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 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, 18 Jan 2013 14:38:30 -0000 --- On Thu, 1/17/13, Adrian Chadd wrote: > From: Adrian Chadd > Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() > To: "Luigi Rizzo" > Cc: "Barney Cordoba" , freebsd-net@freebsd.org > Date: Thursday, January 17, 2013, 2:04 PM > On 17 January 2013 09:44, Luigi Rizzo > > wrote: >=20 > > (in the "lem" driver this cannot happen until you > release some > > rx slots, which only happens once at the end of the > lem_rxeof() routine, > > not long before re-enabling interrupts) >=20 > Right. >=20 > >> * .. and the hardware immediately sends you the MSI > or signals an interrupt; > >> * .. thus you re-enter the RX processing thread > almost(!) immediately. > > > > the problem i was actually seeing are slightly > different, namely: > > - once the driver lags behind, it does not have a > chance to recover > >=A0=A0=A0even if there are CPU cycles > available, because both interrupt > >=A0=A0=A0rate and packets per interrupt are > capped. >=20 > Right, but the interrupt isn't being continuously asserted > whilst > there are packets there. > You just get a single interrupt when the queue has frames in > it, and > you won't get a further interrupt for whatever the > mitigation period > is (or ever, if you fill up the RX FIFO, right?) >=20 > > - much worse, once the input stream stops, you have a > huge backlog that > >=A0=A0=A0is not drained. And if, say, you try > to ping the machine, > >=A0=A0=A0the incoming packet is behind another > 3900 packets, so the first > >=A0=A0=A0interrupt drains 100 (but not the ping > request, so no response), > >=A0=A0=A0you keep going for a while, eventually > the external world sees the > >=A0=A0=A0machine as not responding and stops > even trying to talk to it. >=20 > Right, so you do need to do what you're doing - but I still > think > there's a possibility of a race there. > Namely that your queue servicing does reach the end of the > list (and > so you don't immediately reschedule the taskqueue) but some > more > frames have arrived. > You have to wait for the next mitigated interrupt for that. i don't think that's the case. The mitigation is a minimum delay. If the=20 delay is longer than the minimum, you'd get an interrupt as soon as you enable it, which is clearly better than scheduling a task. BC From owner-freebsd-net@FreeBSD.ORG Fri Jan 18 14:50:11 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1E51F8AC for ; Fri, 18 Jan 2013 14:50:11 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm24.bullet.mail.ne1.yahoo.com (nm24.bullet.mail.ne1.yahoo.com [98.138.90.87]) by mx1.freebsd.org (Postfix) with ESMTP id DA78AD8D for ; Fri, 18 Jan 2013 14:50:09 +0000 (UTC) Received: from [98.138.226.179] by nm24.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jan 2013 14:50:03 -0000 Received: from [98.138.87.7] by tm14.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jan 2013 14:50:03 -0000 Received: from [127.0.0.1] by omp1007.mail.ne1.yahoo.com with NNFMP; 18 Jan 2013 14:50:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 643241.45315.bm@omp1007.mail.ne1.yahoo.com Received: (qmail 86330 invoked by uid 60001); 18 Jan 2013 14:50:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1358520603; bh=WUOn90E/92tTghESQ+WasvtE2l5LKbkVm9qAy0nMfjY=; 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=1I59ST/0NCV4h67OzMz2seowITnfNu3/Li1wy1y11OrGtpURIZ3UDDCcBkDc/CRDVracq0uY+3tI2wz8MAzwBjDwtMP3O+/0DtQuWrZmo3VkkS/LL/nBr1Ls/9G3jhLZ7kiF6zCNfraLPjUzcsZ8g/cwoZkTzUwH8H/wyCXJt1k= 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=KUc68xEyHqywsMZ27RVcTq8g00x2HaYr3B7ECxOLIdu4/PUl5OO1ExeBWB4sMk2Khi9nZTjxVXkFy33CDBfs93e/gRpVhbXwiXZFpibgxN4Ir4cnC65lqfKdcnY7GzfOCyBi4D6Cybgh/D/MouIFnlugqI0S/5WZBqXd4FcaFDo=; X-YMail-OSG: 6L1ZSF4VM1nBc9PfJFkUV8nSKdX07d2QerNZUuIFQUrxLdM dABmqxB0wRdAfOnbBlrs6wnYsqZoqZLUTD2BwZrlubystPUlsH1dZvoZ_dis fRrvo9ubwlOgxaKgRv_3Rv2gwymmh_hgVVkh4IC2BzxTy7eMaaeKSvagQxnz vDJb9J1gAbbGs0IMIBoNaRfte6KZ7BKT44Bx_jjDSBMyFQGvYaycu9gOTHOr wg97SrOcY1_C_f_9FTA660aMGlSQQn68P5J9ruae8xZFiG2iz3fiV1qZEepG FDCHJoLLUawfe_I5O1R_Fft4UybyIamLeU.NKD5.pUahv2FdbABYlRPnTqjC urCua5.3xtDw1a3gkUGPjAi7MlQN_q0uQ09YzQCDJ4Vq1UIzXsbEpgJbXjr0 Ej1Ec0md9WPS2aJ4RCm3ZoJebgRHieW4TnvTRnJa6SfRftJu7.wQOaDlDi7a 6WByaWOlc32nJAFUMw8df9qTB2DGtR.mdLhs90y._JxX5LDNsBGQIHmVht21 mmsRd8oYoS3kN7in9t_22Qy_XleDr Received: from [174.48.128.27] by web121606.mail.ne1.yahoo.com via HTTP; Fri, 18 Jan 2013 06:50:03 PST X-Rocket-MIMEInfo: 001.001, DQo.IHRoZSBwcm9ibGVtIGkgd2FzIGFjdHVhbGx5IHNlZWluZyBhcmUgc2xpZ2h0bHkgZGlmZmVyZW50LA0KPiBuYW1lbHk6DQo.IC0gb25jZSB0aGUgZHJpdmVyIGxhZ3MgYmVoaW5kLCBpdCBkb2VzIG5vdCBoYXZlIGEgY2hhbmNlIHRvDQo.IHJlY292ZXINCj4gwqAgZXZlbiBpZiB0aGVyZSBhcmUgQ1BVIGN5Y2xlcyBhdmFpbGFibGUsIGJlY2F1c2UgYm90aA0KPiBpbnRlcnJ1cHQgDQo.IMKgIHJhdGUgYW5kIHBhY2tldHMgcGVyIGludGVycnVwdCBhcmUgY2FwcGVkLg0KPiAtIG11Y2ggd29yc2UsIG9uY2UBMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.130.494 Message-ID: <1358520603.55904.YahooMailClassic@web121606.mail.ne1.yahoo.com> Date: Fri, 18 Jan 2013 06:50:03 -0800 (PST) From: Barney Cordoba Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() To: Adrian Chadd , Luigi Rizzo In-Reply-To: <20130117174427.GA65218@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 14:50:11 -0000 > the problem i was actually seeing are slightly different, > namely: > - once the driver lags behind, it does not have a chance to > recover > =A0 even if there are CPU cycles available, because both > interrupt=20 > =A0 rate and packets per interrupt are capped. > - much worse, once the input stream stops, you have a huge > backlog that > =A0 is not drained. And if, say, you try to ping the > machine, > =A0 the incoming packet is behind another 3900 packets, > so the first > =A0 interrupt drains 100 (but not the ping request, so no > response), > =A0 you keep going for a while, eventually the external > world sees the > =A0 machine as not responding and stops even trying to > talk to it. This is a silly example. As I said before, the 100 work limit is=20 arbitrary and too low for a busy network. If you have a backlog of 3900 packets with a workload of 100, then your system is so incompetently tuned that it's not even worthy of discussion. If you're using workload and task queues because you don't know how to=20 tune moderation the process_limit, that's one discussion. But if you can't process all of the packets in your RX queue in the interrupt window than you either need to tune your machine better or get a faster machine. When you tune the work limit you're making a decision about the trade off b= etween livelock and dropping packets. It's not an arbitrary decision. BC From owner-freebsd-net@FreeBSD.ORG Fri Jan 18 15:00:22 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 302D9C35; Fri, 18 Jan 2013 15:00:22 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id E9583E1E; Fri, 18 Jan 2013 15:00:21 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 98FFC7300A; Fri, 18 Jan 2013 15:59:44 +0100 (CET) Date: Fri, 18 Jan 2013 15:59:44 +0100 From: Luigi Rizzo To: Barney Cordoba Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() Message-ID: <20130118145944.GA68125@onelab2.iet.unipi.it> References: <20130117174427.GA65218@onelab2.iet.unipi.it> <1358520603.55904.YahooMailClassic@web121606.mail.ne1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1358520603.55904.YahooMailClassic@web121606.mail.ne1.yahoo.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, 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, 18 Jan 2013 15:00:22 -0000 On Fri, Jan 18, 2013 at 06:50:03AM -0800, Barney Cordoba wrote: > > > the problem i was actually seeing are slightly different, > > namely: > > - once the driver lags behind, it does not have a chance to > > recover > > ? even if there are CPU cycles available, because both > > interrupt > > ? rate and packets per interrupt are capped. > > - much worse, once the input stream stops, you have a huge > > backlog that > > ? is not drained. And if, say, you try to ping the > > machine, > > ? the incoming packet is behind another 3900 packets, > > so the first > > ? interrupt drains 100 (but not the ping request, so no > > response), > > ? you keep going for a while, eventually the external > > world sees the > > ? machine as not responding and stops even trying to > > talk to it. > > This is a silly example. As I said before, the 100 work limit is > arbitrary and too low for a busy network. If you have a backlog of > 3900 packets with a workload of 100, then your system is so incompetently > tuned that it's not even worthy of discussion. > > If you're using workload and task queues because you don't know how to > tune moderation the process_limit, that's one discussion. But if you can't > process all of the packets in your RX queue in the interrupt window than > you either need to tune your machine better or get a faster machine. > > When you tune the work limit you're making a decision about the trade off between livelock and dropping packets. It's not an arbitrary decision. maybe i am too incompetent to participate to this discussion. what do i know about this stuff, after all! have fun :) luigi From owner-freebsd-net@FreeBSD.ORG Fri Jan 18 15:48:01 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 099EC6A4 for ; Fri, 18 Jan 2013 15:48:01 +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 B0EB916B for ; Fri, 18 Jan 2013 15:48:00 +0000 (UTC) Received: from [98.138.226.177] by nm33.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jan 2013 15:46:05 -0000 Received: from [98.138.226.162] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jan 2013 15:46:05 -0000 Received: from [127.0.0.1] by omp1063.mail.ne1.yahoo.com with NNFMP; 18 Jan 2013 15:46:05 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 153311.10868.bm@omp1063.mail.ne1.yahoo.com Received: (qmail 85747 invoked by uid 60001); 18 Jan 2013 15:46:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1358523965; bh=0JZk4EOfZNMJ8rbxUGkRW1eYlILksAU8lxQ65wWZKZU=; 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=CMg1QLEvt/UWOldDAAfJXZ6y3pH/VFeMQxm0KzaaU5WOV/fgV20mECwopaDcaxciUdeXvF7gdorH79bcKD6hICO1cqid6wLPf66Zy84VX9mQwKXqf/eH/3SSGEs0Y+XmtyyxI85sPDRsAHIjgKBqVzJ4A7TL2XlnHAmHpznPcK4= 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=jf4jxCXaYDR7z8wedxMhBr5ZMN/OL3uHulb0YTZoFEb3wV0GbyXCIYtxby56mjsU8ae4dNNV1/0KhjVHCgS92vp8Rf4LK4ARMc3O/S4abAiGupAIvdLDvN73BNrNCwlNQ8OIz+VCsN0p+miZk3PrePI4kDKmDziBSgY88n8pt9M=; X-YMail-OSG: nD5KSj8VM1nH4Ih7hc4r34C0oT52ysG8WG1fCs8psqJtPOY JRl04KnhFuEugGxfaBbd5tvMpH4l89SBkt1UZs7MwOGm0zbxgrVQDgl9UI02 Xr2QfHrQ9X2k8WMmtuPwrl1RUnyiUdH6BYy1_DvMtrB0HrrbZLAH_4QXVFpe axJ7PWvjcM6AWaSl.WL7aempOe0Vmv14Es87U.83e9UcoZuPLITgdkkNTCI0 ZXkULUgzvGFFp6uDeh8zX1bsJLdPDD1fmoKIfvWQF.N6lINTTWJydz9DiPNI E2NcynG1Oyt3PU32lEKolZRaATJ2Qa7TZ_UwMErnYK7MOCPtFX_jIYgXj_bJ Aa0e7WC4laPhKiLgw03Fk5D5RfdrN0wDqNm4MLeW1C4wf11vCTx9zN0O.Djk MRS6m0NvfDdhs1jcXWc1q2O0e3p4_mrMbkr9_AXn2Kdg_bbcN9o0xuJiLYkJ 8QAOTEPgy.2WnR0VPrRmSIz_Bl3.tgzkNT_7wMM3HjuwqKKqE5YCuVcNumB4 MnoXWmSMwyeqjsSlYQ45qqB6futNF Received: from [174.48.128.27] by web121601.mail.ne1.yahoo.com via HTTP; Fri, 18 Jan 2013 07:46:04 PST X-Rocket-MIMEInfo: 001.001, DQoNCi0tLSBPbiBGcmksIDEvMTgvMTMsIEx1aWdpIFJpenpvIDxyaXp6b0BpZXQudW5pcGkuaXQ.IHdyb3RlOg0KDQo.IEZyb206IEx1aWdpIFJpenpvIDxyaXp6b0BpZXQudW5pcGkuaXQ.DQo.IFN1YmplY3Q6IFJlOiB0d28gcHJvYmxlbXMgaW4gZGV2L2UxMDAwL2lmX2xlbS5jOjpsZW1faGFuZGxlX3J4dHgoKQ0KPiBUbzogIkJhcm5leSBDb3Jkb2JhIiA8YmFybmV5X2NvcmRvYmFAeWFob28uY29tPg0KPiBDYzogIkFkcmlhbiBDaGFkZCIgPGFkcmlhbkBmcmVlYnNkLm9yZz4sIGZyZWVic2QtbmV0QGZyZWUBMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.130.494 Message-ID: <1358523964.72178.YahooMailClassic@web121601.mail.ne1.yahoo.com> Date: Fri, 18 Jan 2013 07:46:04 -0800 (PST) From: Barney Cordoba Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() To: Luigi Rizzo In-Reply-To: <20130118145944.GA68125@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, 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, 18 Jan 2013 15:48:01 -0000 --- On Fri, 1/18/13, Luigi Rizzo wrote: > From: Luigi Rizzo > Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() > To: "Barney Cordoba" > Cc: "Adrian Chadd" , freebsd-net@freebsd.org > Date: Friday, January 18, 2013, 9:59 AM > On Fri, Jan 18, 2013 at 06:50:03AM > -0800, Barney Cordoba wrote: > >=20 > > > the problem i was actually seeing are slightly > different, > > > namely: > > > - once the driver lags behind, it does not have a > chance to > > > recover > > > ? even if there are CPU cycles available, because > both > > > interrupt=20 > > > ? rate and packets per interrupt are capped. > > > - much worse, once the input stream stops, you > have a huge > > > backlog that > > > ? is not drained. And if, say, you try to ping > the > > > machine, > > > ? the incoming packet is behind another 3900 > packets, > > > so the first > > > ? interrupt drains 100 (but not the ping request, > so no > > > response), > > > ? you keep going for a while, eventually the > external > > > world sees the > > > ? machine as not responding and stops even trying > to > > > talk to it. > >=20 > > This is a silly example. As I said before, the 100 work > limit is=20 > > arbitrary and too low for a busy network. If you have a > backlog of > > 3900 packets with a workload of 100, then your system > is so incompetently > > tuned that it's not even worthy of discussion. > >=20 > > If you're using workload and task queues because you > don't know how to=20 > > tune moderation the process_limit, that's one > discussion. But if you can't > >=A0 process all of the packets in your RX queue in > the interrupt window than > >=A0 you either need to tune your machine better or > get a faster machine. > >=20 > > When you tune the work limit you're making a decision > about the trade off between livelock and dropping packets. > It's not an arbitrary decision. >=20 > maybe i am too incompetent to participate to this > discussion. > what do i know about this stuff, after all! Think about how much better you could do if you actually understood how it all worked? BC From owner-freebsd-net@FreeBSD.ORG Fri Jan 18 17:13:15 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 ED58846D; Fri, 18 Jan 2013 17:13:15 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id C574488A; Fri, 18 Jan 2013 17:13:15 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2FE61B986; Fri, 18 Jan 2013 12:13:15 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() Date: Fri, 18 Jan 2013 11:49:42 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <1358519440.88044.YahooMailClassic@web121605.mail.ne1.yahoo.com> In-Reply-To: <1358519440.88044.YahooMailClassic@web121605.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301181149.42277.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 18 Jan 2013 12:13:15 -0500 (EST) Cc: Barney Cordoba , Adrian Chadd , Luigi Rizzo 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, 18 Jan 2013 17:13:16 -0000 On Friday, January 18, 2013 9:30:40 am Barney Cordoba wrote: > > --- On Thu, 1/17/13, Adrian Chadd wrote: > > > From: Adrian Chadd > > Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() > > To: "Barney Cordoba" > > Cc: "Luigi Rizzo" , freebsd-net@freebsd.org > > Date: Thursday, January 17, 2013, 11:48 AM > > There's also the subtle race > > condition in TX and RX handling that > > re-queuing the taskqueue gets around. > > > > Which is: > > > > * The hardware is constantly receiving frames , right until > > you blow > > the FIFO away by filling it up; > > * The RX thread receives a bunch of frames; > > * .. and processes them; > > * .. once it's done processing, the hardware may have read > > some more > > frames in the meantime; > > * .. and the hardware may have generated a mitigated > > interrupt which > > you're ignoring, since you're processing frames; > > * So if your architecture isn't 100% paranoid, you may end > > up having > > to wait for the next interrupt to handle what's currently in > > the > > queue. > > > > Now if things are done correct: > > > > * The hardware generates a mitigated interrupt > > * The mask register has that bit disabled, so you don't end > > up receiving it; > > * You finish your RX queue processing, and there's more > > stuff that's > > appeared in the FIFO (hence why the hardware has generated > > another > > mitigated interrupt); > > * You unmask the interrupt; > > * .. and the hardware immediately sends you the MSI or > > signals an interrupt; > > * .. thus you re-enter the RX processing thread almost(!) > > immediately. > > > > However as the poster(s) have said, the interrupt > > mask/unmask in the > > intel driver(s) may not be 100% correct, so you're going to > > end up > > with situations where interrupts are missed. > > > > The reason why this wasn't a big deal in the deep/distant > > past is > > because we didn't used to have kernel preemption, or > > multiple kernel > > threads running, or an overly aggressive scheduler trying > > to > > parallelise things as much as possible. A lot of > > net80211/ath bugs > > have popped out of the woodwork specifically because of the > > above > > changes to the kernel. They were bugs before, but people > > didn't hit > > them. > > > > I don't see the distinction between the rx thread getting re-scheduled > "immediately" vs introducing another thread. In fact you increase missed > interrupts by this method. The entire point of interrupt moderation is > to tune the intervals where a driver is processed. > > You might as well just not have a work limit and process until your done. > The idea that "gee, I've been taking up too much cpu, I'd better yield" > to just queue a task and continue soon after doesn't make much sense to > me. If there are multiple threads with the same priority then batching the work up into chunks allows the scheduler to round-robin among them. However, when a task requeues itself that doesn't actually work since the taskqueue thread will see the requeued task before it yields the CPU. Alternatively, if you force all the relevant interrupt handlers to use the same thread pool and instead of requeueing a separate task you requeue your handler in the ithread pool then you can get the desired round-robin behavior. (I have changes to the ithread stuff that get us part of the way there in that handlers can reschedule themselves and much of the plumbing is in place for shared thread pools among different interrupts.) -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri Jan 18 17:50:23 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 42314F10; Fri, 18 Jan 2013 17:50:23 +0000 (UTC) (envelope-from bryanv@daemoninthecloset.org) Received: from torment.daemoninthecloset.org (ip-static-94-242-209-234.as5577.net [94.242.209.234]) by mx1.freebsd.org (Postfix) with ESMTP id 09914CB4; Fri, 18 Jan 2013 17:50:22 +0000 (UTC) Received: from sage.daemoninthecloset.org (unknown [70.114.209.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sage.daemoninthecloset.org", Issuer "daemoninthecloset.org" (verified OK)) by torment.daemoninthecloset.org (Postfix) with ESMTPS id 7C40742C08B0; Fri, 18 Jan 2013 18:52:26 +0100 (CET) X-Virus-Scanned: amavisd-new at daemoninthecloset.org Received: from sage.daemoninthecloset.org (sage.daemoninthecloset.org [127.0.1.1]) by sage.daemoninthecloset.org (Postfix) with ESMTP id 74E8F7BDC5; Fri, 18 Jan 2013 11:50:04 -0600 (CST) Date: Fri, 18 Jan 2013 11:50:04 -0600 (CST) From: Bryan Venteicher To: Ivan Voras Message-ID: <276815060.931.1358531404055.JavaMail.root@daemoninthecloset.org> In-Reply-To: Subject: Re: VMware vmxnet2 driver MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.51.1.14] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - GC23 (Mac)/7.2.0_GA_2669) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 17:50:23 -0000 ----- Original Message ----- > From: "Ivan Voras" > To: freebsd-net@freebsd.org > Sent: Friday, January 18, 2013 4:54:12 AM > Subject: Re: VMware vmxnet2 driver > > On 14/01/2013 07:42, Bryan Venteicher wrote: > > > Any testing or performance data is welcome. For bulk TCP transfers, > > if_vic > > will tend to be faster than em (~1/2 a magnitude) due to TSO, but I > > don't > > think that warrants merging into HEAD yet. > > Considering that from your description the current situation is: > > * The driver isn't *worse* than either em or the "official" > VMWare driver (right?) > * There is currently no vmxnet driver at all in HEAD > > ... I don't think including the driver will harm anyone or anything, > but it may make things a bit simpler when configuring VMs. > > It is typically no better than em (*) - but better in certain cases with TSO. The official driver didn't compile on HEAD and I couldn't bring myself to spend the time to fix it. I'll look into it this weekend and do an initial comparison. A vmxnet3 driver would be far more useful to have in the tree. * I'm running ESXi nested in VMware Fusion but I don't think that would explain the discrepancy. From owner-freebsd-net@FreeBSD.ORG Fri Jan 18 19:33:00 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 90A4EEE7; Fri, 18 Jan 2013 19:33:00 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id 690DB1D8; Fri, 18 Jan 2013 19:33:00 +0000 (UTC) Received: by mail-pb0-f44.google.com with SMTP id uo1so2227267pbc.17 for ; Fri, 18 Jan 2013 11:32:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=9ogG0HSyLetx1VYZYs55FuHDQ6yonYy9fpY0ST4OwoM=; b=zbEeACNuqOdCpE5w0wF9zet/ANunxlux9gUHgyF7KaLWJ58511fWeNUnEfc8tnBURv 0RFQm5pXyDQmp5XbZdd+z8nL3aqgZNY1cIKM80WLkl8sCpRCjVBTrvP4N/51gb1lkGfi lhKrKe8l1pFofM+9vzkqQUWwU8uoEzGBv+/DiVpXMfGH9pAUuDojsHjAvYAcQIs64HkJ aXyvHsU7KiCCuJl3Mp/Zi4/W9ZpNW0REgXwYlcUGULaxru7uYiOnCzu4TN01Blwj8wa+ aJHLZedr/PkkV6CHEvfpFWDszhxXvoLXP3eJJkBwXXuCvJrO0lMX4EVoNnoFxzEhtHAR 5Iew== X-Received: by 10.66.79.66 with SMTP id h2mr26557832pax.31.1358537574249; Fri, 18 Jan 2013 11:32:54 -0800 (PST) Received: from [192.168.20.12] (c-24-19-191-56.hsd1.wa.comcast.net. [24.19.191.56]) by mx.google.com with ESMTPS id hs2sm3580875pbc.22.2013.01.18.11.32.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Jan 2013 11:32:53 -0800 (PST) References: <1358518345.3216.4.camel@powernoodle> Mime-Version: 1.0 (1.0) In-Reply-To: <1358518345.3216.4.camel@powernoodle> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <53809813-9C23-4A82-AAA7-A36B21AEAC8C@gmail.com> X-Mailer: iPhone Mail (10A523) From: Garrett Cooper Subject: Re: oce patches for freebsd-9.1 Date: Fri, 18 Jan 2013 11:32:51 -0800 To: "sbruno@freebsd.org" Cc: "freebsd-net@freebsd.org" , Venkat Duvvuru 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, 18 Jan 2013 19:33:00 -0000 On Jan 18, 2013, at 6:12 AM, Sean Bruno wrote: > On Fri, 2013-01-18 at 18:10 +0530, Venkat Duvvuru wrote: >> Hi, >> I have to submit some patches for Emulex's "oce" driver. Could you pleas= e >> let me know if http://www.freebsd.org/send-pr.html is the correct way of >> submitting them? >>=20 >> /Venkat >=20 >=20 > Yes please. That would be the first place so that they are saved! >=20 > If you can, please set the assign-to to "freebsd-net" and that way the > patch will show up on the mailing list. The assign-to part is handled by one of edwin's scripts or the bugbusters te= am. Just be sure to add "[oce]" in the title so it's easier to categorize. Cheers, -Garrett= From owner-freebsd-net@FreeBSD.ORG Fri Jan 18 20:07: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 A8B61954; Fri, 18 Jan 2013 20:07:43 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by mx1.freebsd.org (Postfix) with ESMTP id 21976322; Fri, 18 Jan 2013 20:07:42 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id dr13so2370425wgb.13 for ; Fri, 18 Jan 2013 12:07:35 -0800 (PST) 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=2sjUbGAgrB50oE0l2dMEJHPHNzOr++/nA/Ft88wMWIo=; b=cK90R2n55XyM6Ux9W45TphBFRIAS+q/J4UP6P7C4ufkT/qGOp02XBnbM9Ddvx5iKwU Ro5W1Em3Fqg24Swsx0iSY6trX4It4AzSNv0XGghQztxsoFC2ByXQQVP8e6JYlnE7ZYS8 fXm8iYD4Zsi49yDdINQ8ayNVFm7cIYtiQLn0EFkFpp5pHY6IeuY6ZuLNjLh82K7JzPM7 u93AqRYN9bVRz6y1S5stMb6v+DxNljCMBW23dU1xOCWj4Hbjn8nONpcCuHFNKsH1QiOW wrGRwkuv1D2MSNlHyuucHCceSJNqsyWn2HJU84dawI0PSM/coTSx/gmnkw/4Bw+0Xwxb xZng== MIME-Version: 1.0 X-Received: by 10.180.72.146 with SMTP id d18mr5424545wiv.33.1358539655757; Fri, 18 Jan 2013 12:07:35 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Fri, 18 Jan 2013 12:07:35 -0800 (PST) In-Reply-To: <201301181149.42277.jhb@freebsd.org> References: <1358519440.88044.YahooMailClassic@web121605.mail.ne1.yahoo.com> <201301181149.42277.jhb@freebsd.org> Date: Fri, 18 Jan 2013 12:07:35 -0800 X-Google-Sender-Auth: uXPOTbLB-jQ7r1T39p32fRKvnMU Message-ID: Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Luigi Rizzo , Barney Cordoba 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, 18 Jan 2013 20:07:43 -0000 For my purposes, rescheduling the taskqueue means that other things (such as TX, reset processing, other state handling, etc) can run before the next pass at RX completion. Also, IIRC, acquiring mutexes are one of those magic points where the scheduler may decide to switch things around in a preemption kernel. Adrian From owner-freebsd-net@FreeBSD.ORG Fri Jan 18 20:17:23 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 5B70FD64 for ; Fri, 18 Jan 2013 20:17:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id DB82739C for ; Fri, 18 Jan 2013 20:17:22 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id es5so2475831wgb.29 for ; Fri, 18 Jan 2013 12:17:21 -0800 (PST) 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=awUij9MKbD8uKVEVwUIpab/glxdmEDHK3viI7EyPfEE=; b=FERdcytQLRXULX0utqCQWEEvOAguBU5ZE/HetBtYDxphb75Q29lzuA99gdfKIa9azJ m8Eb3m9X1ljiy6iFHMK+V33MMP3XQ4+844mLCkIDZLWeciaZ0e66jLA8eRMY+zUN5yf3 v1kLTLXEtycBdJgvEcjELr2Cel7ygJnNgPeIpQXpqiDGPQ5XqfxWZdXQ9BriptBMg8dg zgSDMJXNmX0u2JDLbNFMdk/fZaUB68zNp73mHxJQ8HtuTbZrzL7kTH9n1zlx9eIlseYR p9U3v4+/iNKSURh83u79fWOGmF1u2xxKHedtvkAnjwcfEXNjQbqOlCd675aNsOm0UhUV hmMA== MIME-Version: 1.0 X-Received: by 10.194.109.10 with SMTP id ho10mr16288364wjb.16.1358539761819; Fri, 18 Jan 2013 12:09:21 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Fri, 18 Jan 2013 12:09:21 -0800 (PST) In-Reply-To: <1358519416.46817.YahooMailClassic@web121606.mail.ne1.yahoo.com> References: <1358519416.46817.YahooMailClassic@web121606.mail.ne1.yahoo.com> Date: Fri, 18 Jan 2013 12:09:21 -0800 X-Google-Sender-Auth: p7h-8MAZ7Y0yLGm5FPHfFrAHW0g Message-ID: Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() From: Adrian Chadd To: Barney Cordoba Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Luigi Rizzo 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, 18 Jan 2013 20:17:23 -0000 On 18 January 2013 06:30, Barney Cordoba wrote: > I don't see the distinction between the rx thread getting re-scheduled > "immediately" vs introducing another thread. In fact you increase missed > interrupts by this method. The entire point of interrupt moderation is > to tune the intervals where a driver is processed. The problem with interrupt moderation combined with enabling/disabling interrupts is that if you get it even slightly wrong, you won't run the packet processing thread(s) until the next interrupt occurs - even if something is in the queue. There's been a class of bugs in the em driver that resemble this. Same as what I found in ath(4) - even the TX watchdog code is broken like this :( Adrian From owner-freebsd-net@FreeBSD.ORG Fri Jan 18 21:16:29 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 892144A7; Fri, 18 Jan 2013 21:16:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4749185D; Fri, 18 Jan 2013 21:16:29 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5A8A0B94C; Fri, 18 Jan 2013 16:16:28 -0500 (EST) From: John Baldwin To: Adrian Chadd Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() Date: Fri, 18 Jan 2013 16:03:32 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <1358519440.88044.YahooMailClassic@web121605.mail.ne1.yahoo.com> <201301181149.42277.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301181603.32393.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 18 Jan 2013 16:16:28 -0500 (EST) Cc: freebsd-net@freebsd.org, Luigi Rizzo , Barney Cordoba 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, 18 Jan 2013 21:16:29 -0000 On Friday, January 18, 2013 3:07:35 pm Adrian Chadd wrote: > For my purposes, rescheduling the taskqueue means that other things > (such as TX, reset processing, other state handling, etc) can run > before the next pass at RX completion. That only works if your taskqueue thread has a priority <= those things. I think the e1000 drivers use the same priority for their taskqueue threads as the ithreads use, so the effectively preempt just about everything and are not preempted by other task queues or swi threads, etc. > Also, IIRC, acquiring mutexes are one of those magic points where the > scheduler may decide to switch things around in a preemption kernel. No, releasing mutexes (and any other place that makes a non-runnable thread runnable), and only if it wakes up a thread with a more important priority. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri Jan 18 21:21:26 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1B05974C; Fri, 18 Jan 2013 21:21:26 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by mx1.freebsd.org (Postfix) with ESMTP id 147CA8A0; Fri, 18 Jan 2013 21:21:24 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id gm6so889890lbb.36 for ; Fri, 18 Jan 2013 13:21:18 -0800 (PST) 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=wC1sNtxEkV/mTpQ9JMJxZS7u0q9pP0ts5aS11exGmRQ=; b=K1nSaygyo5mowNRoThTikbGv/DzmICxoOkBNAIER66JW9QPlMmtp5hVDaD5t9gY4en aJJJH5pdI8GEiV7cTW1io1g2i6Sr1gM3nq52S4ZXffm5kwEO/1ljA5UvWyZhgAqJQfct /JrogzmHEVqb8OuI8NfPo+kM9W99ZE1udXuY9JM2vnopPVlLaORJvMafAFErxAg9Mt6c +tp3jwrtuWA4e/F5dGdN75bip7pNqBC63Kc5NILa58ZAjZS0KZypnUhgix121koMa75N 6i7oaACZVadazOHE4ORv9fE76rWGTGdYKhaMSACTMRkS1nu6IY3G62RTbzD7tCsw2/ib MMiw== MIME-Version: 1.0 X-Received: by 10.152.123.34 with SMTP id lx2mr8678262lab.52.1358544078016; Fri, 18 Jan 2013 13:21:18 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.93.200 with HTTP; Fri, 18 Jan 2013 13:21:17 -0800 (PST) In-Reply-To: <201301181603.32393.jhb@freebsd.org> References: <1358519440.88044.YahooMailClassic@web121605.mail.ne1.yahoo.com> <201301181149.42277.jhb@freebsd.org> <201301181603.32393.jhb@freebsd.org> Date: Fri, 18 Jan 2013 13:21:17 -0800 X-Google-Sender-Auth: jER97L-0kMHROLCukMsQi3_Y6dg Message-ID: Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() From: Luigi Rizzo To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" , 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, 18 Jan 2013 21:21:26 -0000 On Fri, Jan 18, 2013 at 1:03 PM, John Baldwin wrote: > On Friday, January 18, 2013 3:07:35 pm Adrian Chadd wrote: > > For my purposes, rescheduling the taskqueue means that other things > > (such as TX, reset processing, other state handling, etc) can run > > before the next pass at RX completion. > > That only works if your taskqueue thread has a priority <= those things. I > think the e1000 drivers use the same priority for their taskqueue threads > as > the ithreads use, so the effectively preempt just about everything and are > not > preempted by other task queues or swi threads, etc. > > ok this also explains why i see livelock. I hate priorities! luigi From owner-freebsd-net@FreeBSD.ORG Sat Jan 19 14:19:45 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5BA4C995 for ; Sat, 19 Jan 2013 14:19:45 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm19-vm0.bullet.mail.ne1.yahoo.com (nm19-vm0.bullet.mail.ne1.yahoo.com [98.138.91.59]) by mx1.freebsd.org (Postfix) with ESMTP id DD489DCF for ; Sat, 19 Jan 2013 14:19:44 +0000 (UTC) Received: from [98.138.90.57] by nm19.bullet.mail.ne1.yahoo.com with NNFMP; 19 Jan 2013 14:17:45 -0000 Received: from [98.138.88.238] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 19 Jan 2013 14:17:45 -0000 Received: from [127.0.0.1] by omp1038.mail.ne1.yahoo.com with NNFMP; 19 Jan 2013 14:17:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 932085.74043.bm@omp1038.mail.ne1.yahoo.com Received: (qmail 61296 invoked by uid 60001); 19 Jan 2013 14:17:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1358605065; bh=ANS+Z4Gx/scgL9OgW2IJM3ERYIHfafNUhrf2/2F+qBU=; 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=kdqNvJk3K/CI+5psdYyQyqBCRXotqaFpC0wy7qOXyN53pVHM+hEIgZlJNorAAGU2+LE5qZxai18sBgyc1OA+rpLAPjJRgkAz9CPa/Boh8bTO/5M6I+jg30T0MgclkusvqK8+Ra25UZgU8yY9SRF7Us06sNQ5/U2jEZjxaw+Fu7g= 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=n7Ao8scAHB446i2nVbrVUT9eBfnOVmG0z69fZK1bT1oihmpK/51m1in8UZNCYUYnwDIyhytpMi9bEsX/902sZGi/ja/k23jp8od9PVRHqyZywORxKBszdomQJxDru0WbseaLmLFGyDmleFLreCaRV9xG+jJ9+aDmbDTAOHx/zXM=; X-YMail-OSG: j2OVnJ4VM1kPB_tugAR94AETFkpkX2YLVviUeSQNDLIt6kx ztqVQUxgX0v0cffHWbOeZ8COw6moyHZmESUQI5_RiG3kHsRxEkiB_EKQGW6Q hvZ1OHN0ojkJuT1lBsA_V8vhWh1IdbVGA_NACJOGVexGbSWYn3zIxuH3eCJN tS1HrekDlBhyk07mQacLvYpi9YTyDs8ZoeiFlUJ7YeMCDdCf0bYTqGbyfu1W 1B0ktsn59G_eTtXypTT8Niv1o07f0L1XKTbf0Ca8Qt69j7ZOG.XAn7owTydT 9mxWwddzaxkbZPYce7RJR8Y_nw4P0rm_R.ZQ37y4lRIkJu1QyxsgioMzOAEr 6uvM8OqW3x5h0v7OR.RMaEus80asKZXVXSbegjcObwmtlT2Mv93.Kb8iT7Vw O4vkjiQ6x2L7YERUr7w7SCLQkQdqQXGZyKR7LVbsbzjcsE.mVm0W1NF4nRQk TRowSzjdyJHHGrb2hfhAdkEtYhR7tf.mTDymkixA3iOtyExxu1s7rawIv_ta FhnYF2mMyuGzonXg6DKHPkacNrMTi Received: from [174.48.128.27] by web121604.mail.ne1.yahoo.com via HTTP; Sat, 19 Jan 2013 06:17:45 PST X-Rocket-MIMEInfo: 001.001, CgotLS0gT24gRnJpLCAxLzE4LzEzLCBBZHJpYW4gQ2hhZGQgPGFkcmlhbkBmcmVlYnNkLm9yZz4gd3JvdGU6Cgo.IEZyb206IEFkcmlhbiBDaGFkZCA8YWRyaWFuQGZyZWVic2Qub3JnPgo.IFN1YmplY3Q6IFJlOiB0d28gcHJvYmxlbXMgaW4gZGV2L2UxMDAwL2lmX2xlbS5jOjpsZW1faGFuZGxlX3J4dHgoKQo.IFRvOiAiQmFybmV5IENvcmRvYmEiIDxiYXJuZXlfY29yZG9iYUB5YWhvby5jb20.Cj4gQ2M6IGZyZWVic2QtbmV0QGZyZWVic2Qub3JnLCAiTHVpZ2kgUml6em8iIDxyaXp6b0BpZXQudW5pcGkuaXQBMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.130.494 Message-ID: <1358605065.60481.YahooMailClassic@web121604.mail.ne1.yahoo.com> Date: Sat, 19 Jan 2013 06:17:45 -0800 (PST) From: Barney Cordoba Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() To: Adrian Chadd In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-net@freebsd.org, Luigi Rizzo 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, 19 Jan 2013 14:19:45 -0000 --- On Fri, 1/18/13, Adrian Chadd wrote: > From: Adrian Chadd > Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() > To: "Barney Cordoba" > Cc: freebsd-net@freebsd.org, "Luigi Rizzo" > Date: Friday, January 18, 2013, 3:09 PM > On 18 January 2013 06:30, Barney > Cordoba > wrote: > > > I don't see the distinction between the rx thread > getting re-scheduled > > "immediately" vs introducing another thread. In fact > you increase missed > > interrupts by this method. The entire point of > interrupt moderation is > > to tune the intervals where a driver is processed. > > The problem with interrupt moderation combined with > enabling/disabling > interrupts is that if you get it even slightly wrong, > you won't run the packet processing thread(s) until the next > interrupt > occurs - even if something is in the queue. Which is the point of interrupt moderation. Your argument is that "I only want 6000 interrupts per second, but I'm willing to launch N tasks that have the exact same processing load where N <= 20". So you're willing to have 120000 interrupts/task_queues per second (its only possible to get about 2000pps in 1/6000th of a second on a gigabit link unless you're fielding runts). This all comes down, again, to tuning. Luigi's example would result in 39 tasks being queued to process his 3900 backup with a process limit of 100. This would bypass the "next interrupt" by a wide margin. Is the point of moderation to not have the network task take over your system? If you don't care, then why not just set moderation to 20Kpps? The "work" should be the amount of time you're willing to process packets within the interrupt moderation window. The settings go hand in hand. I'm not saying that the task_queue idea is wrong; however in Luigi's example it will cause substantially more overhead by launching too many tasks. Unless you're still running a 700Mhz P3 100 is way too low for a workload limit. It's just arbitrarily silly. BC From owner-freebsd-net@FreeBSD.ORG Sat Jan 19 15:49:30 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 BC00AD8C for ; Sat, 19 Jan 2013 15:49:30 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm14-vm1.bullet.mail.ne1.yahoo.com (nm14-vm1.bullet.mail.ne1.yahoo.com [98.138.91.38]) by mx1.freebsd.org (Postfix) with ESMTP id 5A61818F for ; Sat, 19 Jan 2013 15:49:30 +0000 (UTC) Received: from [98.138.226.180] by nm14.bullet.mail.ne1.yahoo.com with NNFMP; 19 Jan 2013 15:47:32 -0000 Received: from [98.138.89.252] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 19 Jan 2013 15:47:31 -0000 Received: from [127.0.0.1] by omp1044.mail.ne1.yahoo.com with NNFMP; 19 Jan 2013 15:47:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 898773.18503.bm@omp1044.mail.ne1.yahoo.com Received: (qmail 77235 invoked by uid 60001); 19 Jan 2013 15:47:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1358610451; bh=GrYf6rngHl5NjMVEGaHxyw3tBr2QqbjGIVyHFSJVEM4=; 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=sYFfHDQdhAfkxi32c13SoqES12liZweqIB7kFVgxSuUFUjyxHoqv6OTFGS/0SZaYZP7VGfWDbRJbsrmFN+eISFEgOjdlS99XxlWY3G0DjGcS0IAjrpfYBFrvY11H5QrYybzFbU6UU5kAqPHdkhaXWvW4ojbAKnK/p19sJgj9yLY= 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=u5Ua//7/lUR0sdxFHhxn1TC1Pk1vRPQl5Plhgp6Ytec2AXP0w5Mo4zcS7KWhxPXYr7l302crY4HOezzoozOZn9I4+SLTo3jnHQYWgZerzLWvZJHwUGbUMthF0mqob3Itiuzg3eSnhvep5AJVN/63XiC1MZsVSEO6i8azY+TUoc8=; X-YMail-OSG: LSH_C8MVM1kHrjvKOA1vwwK9WIHpu8Z9WTAkBJYjPmv7hWf 5SFPVXY9WpNanC3pBVqecbd1IXraDBjR04AWT9Ke44FXXzK5oE85JWjCwwpP NDiR3HrI11J0CZkumFvn1_KS8Et1oZWk3eK7SE8faBDWMC6a.MH9vv1GfkJg e_NljK1c1c62tw8B3QME5voFwlamHckAn82fRvpgjbLH.RFbs6D.BHysMgLS AoNHqASARqI6PUWcFd0mULWHO6bRtprq60sDsWh0mX_aHIFQ.bujuTf.uVDt 4Jyujc2PrmabpkQPt0_i3_7NvUCXpCp_yhT5LKGPsCgEVnbGCWYizZFEDMaL q7FwWVXa1Kawpw85OTDf8Qt4GKrIYbTvxXLSZgWI_HT4njMlMPGaS2hdbhtF UIavX15fkVfK6b7jxt7F6.LhfIUnmdHwANiZPaGhykgqVpy.egpLWzkcNTQV By7kbzVcfqsHWmimEk2IXqRwcnwmkqE_WTv_8PG0a0e4qcZQqo2eppCxRfFK lS7Dewpbcty0OgOYgpBKakmhpbf1b Received: from [174.48.128.27] by web121604.mail.ne1.yahoo.com via HTTP; Sat, 19 Jan 2013 07:47:30 PST X-Rocket-MIMEInfo: 001.001, CgotLS0gT24gRnJpLCAxLzE4LzEzLCBKb2huIEJhbGR3aW4gPGpoYkBmcmVlYnNkLm9yZz4gd3JvdGU6Cgo.IEZyb206IEpvaG4gQmFsZHdpbiA8amhiQGZyZWVic2Qub3JnPgo.IFN1YmplY3Q6IFJlOiB0d28gcHJvYmxlbXMgaW4gZGV2L2UxMDAwL2lmX2xlbS5jOjpsZW1faGFuZGxlX3J4dHgoKQo.IFRvOiBmcmVlYnNkLW5ldEBmcmVlYnNkLm9yZwo.IENjOiAiQmFybmV5IENvcmRvYmEiIDxiYXJuZXlfY29yZG9iYUB5YWhvby5jb20.LCAiQWRyaWFuIENoYWRkIiA8YWRyaWFuQGZyZWVic2Qub3JnPiwgIkwBMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.130.494 Message-ID: <1358610450.75691.YahooMailClassic@web121604.mail.ne1.yahoo.com> Date: Sat, 19 Jan 2013 07:47:30 -0800 (PST) From: Barney Cordoba Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() To: freebsd-net@freebsd.org, John Baldwin In-Reply-To: <201301181149.42277.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Adrian Chadd , Luigi Rizzo 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, 19 Jan 2013 15:49:30 -0000 =0A=0A--- On Fri, 1/18/13, John Baldwin wrote:=0A=0A> Fro= m: John Baldwin =0A> Subject: Re: two problems in dev/e100= 0/if_lem.c::lem_handle_rxtx()=0A> To: freebsd-net@freebsd.org=0A> Cc: "Barn= ey Cordoba" , "Adrian Chadd" = , "Luigi Rizzo" =0A> Date: Friday, January 18, 2013, 11= :49 AM=0A> On Friday, January 18, 2013 9:30:40=0A> am Barney Cordoba wrote:= =0A> > =0A> > --- On Thu, 1/17/13, Adrian Chadd =0A> wr= ote:=0A> > =0A> > > From: Adrian Chadd =0A> > > Subject= : Re: two problems in=0A> dev/e1000/if_lem.c::lem_handle_rxtx()=0A> > > To:= "Barney Cordoba" =0A> > > Cc: "Luigi Rizzo" ,=0A> freebsd-net@freebsd.org=0A> > > Date: Thursday, Janua= ry 17, 2013, 11:48 AM=0A> > > There's also the subtle race=0A> > > conditio= n in TX and RX handling that=0A> > > re-queuing the taskqueue gets around.= =0A> > > =0A> > > Which is:=0A> > > =0A> > > * The hardware is constantly r= eceiving frames ,=0A> right until=0A> > > you blow=0A> > > the FIFO away by= filling it up;=0A> > > * The RX thread receives a bunch of frames;=0A> > >= * .. and processes them;=0A> > > * .. once it's done processing, the hardw= are may=0A> have read=0A> > > some more=0A> > > frames in the meantime;=0A>= > > * .. and the hardware may have generated a=0A> mitigated=0A> > > inter= rupt which=0A> > > you're ignoring, since you're processing frames;=0A> > >= * So if your architecture isn't 100% paranoid, you=0A> may end=0A> > > up = having=0A> > > to wait for the next interrupt to handle what's=0A> currentl= y in=0A> > > the=0A> > > queue.=0A> > > =0A> > > Now if things are done cor= rect:=0A> > > =0A> > > * The hardware generates a mitigated interrupt=0A> >= > * The mask register has that bit disabled, so you=0A> don't end=0A> > > = up receiving it;=0A> > > * You finish your RX queue processing, and there's= =0A> more=0A> > > stuff that's=0A> > > appeared in the FIFO (hence why the = hardware has=0A> generated=0A> > > another=0A> > > mitigated interrupt);=0A= > > > * You unmask the interrupt;=0A> > > * .. and the hardware immediately= sends you the=0A> MSI or=0A> > > signals an interrupt;=0A> > > * .. thus y= ou re-enter the RX processing thread=0A> almost(!)=0A> > > immediately.=0A>= > > =0A> > > However as the poster(s) have said, the interrupt=0A> > > mas= k/unmask in the=0A> > > intel driver(s) may not be 100% correct, so you're= =0A> going to=0A> > > end up=0A> > > with situations where interrupts are m= issed.=0A> > > =0A> > > The reason why this wasn't a big deal in the=0A> de= ep/distant=0A> > > past is=0A> > > because we didn't used to have kernel pr= eemption,=0A> or=0A> > > multiple kernel=0A> > > threads running, or an ove= rly aggressive scheduler=0A> trying=0A> > > to=0A> > > parallelise things a= s much as possible. A lot of=0A> > > net80211/ath bugs=0A> > > have popped = out of the woodwork specifically=0A> because of the=0A> > > above=0A> > > c= hanges to the kernel. They were bugs before, but=0A> people=0A> > > didn't = hit=0A> > > them.=0A> > > =0A> > =0A> > I don't see the distinction between= the rx thread=0A> getting re-scheduled=0A> > "immediately" vs introducing = another thread. In fact=0A> you increase missed=0A> > interrupts by this me= thod. The entire point of=0A> interrupt moderation is=0A> > to tune the int= ervals where a driver is processed.=0A> > =0A> > You might as well just not= have a work limit and=0A> process until your done.=0A> > The idea that "ge= e, I've been taking up too much cpu,=0A> I'd better yield"=0A> > to just qu= eue a task and continue soon after doesn't=0A> make much sense to =0A> > me= .=0A> =0A> If there are multiple threads with the same priority then=0A> ba= tching the work up =0A> into chunks allows the scheduler to round-robin amo= ng=0A> them.=A0 However, when a =0A> task requeues itself that doesn't actu= ally work since the=0A> taskqueue thread =0A> will see the requeued task be= fore it yields the CPU.=A0=0A> Alternatively, if you =0A> force all the rel= evant interrupt handlers to use the same=0A> thread pool and =0A> instead o= f requeueing a separate task you requeue your=0A> handler in the ithread = =0A> pool then you can get the desired round-robin=0A> behavior.=A0 (I have= changes to =0A> the ithread stuff that get us part of the way there in tha= t=0A> handlers can =0A> reschedule themselves and much of the plumbing is i= n place=0A> for shared thread =0A> pools among different interrupts.)=0A=0A= I dont see any "round robin" effect here. You have:=0A=0ARepeat:=0A- Proces= s 100 frames=0Aif (more)=0A- Queue a Task=0A=0Athere's only 1 task at a tim= e. All its really doing is yielding and=0Arescheduling itself to resume the= loop.=0A=0ABC From owner-freebsd-net@FreeBSD.ORG Sat Jan 19 16:16:59 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 704C61A8; Sat, 19 Jan 2013 16:16:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 36311262; Sat, 19 Jan 2013 16:16:59 +0000 (UTC) Received: from ralph.baldwin.cx (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6E994B918; Sat, 19 Jan 2013 11:16:58 -0500 (EST) From: John Baldwin To: Barney Cordoba Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() Date: Sat, 19 Jan 2013 11:14:29 -0500 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <1358610450.75691.YahooMailClassic@web121604.mail.ne1.yahoo.com> In-Reply-To: <1358610450.75691.YahooMailClassic@web121604.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301191114.29959.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Sat, 19 Jan 2013 11:16:58 -0500 (EST) Cc: freebsd-net@freebsd.org, Adrian Chadd , Luigi Rizzo 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, 19 Jan 2013 16:16:59 -0000 On Saturday, January 19, 2013 10:47:30 AM Barney Cordoba wrote: > --- On Fri, 1/18/13, John Baldwin wrote: > > From: John Baldwin > > Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() > > To: freebsd-net@freebsd.org > > Cc: "Barney Cordoba" , "Adrian Chadd" > > , "Luigi Rizzo" Date: Friday, > > January 18, 2013, 11:49 AM > > On Friday, January 18, 2013 9:30:40 > > > > am Barney Cordoba wrote: > > > --- On Thu, 1/17/13, Adrian Chadd > > > > wrote: > > > > From: Adrian Chadd > > > > Subject: Re: two problems in > > > > dev/e1000/if_lem.c::lem_handle_rxtx() > > > > > > To: "Barney Cordoba" > > > > Cc: "Luigi Rizzo" , > > > > freebsd-net@freebsd.org > > > > > > Date: Thursday, January 17, 2013, 11:48 AM > > > > There's also the subtle race > > > > condition in TX and RX handling that > > > > re-queuing the taskqueue gets around. > > > > > > > > Which is: > > > > > > > > * The hardware is constantly receiving frames , > > > > right until > > > > > > you blow > > > > the FIFO away by filling it up; > > > > * The RX thread receives a bunch of frames; > > > > * .. and processes them; > > > > * .. once it's done processing, the hardware may > > > > have read > > > > > > some more > > > > frames in the meantime; > > > > * .. and the hardware may have generated a > > > > mitigated > > > > > > interrupt which > > > > you're ignoring, since you're processing frames; > > > > * So if your architecture isn't 100% paranoid, you > > > > may end > > > > > > up having > > > > to wait for the next interrupt to handle what's > > > > currently in > > > > > > the > > > > queue. > > > > > > > > Now if things are done correct: > > > > > > > > * The hardware generates a mitigated interrupt > > > > * The mask register has that bit disabled, so you > > > > don't end > > > > > > up receiving it; > > > > * You finish your RX queue processing, and there's > > > > more > > > > > > stuff that's > > > > appeared in the FIFO (hence why the hardware has > > > > generated > > > > > > another > > > > mitigated interrupt); > > > > * You unmask the interrupt; > > > > * .. and the hardware immediately sends you the > > > > MSI or > > > > > > signals an interrupt; > > > > * .. thus you re-enter the RX processing thread > > > > almost(!) > > > > > > immediately. > > > > > > > > However as the poster(s) have said, the interrupt > > > > mask/unmask in the > > > > intel driver(s) may not be 100% correct, so you're > > > > going to > > > > > > end up > > > > with situations where interrupts are missed. > > > > > > > > The reason why this wasn't a big deal in the > > > > deep/distant > > > > > > past is > > > > because we didn't used to have kernel preemption, > > > > or > > > > > > multiple kernel > > > > threads running, or an overly aggressive scheduler > > > > trying > > > > > > to > > > > parallelise things as much as possible. A lot of > > > > net80211/ath bugs > > > > have popped out of the woodwork specifically > > > > because of the > > > > > > above > > > > changes to the kernel. They were bugs before, but > > > > people > > > > > > didn't hit > > > > them. > > > > > > I don't see the distinction between the rx thread > > > > getting re-scheduled > > > > > "immediately" vs introducing another thread. In fact > > > > you increase missed > > > > > interrupts by this method. The entire point of > > > > interrupt moderation is > > > > > to tune the intervals where a driver is processed. > > > > > > You might as well just not have a work limit and > > > > process until your done. > > > > > The idea that "gee, I've been taking up too much cpu, > > > > I'd better yield" > > > > > to just queue a task and continue soon after doesn't > > > > make much sense to > > > > > me. > > > > If there are multiple threads with the same priority then > > batching the work up > > into chunks allows the scheduler to round-robin among > > them. However, when a > > task requeues itself that doesn't actually work since the > > taskqueue thread > > will see the requeued task before it yields the CPU. > > Alternatively, if you > > force all the relevant interrupt handlers to use the same > > thread pool and > > instead of requeueing a separate task you requeue your > > handler in the ithread > > pool then you can get the desired round-robin > > behavior. (I have changes to > > the ithread stuff that get us part of the way there in that > > handlers can > > reschedule themselves and much of the plumbing is in place > > for shared thread > > pools among different interrupts.) > > I dont see any "round robin" effect here. You have: > > Repeat: > - Process 100 frames > if (more) > - Queue a Task > > there's only 1 task at a time. All its really doing is yielding and > rescheduling itself to resume the loop. As I said above, in the current e1000 drivers using private taskqueues where the taskqueue thread priority is the same as the ithread priority, the round- robin doesn't really work because the taskqueue thread doesn't yield when the task is rescheduled since it will see the new task and go run it instead of yielding. However, I did describe an alternate setup where you can fix this. Part of the key is to get various NICs to share a single logical queue of tasks. You could simulate this now by having all the deferred tasks share a single taskqueue with a pool of tasks, but that will still not fully cooperate with ithreads. To do that you have to get the interrupt handlers themselves into the shared taskqueue. Some changes I have in a p4 branch allow you to do that by letting interrupt handlers reschedule themselves (avoiding the need for a separate task and preventing the task from running concurrently with the interrupt handler) and providing some (but not yet all) of the framework to allow multiple devices to share a single work queue backed by a shared pool of threads. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Sat Jan 19 16:26:17 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 ABF0D614; Sat, 19 Jan 2013 16:26:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 745D02AD; Sat, 19 Jan 2013 16:26:17 +0000 (UTC) Received: from ralph.baldwin.cx (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D1A8CB918; Sat, 19 Jan 2013 11:26:16 -0500 (EST) From: John Baldwin To: emulation@freebsd.org Subject: [PATCH] Properly handle Linux TCP socket options Date: Sat, 19 Jan 2013 11:26:13 -0500 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201301191126.13257.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Sat, 19 Jan 2013 11:26:16 -0500 (EST) Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 16:26:17 -0000 The current setsockopt() wrapper for the Linux ABI claims that Linux and FreeBSD use the same values for TCP socket options. This is true for TCP_NODELAY and TCP_MAXSEG but not for any other options. This patch adds a mapping routine for TCP options similar to that used for other socket option levels. I believe this mapping to be correct in terms of which FreeBSD options have the same semantics as Linux options based on comparing code in the two kernels, but I'm not 100% certain about TCP_MD5SIG since the Linux code that it maps to is not as clear (it calls some function pointer and it is not clear if it is accepting a simple boolean value similar to FreeBSD's). Also, almost all of the socket stuff in the linux.h headers appears to be identical and at least some of it are in MI headers in Linux (such as the TCP options). It seems to me that a lot of that should move into linux_socket.h instead. Index: amd64/linux32/linux.h =================================================================== --- amd64/linux32/linux.h (revision 245225) +++ amd64/linux32/linux.h (working copy) @@ -725,6 +725,13 @@ #define LINUX_IP_ADD_MEMBERSHIP 35 #define LINUX_IP_DROP_MEMBERSHIP 36 +#define LINUX_TCP_NODELAY 1 +#define LINUX_TCP_MAXSEG 2 +#define LINUX_TCP_KEEPIDLE 4 +#define LINUX_TCP_KEEPINTVL 5 +#define LINUX_TCP_KEEPCNT 6 +#define LINUX_TCP_MD5SIG 14 + struct l_sockaddr { l_ushort sa_family; char sa_data[14]; Index: compat/linux/linux_socket.c =================================================================== --- compat/linux/linux_socket.c (revision 245225) +++ compat/linux/linux_socket.c (working copy) @@ -56,6 +56,7 @@ #include #include #include +#include #ifdef INET6 #include #include @@ -326,6 +327,27 @@ } static int +linux_to_bsd_tcp_sockopt(int opt) +{ + + switch (opt) { + case LINUX_TCP_NODELAY: + return (TCP_NODELAY); + case LINUX_TCP_MAXSEG: + return (TCP_MAXSEG); + case LINUX_TCP_KEEPIDLE: + return (TCP_KEEPIDLE); + case LINUX_TCP_KEEPINTVL: + return (TCP_KEEPINTVL); + case LINUX_TCP_KEEPCNT: + return (TCP_KEEPCNT); + case LINUX_TCP_MD5SIG: + return (TCP_MD5SIG); + } + return (-1); +} + +static int linux_to_bsd_msg_flags(int flags) { int ret_flags = 0; @@ -1496,8 +1518,7 @@ name = linux_to_bsd_ip_sockopt(args->optname); break; case IPPROTO_TCP: - /* Linux TCP option values match BSD's */ - name = args->optname; + name = linux_to_bsd_tcp_sockopt(args->optname); break; default: name = -1; Index: i386/linux/linux.h =================================================================== --- i386/linux/linux.h (revision 245225) +++ i386/linux/linux.h (working copy) @@ -701,6 +701,13 @@ #define LINUX_IP_ADD_MEMBERSHIP 35 #define LINUX_IP_DROP_MEMBERSHIP 36 +#define LINUX_TCP_NODELAY 1 +#define LINUX_TCP_MAXSEG 2 +#define LINUX_TCP_KEEPIDLE 4 +#define LINUX_TCP_KEEPINTVL 5 +#define LINUX_TCP_KEEPCNT 6 +#define LINUX_TCP_MD5SIG 14 + struct l_sockaddr { l_ushort sa_family; char sa_data[14]; -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Sat Jan 19 23:56:42 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 2383EF2 for ; Sat, 19 Jan 2013 23:56:42 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id B0B3D68B for ; Sat, 19 Jan 2013 23:56:40 +0000 (UTC) Received: from server.rulingia.com (c220-239-253-186.belrs5.nsw.optusnet.com.au [220.239.253.186]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id r0JNuUQS052570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 20 Jan 2013 10:56:31 +1100 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id r0JNuPaV025999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Jan 2013 10:56:25 +1100 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id r0JNuOVC025997; Sun, 20 Jan 2013 10:56:24 +1100 (EST) (envelope-from peter) Date: Sun, 20 Jan 2013 10:56:24 +1100 From: Peter Jeremy To: "Stephen J. Kiernan" Subject: Re: [JNPR] Proposal for changes to network device drivers and network stack (RFC) Message-ID: <20130119235624.GB30633@server.rulingia.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BwCQnh7xodEAoBMC" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp 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: Sat, 19 Jan 2013 23:56:42 -0000 --BwCQnh7xodEAoBMC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2013-Jan-17 14:38:06 -0500, "Stephen J. Kiernan" wr= ote: >The patch also includes moving zlib.[ch] and zlibutil.h out of net and=20 >into sys/libkern (for the .c) and sys/sys (for the .h). Good. >It really doesn't make much sense for that code to live in net,=20 >especially when so many things which are not the network stack utilize=20 >it. One thing that currently doesn't is ZFS - which has its own copy. It would be nice if ZFS could use the common copy. >Is that going to be a problem? Should simple stubs be added in the=20 >original locations in net/ to include the one in sys/ now? IMHO, no. zlib wasn't an advertised API so nothing outside the base OS should be using it. If you've moved all the kernel code to use the new location, that should be enough. --=20 Peter Jeremy --BwCQnh7xodEAoBMC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlD7MqgACgkQ/opHv/APuIfV+wCfT4VH01zeR9usrkh1egAH3GOD 5uAAn1apvfHbpc+5383XM4lAIwMUKBtL =LC6R -----END PGP SIGNATURE----- --BwCQnh7xodEAoBMC--