From owner-freebsd-net@FreeBSD.ORG Sun Sep 8 00:25:19 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0257995A; Sun, 8 Sep 2013 00:25:18 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ee0-x22f.google.com (mail-ee0-x22f.google.com [IPv6:2a00:1450:4013:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 30A182CCF; Sun, 8 Sep 2013 00:25:18 +0000 (UTC) Received: by mail-ee0-f47.google.com with SMTP id d49so2349414eek.6 for ; Sat, 07 Sep 2013 17:25:16 -0700 (PDT) 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=wzQX3A8xfDuNDhu+K/pgNbPEnXMcWTpC/kzjDnK6xGY=; b=v3wuF2zarKoOA9yF0X2p73kqhcKFr1nHa14OyUDdamx3uXRZL+AWXL3opciL/e1MWN +kvxAcSmxwmgHUt/gcYTzFmbGdO79DtWv5vIVkNQeIGQ5XZR1MkIFBTK1CHv4dMFN1Sl Dlh80LHVgZH9YVDmGnrEQpBkZ7JL+tzAxkWWu1ceNcARvXjOeg7H7FKXfEVUloywSnl0 K5G8znjfuRWsN1y00wXAgTZh7swFa/rYowz0EV+sdqLnvcR13egSUuiRzOMxEKGE+ZFY a3tqBsp6RmX0WJYigIRnP7QHH/2alD3TTtABR39X+5NNO8RxtRFcev1WZQq0wMWIr48o lsBQ== MIME-Version: 1.0 X-Received: by 10.15.64.1 with SMTP id n1mr17328564eex.15.1378599915944; Sat, 07 Sep 2013 17:25:15 -0700 (PDT) Received: by 10.14.105.137 with HTTP; Sat, 7 Sep 2013 17:25:15 -0700 (PDT) In-Reply-To: <1378583762.1111.512.camel@revolution.hippie.lan> References: <9CBFAD35-D651-4E28-BEBB-DC3717F38567@bsdimp.com> <1378583762.1111.512.camel@revolution.hippie.lan> Date: Sat, 7 Sep 2013 17:25:15 -0700 Message-ID: Subject: Re: mbuf autotuning effect From: hiren panchasara To: Ian Lepore Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" , "freebsd-mips@freebsd.org" , Warner Losh 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, 08 Sep 2013 00:25:19 -0000 On Sat, Sep 7, 2013 at 12:56 PM, Ian Lepore wrote: > On Sat, 2013-09-07 at 12:21 -0700, hiren panchasara wrote: > > On Sep 6, 2013 8:26 PM, "Warner Losh" wrote: > > > > > > > > > On Sep 6, 2013, at 7:11 PM, Adrian Chadd wrote: > > > > > > > Yeah, why is VM_KMEM_SIZE only 12mbyte for MIPS? That's a little > > low > > for a > > > > platform that has a direct map that's slightly larger than 12mb :) > > > > > > > > Warner? Juli? > > > > > > All architectures have it at 12MB, except sparc64 where it is 16MB. > > This > > can be changed with the options VM_KMEM_SIZE=xxxxx in the config file. > > > > Right. Does that mean for any platform, if we do not have nmbclusters > > pre-set in kmeminit() than we will always have pretty low value of > > vm_kmem_size. And because of that, if maxmbufmem is not pre-set (via > > loader.conf) inside tunable_mbinit() , we will have very low value for > > maxmbufmem too. > > > > I hope (partially believe) that my understanding is not entirely > > correct. > > Because if its correct, we arw depending on loader.conf instead of > > actually > > auto tuning. > > > I think the part of this that strikes me as strange is calling 20% of > physical memory used for network buffers a "very low value". It seems > outrageously high to me. I'd be pissed if that much memory got wasted > on network buffers on one of our $work platforms with so little memory. > Interesting. So here how it looks on my laptop running amd64 GENERIC looks like: (without any special loader.conf settings) flymockour-l7% uname -a FreeBSD flymockour-l7.corp.yahoo.com 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r253512M: Sat Jul 20 23:00:51 PDT 2013 hirenp@flymockour-l7.corp.yahoo.com:/usr/obj/usr/home/hirenp/head/sys/GENERIC amd64 flymockour-l7% sysctl -a | grep hw| grep mem hw.physmem: 8496877568 hw.usermem: 3538432000 hw.realmem: 9093251072 flymockour-l7% sysctl kern.ipc.maxmbufmem kern.ipc.maxmbufmem: 4132540416 flymockour-l7% sysctl -a | grep vm.kmem_ vm.kmem_size: 8265080832 vm.kmem_size_min: 0 vm.kmem_size_max: 329853485875 vm.kmem_size_scale: 1 vm.kmem_map_size: 1380515840 vm.kmem_map_free: 5796265984 VM_KMEM_SIZE_SCALE is 1 for amd64 while 3 for mips. Which might be one reason. > So the fact that you think it's crazy-low and I think it's crazy-high > may be a sign that it's auto-tuned to a reasonable compromise, and in > both our cases the right fix would be to use the available knobs to tune > things for our particular uses. > I am pretty ignorant on what the value _should_ be. I will try to find out more. cheers, Hiren From owner-freebsd-net@FreeBSD.ORG Sun Sep 8 05:57: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 13C5AE1B; Sun, 8 Sep 2013 05:57:30 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ea0-x233.google.com (mail-ea0-x233.google.com [IPv6:2a00:1450:4013:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2126C2AC5; Sun, 8 Sep 2013 05:57:28 +0000 (UTC) Received: by mail-ea0-f179.google.com with SMTP id b10so2449585eae.10 for ; Sat, 07 Sep 2013 22:57:27 -0700 (PDT) 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=k7hEDBTfwMDx4LKQsjGR2EkW4dG4naRWhPaGjkNZxtY=; b=CzELVKoeY9PGOcdUW+bStnpSFfVIw/r70EMgPUWyhCI2OtGruBI8w759NeJ/KfwPro R4PHfmMREHv5cQtlWMcSwEjwJdCKssdus9EiyoTnyUITOJZFCN7na4bCcW6TVS6zZ3IF 6ApdQ4orKt5o1aIFrQP/aCkdRa+tAzBo8MkG4X7HatmEhXt/44/W10cP8VvNo/5wLSvD 6+GpvKcE5TUF2UHSEMHlS3Lkd1bXb6yT+6CCpzzfyR695QVdXuwGc5zbaGbcc2fDWAs3 ZhlwO4/DJGhfodOBlbmpNcUhOznGWIM67cIlVcQK07n86ExZzgiWdoBCff4DJjuqokYf H5zg== MIME-Version: 1.0 X-Received: by 10.14.4.1 with SMTP id 1mr19181474eei.21.1378619847484; Sat, 07 Sep 2013 22:57:27 -0700 (PDT) Received: by 10.14.105.137 with HTTP; Sat, 7 Sep 2013 22:57:27 -0700 (PDT) In-Reply-To: References: <9CBFAD35-D651-4E28-BEBB-DC3717F38567@bsdimp.com> <1378583762.1111.512.camel@revolution.hippie.lan> Date: Sat, 7 Sep 2013 22:57:27 -0700 Message-ID: Subject: Re: mbuf autotuning effect From: hiren panchasara To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Net , "freebsd-mips@freebsd.org" , Ian Lepore , Warner Losh 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, 08 Sep 2013 05:57:30 -0000 On Sat, Sep 7, 2013 at 1:39 PM, Adrian Chadd wrote: > On 7 September 2013 12:56, Ian Lepore wrote: > > >> I think the part of this that strikes me as strange is calling 20% of >> physical memory used for network buffers a "very low value". It seems >> outrageously high to me. I'd be pissed if that much memory got wasted >> on network buffers on one of our $work platforms with so little memory. >> >> So the fact that you think it's crazy-low and I think it's crazy-high >> may be a sign that it's auto-tuned to a reasonable compromise, and in >> both our cases the right fix would be to use the available knobs to tune >> things for our particular uses. >> > > Well, which limit is actually being hit here? 20% of 32mb is still a lot > of memory buffers.. > > Now, for sizing up the needed buffers for wifi: > > assuming 512 tx, 512 rx buffers for two ath NICs. > > another 512+512 buffers for each arge NICs. > > So, 4096 mbufs here, 2k each, so ~ 8mb of RAM. > And we are only getting 6mb of maxmbufmem with current setup. Index: mips/include/vmparam.h =================================================================== --- mips/include/vmparam.h (revision 255320) +++ mips/include/vmparam.h (working copy) @@ -119,7 +119,7 @@ * is the total KVA space allocated for kmem_map. */ #ifndef VM_KMEM_SIZE_SCALE -#define VM_KMEM_SIZE_SCALE (3) +#define VM_KMEM_SIZE_SCALE (1) #endif /* As I mentioned on another reply in the same thread, VM_KMEM_SIZE_SCALE is 1 for amd64. If I do the same for mips as above, we get # sysctl -a | grep maxmbuf kern.ipc.maxmbufmem: 14407680 Now, do we want to have this much rams assigned to mbufs is another question. cheers, Hiren From owner-freebsd-net@FreeBSD.ORG Sun Sep 8 07:20: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 21542ED9 for ; Sun, 8 Sep 2013 07:20:03 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6C37D2E57 for ; Sun, 8 Sep 2013 07:20:02 +0000 (UTC) Received: (qmail 59840 invoked from network); 8 Sep 2013 07:59:54 -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 ; 8 Sep 2013 07:59:54 -0000 Message-ID: <522C2516.9030406@freebsd.org> Date: Sun, 08 Sep 2013 09:19:50 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ian Lepore Subject: Re: mbuf autotuning effect References: <9CBFAD35-D651-4E28-BEBB-DC3717F38567@bsdimp.com> <1378583762.1111.512.camel@revolution.hippie.lan> In-Reply-To: <1378583762.1111.512.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, hiren panchasara , "freebsd-mips@freebsd.org" , Warner Losh 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, 08 Sep 2013 07:20:03 -0000 On 07.09.2013 21:56, Ian Lepore wrote: > On Sat, 2013-09-07 at 12:21 -0700, hiren panchasara wrote: >> On Sep 6, 2013 8:26 PM, "Warner Losh" wrote: >>> >>> >>> On Sep 6, 2013, at 7:11 PM, Adrian Chadd wrote: >>> >>>> Yeah, why is VM_KMEM_SIZE only 12mbyte for MIPS? That's a little >> low >> for a >>>> platform that has a direct map that's slightly larger than 12mb :) >>>> >>>> Warner? Juli? >>> >>> All architectures have it at 12MB, except sparc64 where it is 16MB. >> This >> can be changed with the options VM_KMEM_SIZE=xxxxx in the config file. >> >> Right. Does that mean for any platform, if we do not have nmbclusters >> pre-set in kmeminit() than we will always have pretty low value of >> vm_kmem_size. And because of that, if maxmbufmem is not pre-set (via >> loader.conf) inside tunable_mbinit() , we will have very low value for >> maxmbufmem too. >> >> I hope (partially believe) that my understanding is not entirely >> correct. >> Because if its correct, we arw depending on loader.conf instead of >> actually >> auto tuning. >> > I think the part of this that strikes me as strange is calling 20% of > physical memory used for network buffers a "very low value". It seems > outrageously high to me. I'd be pissed if that much memory got wasted > on network buffers on one of our $work platforms with so little memory. This memory is NOT allocated to the mbuf system. It is just the upper *limit* how far it can go when the demand is there. > So the fact that you think it's crazy-low and I think it's crazy-high > may be a sign that it's auto-tuned to a reasonable compromise, and in > both our cases the right fix would be to use the available knobs to tune > things for our particular uses. Yes. The autotuning network memory *limit* is a compromise that allows big beefy network servers work well right out of the box while not killing small ones. Lets say it covers > 90% of our actual users and use cases. If you have special requirements then you may have to tune these values, but if you known exactly what your system is going to do, then chances are you're tuning various other parameters anyways. -- Andre From owner-freebsd-net@FreeBSD.ORG Sun Sep 8 18:45:03 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 57E648B2; Sun, 8 Sep 2013 18:45:03 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2C41D2B06; Sun, 8 Sep 2013 18:45:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r88Ij3jU027899; Sun, 8 Sep 2013 18:45:03 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r88Ij3Lr027838; Sun, 8 Sep 2013 18:45:03 GMT (envelope-from linimon) Date: Sun, 8 Sep 2013 18:45:03 GMT Message-Id: <201309081845.r88Ij3Lr027838@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/181931: [vlan] [lagg] vlan over lagg over mlxen crashes the kernel 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, 08 Sep 2013 18:45:03 -0000 Old Synopsis: vlan over lagg over mlxen crashes the kernel New Synopsis: [vlan] [lagg] vlan over lagg over mlxen crashes the kernel Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Sep 8 18:44:40 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=181931 From owner-freebsd-net@FreeBSD.ORG Mon Sep 9 07:44:21 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DC3A0A9E for ; Mon, 9 Sep 2013 07:44:20 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 348EF2D05 for ; Mon, 9 Sep 2013 07:44:19 +0000 (UTC) Received: (qmail 64804 invoked from network); 9 Sep 2013 08:24:01 -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 ; 9 Sep 2013 08:24:01 -0000 Message-ID: <522D7C46.6030004@freebsd.org> Date: Mon, 09 Sep 2013 09:44:06 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Navdeep Parhar Subject: Re: Please review: lazy ext refcount initialization References: <521FD217.5080603@FreeBSD.org> In-Reply-To: <521FD217.5080603@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 07:44:21 -0000 On 30.08.2013 00:58, Navdeep Parhar wrote: > I'd like to merge r254342 from user/np/cxl_tuning to head if there are > no objections. I don't object in principle, though I'm wonder whether we should have a more generic way of passing this kind of flags to the allocator? We probably get more demands for special allocations or variants in the future. And now would be the time as it is still in its infancy and we can easily adjust all consumers before it becomes widespread. See more comments inline. > http://svnweb.freebsd.org/base/user/np/cxl_tuning/sys/kern/kern_mbuf.c?r1=254334&r2=254342&diff_format=u > http://svnweb.freebsd.org/base/user/np/cxl_tuning/sys/sys/mbuf.h?r1=254334&r2=254342&diff_format=u > > --------------------- > Perform lazy initialization of a cluster's refcount if possible. This > doesn't change anything for the common cases where the constructor is > given an mbuf to attach to the cluster, or when the cluster is obtained > with m_cljget(NULL, ...) and attached later with m_cljset(). But it > allows for an alternate usage scenario where the cluster is managed > EXT_EXTREF style without ever having to look up its "usual" refcount via > uma_find_refcnt. > --------------------- > > Regards, > Navdeep > > diff -r 9753d3e51363 -r c9388a59fba6 sys/kern/kern_mbuf.c > --- a/sys/kern/kern_mbuf.c Thu Aug 29 11:16:04 2013 -0700 > +++ b/sys/kern/kern_mbuf.c Thu Aug 29 11:16:04 2013 -0700 > @@ -503,8 +503,6 @@ mb_dtor_pack(void *mem, int size, void * > static int > mb_ctor_clust(void *mem, int size, void *arg, int how) > { > - struct mbuf *m; > - u_int *refcnt; > int type; > uma_zone_t zone; > > @@ -535,10 +533,11 @@ mb_ctor_clust(void *mem, int size, void > break; > } > > - m = (struct mbuf *)arg; > - refcnt = uma_find_refcnt(zone, mem); > - *refcnt = 1; > - if (m != NULL) { > + if (arg != NULL) { > + struct mbuf *m = arg; > + u_int *refcnt = uma_find_refcnt(zone, mem); We typically do not declare variables inside {} statements but only at the top of a function. Also declaration-initialization is not really permitted by style(9) even though it is used in a few places. -- Andre > + > + *refcnt = 1; > m->m_ext.ext_buf = (caddr_t)mem; > m->m_data = m->m_ext.ext_buf; > m->m_flags |= M_EXT; > @@ -549,6 +548,10 @@ mb_ctor_clust(void *mem, int size, void > m->m_ext.ext_type = type; > m->m_ext.ext_flags = 0; > m->m_ext.ref_cnt = refcnt; > + } else { > +#ifdef INVARIANTS > + *uma_find_refcnt(zone, mem) = 0; > +#endif > } > > return (0); > diff -r 9753d3e51363 -r c9388a59fba6 sys/sys/mbuf.h > --- a/sys/sys/mbuf.h Thu Aug 29 11:16:04 2013 -0700 > +++ b/sys/sys/mbuf.h Thu Aug 29 11:16:04 2013 -0700 > @@ -721,6 +721,7 @@ m_cljset(struct mbuf *m, void *cl, int t > m->m_ext.ext_type = type; > m->m_ext.ext_flags = 0; > m->m_ext.ref_cnt = uma_find_refcnt(zone, cl); > + *m->m_ext.ref_cnt = 1; > m->m_flags |= M_EXT; > > } > > _______________________________________________ > 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 Sep 9 11:06:51 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C2E19DFD for ; Mon, 9 Sep 2013 11:06:51 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AF80D29FE for ; Mon, 9 Sep 2013 11:06:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r89B6pp9016131 for ; Mon, 9 Sep 2013 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r89B6pF1015291 for freebsd-net@FreeBSD.org; Mon, 9 Sep 2013 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 9 Sep 2013 11:06:51 GMT Message-Id: <201309091106.r89B6pF1015291@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, 09 Sep 2013 11:06:51 -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/181931 net [vlan] [lagg] vlan over lagg over mlxen crashes the ke o kern/181823 net [ip6] [patch] make ipv6 mroute return same errror code o kern/181703 net [re] [patch] Fix Realtek 8111G Ethernet controller not o kern/181699 net [ipsec] [patch] IPsec does scale to large SPD / SADB o kern/181657 net [bpf] [patch] BPF_COP/BPF_COPX instruction reservation o kern/181257 net [bge] bge link status change o kern/181236 net [igb] igb driver unstable work o kern/181225 net [infiniband] [patch] unloading ipoib crashes the kerne o kern/181135 net [netmap] [patch] sys/dev/netmap patch for Linux compat o kern/181131 net [netmap] [patch] sys/dev/netmap memory allocation impr o kern/181006 net [run] [patch] mbuf leak in run(4) driver o kern/180893 net [if_ethersubr] [patch] Packets received with own LLADD o kern/180844 net [panic] [re] Intermittent panic (re driver?) o kern/180775 net [bxe] if_bxe driver broken with Broadcom BCM57711 card o kern/180722 net [bluetooth] bluetooth takes 30-50 attempts to pair to s kern/180468 net [request] LOCAL_PEERCRED support for PF_INET o kern/180065 net [netinet6] [patch] Multicast loopback to own host brok o kern/179926 net [lacp] [patch] active aggregator selection bug o kern/179824 net [ixgbe] System (9.1-p4) hangs on heavy ixgbe network t o kern/179733 net [lagg] [patch] interface loses capabilities when proto o kern/179429 net [tap] STP enabled tap bridge o kern/179299 net [igb] Intel X540-T2 - unstable driver a kern/179264 net [vimage] [pf] Core dump with Packet filter and VIMAGE o kern/178947 net [arp] arp rejecting not working o kern/178782 net [ixgbe] 82599EB SFP does not work with passthrough und o kern/178612 net [run] kernel panic due the problems with run driver o kern/178472 net [ip6] [patch] make return code consistent with IPv4 co o kern/178079 net [tcp] Switching TCP CC algorithm panics on sparc64 wit s kern/178071 net FreeBSD unable to recongize Kontron (Industrial Comput o kern/177905 net [xl] [panic] ifmedia_set when pluging CardBus LAN card o kern/177618 net [bridge] Problem with bridge firewall with trunk ports o kern/177417 net [ip6] Invalid protocol value in ipsec6_common_input_cb o kern/177402 net [igb] [pf] problem with ethernet driver igb + pf / alt o kern/177400 net [jme] JMC25x 1000baseT establishment issues o kern/177366 net [ieee80211] negative malloc(9) statistics for 80211nod f kern/177362 net [netinet] [patch] Wrong control used to return TOS o kern/177194 net [netgraph] Unnamed netgraph nodes for vlan interfaces o kern/177139 net [igb] igb drops ethernet ports 2 and 3 o kern/176884 net [re] re0 flapping up/down o kern/176671 net [epair] MAC address for epair device not unique o kern/176484 net [ipsec] [enc] [patch] panic: IPsec + enc(4); device na o kern/176446 net [netinet] [patch] Concurrency in ixgbe driving out-of- o kern/176420 net [kernel] [patch] incorrect errno for LOCAL_PEERCRED o kern/176419 net [kernel] [patch] socketpair support for LOCAL_PEERCRED o kern/176401 net [netgraph] page fault in netgraph o kern/176167 net [ipsec][lagg] using lagg and ipsec causes immediate pa o kern/176097 net [lagg] [patch] lagg/lacp broken when aggregated interf o kern/176027 net [em] [patch] flow control systcl consistency for em dr o kern/176026 net [tcp] [patch] TCP wrappers caused quite a lot of warni o bin/175974 net ppp(8): logic issue o kern/175864 net [re] Intel MB D510MO, onboard ethernet not working aft o kern/175852 net [amd64] [patch] in_cksum_hdr() behaves differently on o kern/175734 net no ethernet detected on system with EG20T PCH chipset o kern/175267 net [pf] [tap] pf + tap keep state problem o kern/175236 net [epair] [gif] epair and gif Devices On Bridge o kern/175182 net [panic] kernel panic on RADIX_MPATH when deleting rout o kern/175153 net [tcp] will there miss a FIN when do TSO? o kern/174959 net [net] [patch] rnh_walktree_from visits spurious nodes o kern/174958 net [net] [patch] rnh_walktree_from makes unreasonable ass o kern/174897 net [route] Interface routes are broken o kern/174851 net [bxe] [patch] UDP checksum offload is wrong in bxe dri o kern/174850 net [bxe] [patch] bxe driver does not receive multicasts o kern/174849 net [bxe] [patch] bxe driver can hang kernel when reset o kern/174822 net [tcp] Page fault in tcp_discardcb under high traffic o kern/174602 net [gif] [ipsec] traceroute issue on gif tunnel with ipse o kern/174535 net [tcp] TCP fast retransmit feature works strange o kern/173871 net [gif] process of 'ifconfig gif0 create hangs' when if_ o kern/173475 net [tun] tun(4) stays opened by PID after process is term o kern/173201 net [ixgbe] [patch] Missing / broken ixgbe sysctl's and tu o kern/173137 net [em] em(4) unable to run at gigabit with 9.1-RC2 o kern/173002 net [patch] data type size problem in if_spppsubr.c o kern/172895 net [ixgb] [ixgbe] do not properly determine link-state o kern/172683 net [ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos o kern/172113 net [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net [ip6] IPv6 packets transmitting only on queue 0 o kern/171739 net [bce] [panic] bce related kernel panic o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net [ndis] undocumented dependency for ndis(4) o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net [epair] [request] Add the ability to name epair device o kern/171228 net [re] [patch] if_re - eeprom write issues o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169664 net [bgp] Wrongful replacement of interface connected net o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/166462 net [gre] gre(4) when using a tunnel source address from c 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 p kern/165903 net mbuf leak 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/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/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155680 net [multicast] problems with multicast s kern/155642 net [new driver] [request] Add driver for Realtek RTL8191S o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [new driver] [request]: Port brcm80211 driver from Lin o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl p 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/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/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/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 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 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/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 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 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/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/121534 net [ipl] [nat] FreeBSD Release 6.3 Kernel Trap 12: 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] f kern/108197 net [panic] [gif] [ip6] if_delmulti reference counting pan 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/104738 net [inet] [patch] Reentrant problem with inet_ntoa in the 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/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling 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 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging 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/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation 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/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/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 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 465 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Sep 9 13:02:27 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BA8447CF for ; Mon, 9 Sep 2013 13:02:27 +0000 (UTC) (envelope-from marek_sal@wp.pl) Received: from mx4.wp.pl (mx4.wp.pl [212.77.101.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 441A322FF for ; Mon, 9 Sep 2013 13:02:26 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 11559 invoked from network); 9 Sep 2013 15:02:24 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1378731744; bh=s11SUU6lMbJRupGOTEJRgiC8LEvGPw9SyzvAFJbt86I=; h=From:To:Subject; b=ak6TeCzVLsmv83NwEawJ8tgGtGLIQlH5DiG8gsfZkoXBlymlHjqe4TIdVCcHt6epY JIA6bMCfGbtJeaIqB517BVNqCKZpduY5WKwocRvzCurXSnh4ilcwiqZrgFpDEQTJgE A7/ASaT1H9ZdVLb0Q6me/7f54RHHJMi7faYYxXsY= Received: from zcp.comp.com.pl (HELO [172.31.2.53]) (marek_sal@[91.198.145.1]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with CAMELLIA256-SHA encrypted SMTP for ; 9 Sep 2013 15:02:24 +0200 Message-ID: <522DC6DE.3040908@wp.pl> Date: Mon, 09 Sep 2013 15:02:22 +0200 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: igb Intel Gigabit Network Connection I350, lagg, vlan - increase mtu Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [kbPk] 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, 09 Sep 2013 13:02:27 -0000 Hi, My server is running with 4 Gigabit NICs: igb0@pci0:5:0:0: class=0x020000 card=0x152115d9 chip=0x15218086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'I350 Gigabit Network Connection' class = network subclass = ethernet igb1@pci0:5:0:1: class=0x020000 card=0x152115d9 chip=0x15218086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'I350 Gigabit Network Connection' class = network subclass = ethernet igb2@pci0:5:0:2: class=0x020000 card=0x152115d9 chip=0x15218086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'I350 Gigabit Network Connection' class = network subclass = ethernet igb3@pci0:5:0:3: class=0x020000 card=0x152115d9 chip=0x15218086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'I350 Gigabit Network Connection' class = network subclass = ethernet those NICs are connected to switch with LACP aggregation: lagg0: flags=8843 metric 0 mtu 1500 options=401bb ether 00:25:90:c1:1d:18 inet6 fe80::225:90ff:fec1:1d18%lagg0 prefixlen 64 scopeid 0x8 nd6 options=21 media: Ethernet autoselect status: active laggproto lacp lagghash l2,l3,l4 laggport: igb3 flags=1c laggport: igb2 flags=1c laggport: igb1 flags=1c laggport: igb0 flags=1c Using this lagg interface I created 2 vlan interfaces: vlan14: flags=8843 metric 0 mtu 1500 options=103 ether 00:25:90:c1:1d:18 inet 192.168.1.65 netmask 0xffffff00 broadcast 192.168.1.255 inet6 fe80::225:90ff:fec1:1d18%vlan14 prefixlen 64 scopeid 0x9 nd6 options=29 media: Ethernet autoselect status: active vlan: 14 parent interface: lagg0 vlan900: flags=8843 metric 0 mtu 1500 options=103 ether 00:25:90:c1:1d:18 inet6 fe80::225:90ff:fec1:1d18%vlan900 prefixlen 64 scopeid 0xa inet 172.25.25.65 netmask 0xffff0000 broadcast 172.25.255.255 nd6 options=29 media: Ethernet autoselect status: active vlan: 900 parent interface: lagg0 I would like to increase the MTU on cards, but I can't set it in any way: % sudo ifconfig igbX mtu 9000 [14:59:37] ifconfig: ioctl (set mtu): Invalid argument event setting the MTU to 1500 (default value) results in same error. same for lagg0, and vlanX How can I increase the MTU for lagg interface ? Is it possible without rebooting or only via /etc/rc.conf ? Regards, -- Marek Salwerowicz From owner-freebsd-net@FreeBSD.ORG Mon Sep 9 13:06:42 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0332D9E1 for ; Mon, 9 Sep 2013 13:06:42 +0000 (UTC) (envelope-from marek_sal@wp.pl) Received: from mx3.wp.pl (mx3.wp.pl [212.77.101.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7DF982340 for ; Mon, 9 Sep 2013 13:06:41 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 14699 invoked from network); 9 Sep 2013 15:06:38 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1378731998; bh=bGt4PJ1/d/sJ14juw2TKdcCQMHPh5CEXpp4ISy7cXZ0=; h=From:To:Subject; b=DlK1g8xUCgS55uwz0PtzZG4m09D4RRBksijSq5mim4NWu7oQbZupLVGhuqwA0Ur23 3Fy3Ibx3ifLodvGFpLO/hl54T2pPiGVUa/YMczdhH/tVLzFPVCbOgchLTalOISzObv KFSRboYOYGHJK7xvOZ+aizW3cN1iSVQ9kQTSxeo8= Received: from zcp.comp.com.pl (HELO [172.31.2.53]) (marek_sal@[91.198.145.1]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with CAMELLIA256-SHA encrypted SMTP for ; 9 Sep 2013 15:06:38 +0200 Message-ID: <522DC7DD.705@wp.pl> Date: Mon, 09 Sep 2013 15:06:37 +0200 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: igb Intel Gigabit Network Connection I350, lagg, vlan - increase mtu References: <522DC6DE.3040908@wp.pl> In-Reply-To: <522DC6DE.3040908@wp.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [UYPk] 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, 09 Sep 2013 13:06:42 -0000 W dniu 2013-09-09 15:02, Marek Salwerowicz pisze: > My server just to add - I am running the 9.1-RELEASE: FreeBSD storage1 9.1-RELEASE-p6 FreeBSD 9.1-RELEASE-p6 #0: Wed Aug 21 20:40:52 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 From owner-freebsd-net@FreeBSD.ORG Mon Sep 9 13:50:53 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6C419734 for ; Mon, 9 Sep 2013 13:50:53 +0000 (UTC) (envelope-from mark@fivenynes.com) Received: from golf.bouncedomains.com (golf.bouncedomains.com [103.18.252.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 276BB2714 for ; Mon, 9 Sep 2013 13:50:52 +0000 (UTC) Received: from ppp59-167-131-60.static.internode.on.net ([59.167.131.60]:50639 helo=[192.168.77.204]) by golf.bouncedomains.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VJ1G0-00064v-0Y; Mon, 09 Sep 2013 23:11:56 +1000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: igb Intel Gigabit Network Connection I350, lagg, vlan - increase mtu From: Mark van der Meulen In-Reply-To: <522DC7DD.705@wp.pl> Date: Mon, 9 Sep 2013 23:11:55 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <522DC6DE.3040908@wp.pl> <522DC7DD.705@wp.pl> To: Marek Salwerowicz X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - golf.bouncedomains.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - fivenynes.com X-Get-Message-Sender-Via: golf.bouncedomains.com: authenticated_id: mark@fivenynes.com X-Source: X-Source-Args: X-Source-Dir: 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, 09 Sep 2013 13:50:53 -0000 As far as I can tell, if you are using the links in a lagg then you are = going to need to make the change in /etc/rc.conf and reboot or perhaps = restart netif. I recently came across a similar situation where I had to = change the MTU across a bunch of different bsdrp boxes running as = firewalls and routers and in the end after a lot of research I worked = out the only way was either a reboot or possibly a restart of = networking. Some machines had Intel(em) and Broadcom(bcd and bge) = interfaces. I never tried restarting networking as there are a few things on my = boxes which that will break so I am better off just rebooting. Mark On 09/09/2013, at 11:06 PM, Marek Salwerowicz wrote: > W dniu 2013-09-09 15:02, Marek Salwerowicz pisze: >> My server >=20 > just to add - I am running the 9.1-RELEASE: >=20 > FreeBSD storage1 9.1-RELEASE-p6 FreeBSD 9.1-RELEASE-p6 #0: Wed Aug 21 = 20:40:52 UTC 2013 = root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 >=20 >=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" From owner-freebsd-net@FreeBSD.ORG Mon Sep 9 18:19:20 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E09BAA64 for ; Mon, 9 Sep 2013 18:19:20 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw14.york.ac.uk (mail-gw14.york.ac.uk [144.32.129.164]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9D4C42A63 for ; Mon, 9 Sep 2013 18:19:20 +0000 (UTC) Received: from buffy-128.york.ac.uk ([144.32.128.160]:35838 helo=buffy.york.ac.uk) by mail-gw14.york.ac.uk with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1VJ5wY-0000Sa-Nt for freebsd-net@FreeBSD.org; Mon, 09 Sep 2013 19:12:10 +0100 Received: from [127.0.0.1] (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.6/8.14.6) with ESMTP id r89ICACK013991 for ; Mon, 9 Sep 2013 19:12:10 +0100 (BST) (envelope-from gavin@FreeBSD.org) Subject: Reproducible IPSEC panic head r254660 ipsec6_output_tunnel() - encif is NULL. From: Gavin Atkinson To: freebsd-net@FreeBSD.org Content-Type: text/plain; charset="ASCII" Date: Mon, 09 Sep 2013 19:12:10 +0100 Message-ID: <1378750330.11656.44.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 18:19:20 -0000 Hi all, I have a reproducible kernel panic on a machine running head, r254660: Thu Aug 22 19:51:00 UTC 2013 amd64. The machine in question is a firewall. It already has one IPSEC tunnel in place, which seems stable. Bringing up a second leads to almost instant panic: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xd0 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff806d5ada stack pointer = 0x28:0xfffffe011ad614b0 frame pointer = 0x28:0xfffffe011ad61580 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (swi5: fast taskq) #8 0xffffffff807d277a in trap (frame=0xfffffe011ad61400) at /usr/src/sys/amd64/amd64/trap.c:463 #9 0xffffffff807bae03 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #10 0xffffffff806d5ada in ipsec6_output_tunnel (state=0xfffffe011ad615d0, sp=, flags=) at /usr/src/sys/netipsec/ipsec_output.c:815 #11 0xffffffff806b4f5a in ip6_forward (m=0xfffff80005e11100, srcrt=0) at /usr/src/sys/netinet6/ip6_forward.c:292 #12 0xffffffff806b7566 in ip6_input (m=0xfffff80005e11100) at /usr/src/sys/netinet6/ip6_input.c:961 #13 0xffffffff805f264d in netisr_dispatch_src (proto=10, source=0, m=) at /usr/src/sys/net/netisr.c:1013 #14 0xffffffff805e4f59 in ether_demux (ifp=0xfffff80002bd7800, m=0xfffff80005e11100) at /usr/src/sys/net/if_ethersubr.c:850 #15 0xffffffff805e5249 in ether_nh_input (m=) at /usr/src/sys/net/if_ethersubr.c:645 #16 0xffffffff805f264d in netisr_dispatch_src (proto=9, source=0, m=) at /usr/src/sys/net/netisr.c:1013 #17 0xffffffff8045d579 in re_rxeof (sc=0xfffffe0000811000, rx_npktsp=0x0) at /usr/src/sys/dev/re/if_re.c:2326 #18 0xffffffff8046170a in re_int_task (arg=, npending=) at /usr/src/sys/dev/re/if_re.c:2546 #19 0xffffffff80554e63 in taskqueue_run_locked (queue=0xfffff800029e8400) at /usr/src/sys/kern/subr_taskqueue.c:333 #20 0xffffffff80554fad in taskqueue_run (queue=0xfffff800029e8400) at /usr/src/sys/kern/subr_taskqueue.c:347 #21 0xffffffff804dc05a in intr_event_execute_handlers ( p=, ie=0xfffff800029e8300) at /usr/src/sys/kern/kern_intr.c:1263 #22 0xffffffff804dd6eb in ithread_loop (arg=0xfffff80002951980) at /usr/src/sys/kern/kern_intr.c:1276 #23 0xffffffff804d90f9 in fork_exit ( callout=0xffffffff804dd650 , arg=0xfffff80002951980, frame=0xfffffe011ad61c00) at /usr/src/sys/kern/kern_fork.c:989 #24 0xffffffff807bb32e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:606 (kgdb) frame 10 #10 0xffffffff806d5ada in ipsec6_output_tunnel (state=0xfffffe011ad615d0, sp=, flags=) at /usr/src/sys/netipsec/ipsec_output.c:815 815 ipsec_bpf(m, isr->sav, AF_INET6, ENC_OUT|ENC_BEFORE); (kgdb) list 810 #ifdef DEV_ENC 811 encif->if_opackets++; 812 encif->if_obytes += m->m_pkthdr.len; 813 814 /* pass the mbuf to enc0 for bpf processing */ 815 ipsec_bpf(m, isr->sav, AF_INET6, ENC_OUT|ENC_BEFORE); 816 /* pass the mbuf to enc0 for packet filtering */ 817 if ((error = ipsec_filter(&m, PFIL_OUT, ENC_OUT| ENC_BEFORE)) != 0) 818 goto bad; 819 #endif (kgdb) p encif $5 = (struct ifnet *) 0x0 In /etc/rc.conf, I have simply: ipsec_enable="YES" ipsec_file="/etc/ipsec.conf" racoon_enable="yes" And two tunnels defined in both ipsec.conf and racoon.conf. Commenting out one of the two tunnels seems sufficient to avoid the panic, though it is not clear to me why. Adding cloned_interfaces="enc0" to /etc/rc.conf seems to be sufficient to work around the panic. So, how is this supposed to work? Who is supposed to be creating the enc0 interface? Thanks, Gavin -- Gavin Atkinson FreeBSD committer and bugmeister GPG: A093262B (313A A79F 697D 3A5C 216A EDF5 935D EF44 A093 262B) From owner-freebsd-net@FreeBSD.ORG Tue Sep 10 00:14:37 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 91C51B9D for ; Tue, 10 Sep 2013 00:14:37 +0000 (UTC) (envelope-from prvs=19659654a0=agave.spring@cadamericas.com) Received: from cadamericas.com (mail02.amotive.com [173.164.153.20]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 72A7E2D7D for ; Tue, 10 Sep 2013 00:14:36 +0000 (UTC) Received: from agave.cadamericas.com ([64.183.139.162]) by amotive.com (mail02.amotive.com) (MDaemon PRO v13.0.2) with ESMTP id md50002460702.msg; Mon, 09 Sep 2013 17:09:56 -0700 X-Spam-Processed: mail02.amotive.com, Mon, 09 Sep 2013 17:09:56 -0700 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 64.183.139.162 X-Return-Path: prvs=19659654a0=agave.spring@cadamericas.com X-Envelope-From: agave.spring@cadamericas.com X-MDaemon-Deliver-To: freebsd-net@freebsd.org Date: Mon, 9 Sep 2013 17:08:10 -0700 To: freebsd-net From: CAD Americas Subject: Green, Schain, Stephens, Ellis Will Speak at AUGI CAD Americas Message-ID: X-Priority: 3 X-Mailer: PHPMailer 5.2.1 (http://code.google.com/a/apache-extras.org/p/phpmailer/) X-CampTrackID: 300778a4-2d97-e69c-b8e8-522e6270a39b MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: CAD Americas List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 00:14:37 -0000 TIME IS RUNNING OUT! Register for CAD Americas Training Days by MAY 7 and S= AVE!=0ACAD AMERICAS TRAINING DAYS ARRIVE IN YOUR AREA SOON Join us for this= one-day training event in your area. Whether your focus is Mechanical Desi= gn, Construction, BIM, Electrical Design or Plant Design, there will be ses= sions that will improve your productivity immediately!=0AJune 4June 6June 7= June 12June 13June 26 June 27=0A Cleveland Cincinnati Detroit Atlanta D= allas San Jose San_Bernardino =0ATAKE HOME NEW TOOLS AND TECHNIQUES THAT = WILL IMPROVE YOUR PERFORMANCE IMMEDIATELY=0A=0A=0A=0A=0ALynn AllenTechnical= Evangelist More =0ARobert GreenCAD Mgmt Expert More =0ASteve SchainAutoCAD= Expert More =0ATod StephensRevit Expert More =0AClick here to see current = session descriptions.Please note that sessions will vary by location =0ALea= rn from well-known industry instructors who will share best practices and t= rends, product tips and tricks, new features =E2=80=A6 and more.=0AImprove = your productivity with new techniques that you can put to work right away.= =0AMeet your peers and exchange ideas on how to best use the CAD tools you = have to meet the demands of your job.=0ATake a closer look at services and = technologies offered by resellers in your area.=0AREGISTER BY MAY 7TH AND S= AVERegister for=C2=A0a CAD Americas Training Day by May 7th and save.=0AEar= ly Bird Rate: $150 (Until May 7th)=0AStandard Rate: $195 (AFTER May 7th)=0A= Student/Faculty Rate: $95 (must present current student ID upon check-in at= registration)=0AREGISTER FOR CAD AMERICAS TRAINING TODAY!=0A=0A=0A=0A=0AJo= in us at=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=C2=A0INTERNATIONAL SPONSORS=0A= =0A=0A=C2=A0=C2=A0 =C2=A0=C2=A0 =0A=0AEDUCATION SPONSOR=0A=0A=0AMEDIA SPONS= ORS=0A=0A=C2=A0=0AThis email was sent to email address: freebsd-net@freebsd= .org Click here to Opt-Out=0A From owner-freebsd-net@FreeBSD.ORG Tue Sep 10 00:59:20 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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 87A4EE4; Tue, 10 Sep 2013 00:59:20 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5CD572F2D; Tue, 10 Sep 2013 00:59:20 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r8A0xKi3045948; Tue, 10 Sep 2013 00:59:20 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r8A0xKD6045882; Tue, 10 Sep 2013 00:59:20 GMT (envelope-from linimon) Date: Tue, 10 Sep 2013 00:59:20 GMT Message-Id: <201309100059.r8A0xKD6045882@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/181970: [re] LAN Realtek® 8111G is not supported by re driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 00:59:20 -0000 Old Synopsis: update "re" driver New Synopsis: [re] LAN Realtek® 8111G is not supported by re driver Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Sep 10 00:58:32 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=181970 From owner-freebsd-net@FreeBSD.ORG Tue Sep 10 01:40:33 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CE7F9874; Tue, 10 Sep 2013 01:40:33 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A514820EE; Tue, 10 Sep 2013 01:40:33 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r8A1eXeO086294; Tue, 10 Sep 2013 01:40:33 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r8A1eXYc086178; Tue, 10 Sep 2013 01:40:33 GMT (envelope-from linimon) Date: Tue, 10 Sep 2013 01:40:33 GMT Message-Id: <201309100140.r8A1eXYc086178@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/181741: [kernel] [patch] Packet loss when 'control' messages are present with large data (sendmsg(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: Tue, 10 Sep 2013 01:40:33 -0000 Old Synopsis: [PATCH] Packet loss when 'control' messages are present with large data (sendmsg(2)) New Synopsis: [kernel] [patch] Packet loss when 'control' messages are present with large data (sendmsg(2)) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Sep 10 01:39:52 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=181741 From owner-freebsd-net@FreeBSD.ORG Tue Sep 10 02:15:10 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3C40CC32 for ; Tue, 10 Sep 2013 02:15:10 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 108A12254 for ; Tue, 10 Sep 2013 02:15:10 +0000 (UTC) Received: by mail-pb0-f50.google.com with SMTP id uo5so6854519pbc.23 for ; Mon, 09 Sep 2013 19:15:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=5zYwOGDTdyi1ECtXb6eJ83LMXMtx7d272C2H2Q/0JVw=; b=UI+CgNQv96rIWzEvLgBpMSRzMGNY9rdT0DKy/G9i+n7HczWqZEMTgoocBUZxzk27SP KEKsEVqfunPudRHLvM8CrUqu0TKr6QgpHqVUE0BzXDDhwwXmZTxlObFTGpu5TcHQuSHT 1C3WjGy+ryKzR8a5CqnlNK4pcz3emZTRaG1RV61nOmha0lpRsUgwQU5b0f2i2T/ABguo ZIK0r8hf4r+Qwp7kEOJ8nS/xLq/OrH1a3MZepat43bLGsWbWytLAhmO+L/QW1UlDaSu0 0BpCPsMIqwt+N6pSpbiOqmKJ6P7G1L13VFp4hLqJjV9vLjMcdQpX+oi7b4/nPIsCcjze cVeQ== X-Received: by 10.68.113.99 with SMTP id ix3mr459612pbb.180.1378779309368; Mon, 09 Sep 2013 19:15:09 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id k4sm14673378pbd.11.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 09 Sep 2013 19:15:08 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 10 Sep 2013 11:15:02 +0900 From: Yonghyeon PYUN Date: Tue, 10 Sep 2013 11:15:02 +0900 To: Guido Falsi Subject: Re: re0 not working at boot on -CURRENT Message-ID: <20130910021502.GA2962@michelle.cdnetworks.com> References: <51DC726D.6040601@madpilot.net> <20130710070431.GE2753@michelle.cdnetworks.com> <51DD9E15.7070609@madpilot.net> <20130906061521.GB3070@michelle.cdnetworks.com> <522A3E50.8080801@madpilot.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline In-Reply-To: <522A3E50.8080801@madpilot.net> 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, 10 Sep 2013 02:15:10 -0000 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Sep 06, 2013 at 10:42:56PM +0200, Guido Falsi wrote: > On 09/06/13 08:15, Yonghyeon PYUN wrote: > >On Wed, Jul 10, 2013 at 07:47:01PM +0200, Guido Falsi wrote: > >>On 07/10/13 09:04, Yonghyeon PYUN wrote: > >>>On Tue, Jul 09, 2013 at 10:28:29PM +0200, Guido Falsi wrote: > >>>>Hi, > >>>> > >>>>I have a PC with an integrate re ethernet interface, pciconf identifies > >>>>it like this: > >>>> > >>>>re0@pci0:3:0:0: class=0x020000 card=0x11c01734 chip=0x816810ec rev=0x07 > >>>>hdr=0x00 > >>>> > >>>>I'm running FreeBSD current r252261. > >>>> > >>>>As stated in the subject after boot the interface does not work > >>>>correctly. > >>>> > >>>>Using tcpdump on another host I noticed that packets (ICMP echo requests > >>>>for example) do get sent, and replies generated by the other host, but > >>>>the kernel does not seem to see them. Except that every now and then > >>>>some packet does get to the system. > >>>> > >>>>I'm seeing packet 7, 27, 47, 66, 86, 106, 125, 144, 164, 183 and so on > >>>>from a ping which has been running for some time. Just about one every > >>>>twenty. Some pattern is showing up. > >>>> > >>>>this is the output of ifconfig re0 after boot: > >>>> > >>>>re0: flags=8843 metric 0 mtu > >>>>1500 > >>>> > >>>>options=8209b > >>>> ether 00:19:99:f8:d3:0b > >>>> inet 172.24.42.13 netmask 0xffffff00 broadcast 172.24.42.255 > >>>> inet6 fe80::219:99ff:fef8:d30b%re0 prefixlen 64 scopeid 0x2 > >>>> nd6 options=29 > >>>> media: Ethernet autoselect (100baseTX ) > >>>> status: active > >>>> > >>>>If I just touch any interface flag with ifconfig, anyone, tso, -txcsum > >>>>-rxcsum, it starts working flawlessly. It keeps working also if I > >>>>perform the opposite operation with ifconfig afterwards, so it is not > >>>>the flag itself fixing it. > >>>> > >>>>This is an ifconfig after performing this exercise(it's the same, since > >>>>I disabled txcsum and reactivated it in this instance): > >>>> > >>>>re0: flags=8843 metric 0 mtu > >>>>1500 > >>>> > >>>>options=8209b > >>>> ether 00:19:99:f8:d3:0b > >>>> inet 172.24.42.13 netmask 0xffffff00 broadcast 172.24.42.255 > >>>> inet6 fe80::219:99ff:fef8:d30b%re0 prefixlen 64 scopeid 0x2 > >>>> nd6 options=29 > >>>> media: Ethernet autoselect (100baseTX ) > >>>> status: active > >>>> > >>>>I don't know much about FreeBSD network drivers so i can't make theories > >>>>about this. I hope someone has an idea what the problem could be. > >>>> > >>>>I'm available for any further information needed, test, experiment and > >>>>so on. > >>> > >>>Could you show me dmesg output(re(4) and rgephy(4) only)? > >> > >>re0: port > >>0xd000-0xd0ff mem 0xf2104000-0xf2104fff,0xf2100000-0xf2103fff irq 17 at > >>device 0.0 on pci3 > >>re0: Using 1 MSI-X message > >>re0: turning off MSI enable bit. > >>re0: Chip rev. 0x2c800000 > >>re0: MAC rev. 0x00000000 > >>re0: Ethernet address: 00:19:99:f8:d3:0b > >>miibus0: on re0 > >>rgephy0: PHY 1 on miibus0 > >>rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, > >>100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, > >>1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, > >>1000baseT-FDX-flow-master, auto, auto-flow > >> > >>Also, I'm loading this as a module, but, for as much as I know, this > >>should not make any difference. > >> > >> > >>>Did it ever work or you see the issue only on CURRENT? > >> > >>Never worked on this machine (I own it since the last days of February). > >> > >>I only installed current on it. If needed I can find time to test a > >>recent 9.x snapshot on it. > >> > >>I worked around the problem till now using an USB ethernet adapter, > >>always wanted to report this problem, but I've been lazy :) > >> > > > >Would you try attached patch and let me know whether it makes any > >difference? > > > > Hi! > > Thanks for looking into this and sorry for the delay in reporting back. > > Unluckily the patch does not solve nor mitigates the problem. Symptoms > are very similar. [...] > Only real difference is the re_eri_read timeout. It did not output that > error message before. Oops, sorry. It seems there is logic error in the diff. Try attached one again. --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="re.eri.diff2" Index: sys/dev/re/if_re.c =================================================================== --- sys/dev/re/if_re.c (revision 255410) +++ sys/dev/re/if_re.c (working copy) @@ -289,6 +289,9 @@ static int re_miibus_readreg (device_t, int, int); static int re_miibus_writereg (device_t, int, int, int); static void re_miibus_statchg (device_t); +static uint32_t re_eri_read (struct rl_softc *, bus_size_t, int); +static void re_eri_write (struct rl_softc *, bus_size_t, uint32_t, int); + static void re_set_jumbo (struct rl_softc *, int); static void re_set_rxmode (struct rl_softc *); static void re_reset (struct rl_softc *); @@ -602,6 +605,7 @@ re_miibus_statchg(device_t dev) struct rl_softc *sc; struct ifnet *ifp; struct mii_data *mii; + uint32_t exgmac; sc = device_get_softc(dev); mii = device_get_softc(sc->rl_miibus); @@ -627,14 +631,108 @@ re_miibus_statchg(device_t dev) break; } } + + if ((sc->rl_flags & RL_FLAG_LINK) == 0) + return; + /* * RealTek controllers does not provide any interface to * Tx/Rx MACs for resolved speed, duplex and flow-control * parameters. */ + + switch (sc->rl_hwrev->rl_rev) { + case RL_HWREV_8168E_VL: + if (sc->rl_icrev == 0x00100000) { + switch (IFM_SUBTYPE(mii->mii_media_active)) { + case IFM_1000_T: + re_eri_write(sc, 0x1BC, 0x00000011, + RL_ERIAR_EXGMAC); + re_eri_write(sc, 0x1BC, 0x00000005, + RL_ERIAR_EXGMAC); + break; + case IFM_100_TX: + re_eri_write(sc, 0x1BC, 0x0000001F, + RL_ERIAR_EXGMAC); + re_eri_write(sc, 0x1bc, 0x00000005, + RL_ERIAR_EXGMAC); + break; + default: + re_eri_write(sc, 0x1BC, 0x0000001F, + RL_ERIAR_EXGMAC); + re_eri_write(sc, 0x1BC, 0x0000003F, + RL_ERIAR_EXGMAC); + break; + } + } + exgmac = re_eri_read(sc, 0xDC, RL_ERIAR_EXGMAC); + exgmac &= ~0x01; + re_eri_write(sc, 0x1BC, exgmac, RL_ERIAR_EXGMAC); + exgmac |= 0x01; + re_eri_write(sc, 0x1BC, exgmac, RL_ERIAR_EXGMAC); + break; + case RL_HWREV_8168F: + case RL_HWREV_8411: + switch (IFM_SUBTYPE(mii->mii_media_active)) { + case IFM_1000_T: + re_eri_write(sc, 0x1BC, 0x00000011, RL_ERIAR_EXGMAC); + re_eri_write(sc, 0x1BC, 0x00000005, RL_ERIAR_EXGMAC); + break; + default: + re_eri_write(sc, 0x1BC, 0x0000001F, RL_ERIAR_EXGMAC); + re_eri_write(sc, 0x1BC, 0x0000003F, RL_ERIAR_EXGMAC); + break; + } + break; + } } +static uint32_t +re_eri_read(struct rl_softc *sc, bus_size_t addr, int type) +{ + int i; + + CSR_WRITE_4(sc, RL_ERIAR, addr | type | RL_ERIAR_BYTES_MASK | + RL_ERIAR_READ); + for (i = 100; i > 0; i--) { + DELAY(100); + if ((CSR_READ_4(sc, RL_ERIAR) & RL_ERIAR_READY) != 0) + break; + } + if (i == 0) { + device_printf(sc->rl_dev, "%s: timed out\n", __func__); + return (0xFFFFFFFF); + } + return (CSR_READ_4(sc, RL_ERIDR)); +} + /* + * ERI is used to access extended GigaMAC register. addr should be + * aligned on 4 bytes boundary. mask(e.g. bit 12~15 of RL_ERIAR) is + * used to determine which bytes in RL_ERIDR should be accessed. + * Because we have to access 32bits quantity regardless of the value + * of mask, make driver access to 4 bytes which in turn means it's + * responsibility of caller to preserve unwanted bytes in write + * access. + */ +static void +re_eri_write(struct rl_softc *sc, bus_size_t addr, uint32_t val, int type) +{ + int i; + + CSR_WRITE_4(sc, RL_ERIDR, val); + CSR_WRITE_4(sc, RL_ERIAR, addr | type | RL_ERIAR_BYTES_MASK | + RL_ERIAR_WRITE); + for (i = 100; i > 0; i--) { + DELAY(100); + if ((CSR_READ_4(sc, RL_ERIAR) & RL_ERIAR_BUSY) == 0) + break; + } + if (i == 0) + device_printf(sc->rl_dev, "%s: timed out\n", __func__); +} + +/* * Set the RX configuration and 64-bit multicast hash filter. */ static void @@ -1367,6 +1465,8 @@ re_attach(device_t dev) break; default: device_printf(dev, "Chip rev. 0x%08x\n", hwrev & 0x7c800000); + device_printf(dev, "IC rev. 0x%08x\n", hwrev & 0x00700000); + sc->rl_icrev = hwrev & 0x00700000; hwrev &= RL_TXCFG_HWREV; break; } @@ -1429,7 +1529,7 @@ re_attach(device_t dev) sc->rl_flags |= RL_FLAG_MACSLEEP; /* FALLTHROUGH */ case RL_HWREV_8168C: - if ((hwrev & 0x00700000) == 0x00200000) + if (sc->rl_icrev == 0x00200000) sc->rl_flags |= RL_FLAG_MACSLEEP; /* FALLTHROUGH */ case RL_HWREV_8168CP: Index: sys/pci/if_rlreg.h =================================================================== --- sys/pci/if_rlreg.h (revision 255410) +++ sys/pci/if_rlreg.h (working copy) @@ -143,6 +143,8 @@ #define RL_MACDBG 0x006D /* 8 bits, 8168C SPIN2 only */ #define RL_GPIO 0x006E /* 8 bits, 8168C SPIN2 only */ #define RL_PMCH 0x006F /* 8 bits */ +#define RL_ERIDR 0x0070 +#define RL_ERIAR 0x0074 #define RL_MAXRXPKTLEN 0x00DA /* 16 bits, chip multiplies by 8 */ #define RL_INTRMOD 0x00E2 /* 16 bits */ @@ -540,6 +542,19 @@ #define RL_GMEDIASTAT_TXFLOW 0x40 /* TX flow control on */ #define RL_GMEDIASTAT_TBI 0x80 /* TBI enabled */ +#define RL_ERIAR_BYTES_1ST 0x00001000 +#define RL_ERIAR_BYTES_2ND 0x00002000 +#define RL_ERIAR_BYTES_3RD 0x00004000 +#define RL_ERIAR_BYTES_4TH 0x00008000 +#define RL_ERIAR_BYTES_MASK 0x0000F000 +#define RL_ERIAR_EXGMAC 0x00000000 +#define RL_ERIAR_MSIX 0x00010000 +#define RL_ERIAR_ASF 0x00020000 +#define RL_ERIAR_READ 0x00000000 +#define RL_ERIAR_WRITE 0x80000000 +#define RL_ERIAR_BUSY 0x80000000 +#define RL_ERIAR_READY 0x80000000 + /* * The RealTek doesn't use a fragment-based descriptor mechanism. * Instead, there are only four register sets, each or which represents @@ -877,6 +892,7 @@ struct rl_softc { bus_dma_tag_t rl_parent_tag; uint8_t rl_type; const struct rl_hwrev *rl_hwrev; + uint32_t rl_icrev; int rl_eecmd_read; int rl_eewidth; int rl_expcap; --9jxsPFA5p3P2qPhR-- From owner-freebsd-net@FreeBSD.ORG Tue Sep 10 12:23:49 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5704430B for ; Tue, 10 Sep 2013 12:23:49 +0000 (UTC) (envelope-from michael.schuh@gmail.com) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 24981252C for ; Tue, 10 Sep 2013 12:23:49 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id i7so7680569oag.22 for ; Tue, 10 Sep 2013 05:23:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Kg0YH9GnyB0TBzLKEWa21B7e84zQ7jRskxYlPUCOn7k=; b=leFuupcNOW8wLiR8vNpsVRu7WKoKTHMDHVp+O3+Qt9Mkrla2UGn9me7MC+LPgm86G9 3nRd0HZYA6LxGFUyjIM/eZnzzlw2BO2OpoRd1tOD3T627k7gjAKRS3gGTee1PSRTi0dH eJd1oJOAkDyIKFF+4+JcFTtKXZS8AanSGDjYKy0wgckVETYLbb3QSmr7trBDT6RD/pp5 jfKIDdlj62utQCbVrf2P7nM2LhCw7MO22EuugxAebpXIIzk26M7Wc74/LLrPJu5933VS 9bNxbku/OkxwBkYqaD6DKiC5sV+npx8hGajRWj9OVW2wkIgLnS0Y4N+IwCuXMYITsT4a ftng== MIME-Version: 1.0 X-Received: by 10.182.129.201 with SMTP id ny9mr15754564obb.0.1378815828399; Tue, 10 Sep 2013 05:23:48 -0700 (PDT) Received: by 10.60.52.7 with HTTP; Tue, 10 Sep 2013 05:23:48 -0700 (PDT) Date: Tue, 10 Sep 2013 14:23:48 +0200 Message-ID: Subject: Re: igb Intel Gigabit Network Connection I350, lagg, vlan - increase mtu From: Michael Schuh To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 12:23:49 -0000 > Hi, > > My server is running with 4 Gigabit NICs: > > igb0@pci0:5:0:0: class=0x020000 card=0x152115d9 chip=0x15218086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = 'I350 Gigabit Network Connection' > class = network > subclass = ethernet > igb1@pci0:5:0:1: class=0x020000 card=0x152115d9 chip=0x15218086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = 'I350 Gigabit Network Connection' > class = network > subclass = ethernet > igb2@pci0:5:0:2: class=0x020000 card=0x152115d9 chip=0x15218086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = 'I350 Gigabit Network Connection' > class = network > subclass = ethernet > igb3@pci0:5:0:3: class=0x020000 card=0x152115d9 chip=0x15218086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = 'I350 Gigabit Network Connection' > class = network > subclass = ethernet > > > those NICs are connected to switch with LACP aggregation: > > lagg0: flags=8843 metric 0 mtu 1500 > > options=401bb > ether 00:25:90:c1:1d:18 > inet6 fe80::225:90ff:fec1:1d18%lagg0 prefixlen 64 scopeid 0x8 > nd6 options=21 > media: Ethernet autoselect > status: active > laggproto lacp lagghash l2,l3,l4 > laggport: igb3 flags=1c > laggport: igb2 flags=1c > laggport: igb1 flags=1c > laggport: igb0 flags=1c > > > Using this lagg interface I created 2 vlan interfaces: > > vlan14: flags=8843 metric 0 mtu > 1500 > options=103 > ether 00:25:90:c1:1d:18 > inet 192.168.1.65 netmask 0xffffff00 broadcast 192.168.1.255 > inet6 fe80::225:90ff:fec1:1d18%vlan14 prefixlen 64 scopeid 0x9 > nd6 options=29 > media: Ethernet autoselect > status: active > vlan: 14 parent interface: lagg0 > > > vlan900: flags=8843 metric 0 mtu > 1500 > options=103 > ether 00:25:90:c1:1d:18 > inet6 fe80::225:90ff:fec1:1d18%vlan900 prefixlen 64 scopeid 0xa > inet 172.25.25.65 netmask 0xffff0000 broadcast 172.25.255.255 > nd6 options=29 > media: Ethernet autoselect > status: active > vlan: 900 parent interface: lagg0 > > > I would like to increase the MTU on cards, but I can't set it in any way: > > % sudo ifconfig igbX mtu 9000 [14:59:37] > ifconfig: ioctl (set mtu): Invalid argument > > > event setting the MTU to 1500 (default value) results in same error. > same for lagg0, and vlanX > > > How can I increase the MTU for lagg interface ? > Is it possible without rebooting or only via /etc/rc.conf ? > > Regards, > -- > Marek Salwerowicz > Hi Marek, if i remember well the order of doing so is important. #1 set the mtu on each physical NIC to 9000 #2 create the lagg . . . on a running system it might consist of: destroy the vlans, destroy the lagg, set the mtu on each nic and rebuild the lagg and add the vlans. HTH regards michael From owner-freebsd-net@FreeBSD.ORG Tue Sep 10 22:42:23 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 571647FD for ; Tue, 10 Sep 2013 22:42:23 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm18.bullet.mail.ne1.yahoo.com (nm18.bullet.mail.ne1.yahoo.com [98.138.90.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1881723E5 for ; Tue, 10 Sep 2013 22:42:22 +0000 (UTC) Received: from [98.138.90.50] by nm18.bullet.mail.ne1.yahoo.com with NNFMP; 10 Sep 2013 22:42:16 -0000 Received: from [98.138.88.234] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 10 Sep 2013 22:42:16 -0000 Received: from [127.0.0.1] by omp1034.mail.ne1.yahoo.com with NNFMP; 10 Sep 2013 22:42:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 367858.39232.bm@omp1034.mail.ne1.yahoo.com Received: (qmail 2624 invoked by uid 60001); 10 Sep 2013 22:42:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1378852936; bh=BImvDAgnFYFGDpdcT/DTTYL6vqhdaSF8OeFhyATH4kI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=6mIWkb9VYRtRBBUSU+n8z056oQI3F+XJ3Vkb6H7X7TWYecd5iV1n+as/k5taDxIYhl3tYlRaY1g7FOdSf0mcMBLfC2/63DrTuzxKqd4bF9CntmxAKO3S/yMpu6JTQ5IJMvoyo8VP5TCh1d7/R0YZCR1i4meaTC4zBssX8QTTFJk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=aDk9u6E4rbuC4whqpoVDY6chOgL6wEmlLrVsRjzxZ7LtW4RlZCGF4PWT4kbii01RwVj9Zpaotl1aCgmFOxM00Hatit32b0ntRRQ5VKLRAa+c7M5XZYvLFeLkUxgIG4xscVogm2ofKrSThlM/j320JQUMKgQBLP+M7NOH1VQGd6E=; X-YMail-OSG: 6SwEySMVM1nUPFeG.jFvPMIlbQRDl.w1iVVsoGa7HeY3FS8 xHIwEnQyjRqH0AtEIhTwHh00COPOE6Rpr9dJz7cMtVivPXXkA_2jfgRLdoAG NweJamhdRI_80OsiCmFs8UHIA2NDHWo9PAlNegh_QOEHXjCYSoDz_g03vKHl xWzPpJetcKhM_iyQCMmQJLYmw_CdWLLZoadqbazE7qhzmwEWmPradfbhJC85 VdahCNclRhzoltmtz_48aVxwmSRmP2U5A1FLzj5ccBVQaZEsunqCl1j508eq QjmqsEvk5f6yO7sQUm0s65dzDhw6vuZwGLgBHqpHsmAkY95uZjIknbc1ITyi 5iY3aTuaNySQdNCr5hdLokoLgu8.SwA.a0eBDdCtQId2lRwSAWONqQm8Sb2z O2qAd6lMTtTq6.k_xaeswegulCjjsKkhLJbNdhJ8sR9dbxm0gAMbFA9X17D2 snrHG476H8QsSr7vdjhWjfw9zJpwcbRo2TwCCBDWxv3ESysftbsd_fOSfz.W SUwv07QhzX2gjCBzI2m.kF5fFWM1RQhR.ZwDneHiHr.5lids3scyHSb7tkIT UtsLM3oft98jtisNnKX0n2PiwlLclmaRthV9RxR7eI8B7ozY_r6SKEI8oha0 Hmp3Cvv1Dke_IDjf.YEKENkKSgxyF8sf2rx0WDMJoqyxRhahIpG5d1rgCXiw _WY2wQRBE8wclBogNSyBCoom.0zD6obKHEF0JBKVwfSvAie8J Received: from [98.203.118.124] by web121601.mail.ne1.yahoo.com via HTTP; Tue, 10 Sep 2013 15:42:16 PDT X-Rocket-MIMEInfo: 002.001, TkZTIGhhcyBiZWVuIGJyb2tlbiBzaW5jZSBEYXkgMSwgc28gbGV0cyBub3QgY29tZSB0byBjb25jbHVzaW9ucyBhYm91dCBhbnl0aGluZwphcyBpdCByZWxhdGVzIHRvIE5GUy4KCkJDCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KIEZyb206IE1pa2UgVGFuY3NhIDxtaWtlQHNlbnRleC5uZXQ.ClRvOiBSaWNrIE1hY2tsZW0gPHJtYWNrbGVtQHVvZ3VlbHBoLmNhPiAKQ2M6IEZyZWVCU0QgTmV0IDxuZXRAZnJlZWJzZC5vcmc.OyBEYXZpZCBXb2xmc2tpbGwgPGRhdmlkQGNhdHdoaXNrZXIub3IBMAEBAQE- X-Mailer: YahooMailWebService/0.8.156.576 References: <979862494.17918795.1378299005617.JavaMail.root@uoguelph.ca> <52275136.1010105@sentex.net> Message-ID: <1378852936.95477.YahooMailNeo@web121601.mail.ne1.yahoo.com> Date: Tue, 10 Sep 2013 15:42:16 -0700 (PDT) From: Barney Cordoba Subject: Re: TSO help or hindrance ? (was Re: TSO and FreeBSD vs Linux) To: Mike Tancsa , Rick Macklem In-Reply-To: <52275136.1010105@sentex.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: David Wolfskill , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Barney Cordoba List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 22:42:23 -0000 NFS has been broken since Day 1, so lets not come to conclusions about anyt= hing=0Aas it relates to NFS.=0A=0ABC=0A=0A=0A______________________________= __=0A From: Mike Tancsa =0ATo: Rick Macklem =0ACc: FreeBSD Net ; David Wolfskill =0ASent: Wednesday, September 4, 2013 11:26 AM=0ASubject: TSO he= lp or hindrance ? (was Re: TSO and FreeBSD vs Linux)=0A =0A=0AOn 9/4/2013 = 8:50 AM, Rick Macklem wrote:=0A> David Wolfskill wrote:=0A>>=0A>>=0A>> I no= ticed that when I tried to write files to NFS, I could write=0A>> small=0A>= > files OK, but larger ones seemed to ... hang.=0A>> * "ifconfig -v em0" sh= owed flags TSO4 & VLAN_HWTSO turned on.=0A>> * "sysctl net.inet.tcp.tso" sh= owed "1" -- enabled.=0A>>=0A>> As soon as I issued "sudo net.inet.tcp.tso= =3D0" ... the copy worked=0A>> without=0A>> a hitch or a whine.=A0 And I wa= s able to copy all 117709618 bytes, not=0A>> just=0A>> 2097152 (2^21).=0A>>= =0A>> Is the above expected?=A0 It came rather as a surprise to me.=0A>>=0A= > Not surprising to me, I'm afraid. When there are serious NFS problems=0A>= like this, it is often caused by a network fabric issue and broken=0A> TSO= is at the top of the list w.r.t. cause.=0A=0A=0AI was just experimenting a= bit with iSCSI via FreeNAS and was a little=0Adisappointed at the speeds I= was getting. So, I tried disabling tso on=0Aboth boxes and it did seem to = speed things up a bit.=A0 Data and testing=0Amethods attached in a txt file= .=0A=0AI did 3 cases.=0A=0AJust boot up FreeNAS and the initiator without t= weaks.=A0 That had the=0Aworst performance.=0Adisable tso on the nic as wel= l as via sysctl on both boxes. That had the=0Abest performance.=0Are-enable= tso on both boxes. That had better performance than the first=0Acase, but = still not as good as totally disabling it.=A0 I am guessing=0Asomething is = not quite being re-enabled properly ? But its different=0Athan the other tw= o cases ?!?=0A=0Atgt is FreeNAS-9.1.1-RELEASE-x64 (a752d35) and initiator i= s r254328 9.2=0AAMD64=0A=0AThe FreeNAS box has 16G of RAM, so the file is b= eing served out of cache=0Aas gstat shows no activity when sending out the = file=0A=0A=0A=0A=A0=A0=A0 ---Mike=0A=0A=0A-- =0A-------------------=0AMike = Tancsa, tel +1 519 651 3400=0ASentex Communications, mike@sentex.net=0AProv= iding Internet services since 1994 www.sentex.net=0ACambridge, Ontario Cana= da=A0 http://www.tancsa.com/=0A=0A_________________________________________= ______=0Afreebsd-net@freebsd.org mailing list=0Ahttp://lists.freebsd.org/ma= ilman/listinfo/freebsd-net=0ATo unsubscribe, send any mail to "freebsd-net-= unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Sep 10 22:54:34 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6C09DABB for ; Tue, 10 Sep 2013 22:54:34 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2A593248F for ; Tue, 10 Sep 2013 22:54:34 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.7/8.14.7) with ESMTP id r8AMqvPS032514; Tue, 10 Sep 2013 18:52:57 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <522FA2C3.7010109@sentex.net> Date: Tue, 10 Sep 2013 18:52:51 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Barney Cordoba Subject: Re: TSO help or hindrance ? (was Re: TSO and FreeBSD vs Linux) References: <979862494.17918795.1378299005617.JavaMail.root@uoguelph.ca> <52275136.1010105@sentex.net> <1378852936.95477.YahooMailNeo@web121601.mail.ne1.yahoo.com> In-Reply-To: <1378852936.95477.YahooMailNeo@web121601.mail.ne1.yahoo.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 on 64.7.153.18 Cc: David Wolfskill , Rick Macklem , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 22:54:34 -0000 On 9/10/2013 6:42 PM, Barney Cordoba wrote: > NFS has been broken since Day 1, so lets not come to conclusions about > anything > as it relates to NFS. iSCSI is NFS ? ---Mike > > BC > > ------------------------------------------------------------------------ > *From:* Mike Tancsa > *To:* Rick Macklem > *Cc:* FreeBSD Net ; David Wolfskill > *Sent:* Wednesday, September 4, 2013 11:26 AM > *Subject:* TSO help or hindrance ? (was Re: TSO and FreeBSD vs Linux) > > On 9/4/2013 8:50 AM, Rick Macklem wrote: >> David Wolfskill wrote: >>> >>> >>> I noticed that when I tried to write files to NFS, I could write >>> small >>> files OK, but larger ones seemed to ... hang. >>> * "ifconfig -v em0" showed flags TSO4 & VLAN_HWTSO turned on. >>> * "sysctl net.inet.tcp.tso" showed "1" -- enabled. >>> >>> As soon as I issued "sudo net.inet.tcp.tso=0" ... the copy worked >>> without >>> a hitch or a whine. And I was able to copy all 117709618 bytes, not >>> just >>> 2097152 (2^21). >>> >>> Is the above expected? It came rather as a surprise to me. >>> >> Not surprising to me, I'm afraid. When there are serious NFS problems >> like this, it is often caused by a network fabric issue and broken >> TSO is at the top of the list w.r.t. cause. > > > I was just experimenting a bit with iSCSI via FreeNAS and was a little > disappointed at the speeds I was getting. So, I tried disabling tso on > both boxes and it did seem to speed things up a bit. Data and testing > methods attached in a txt file. > > I did 3 cases. > > Just boot up FreeNAS and the initiator without tweaks. That had the > worst performance. > disable tso on the nic as well as via sysctl on both boxes. That had the > best performance. > re-enable tso on both boxes. That had better performance than the first > case, but still not as good as totally disabling it. I am guessing > something is not quite being re-enabled properly ? But its different > than the other two cases ?!? > > tgt is FreeNAS-9.1.1-RELEASE-x64 (a752d35) and initiator is r254328 9.2 > AMD64 > > The FreeNAS box has 16G of RAM, so the file is being served out of cache > as gstat shows no activity when sending out the file > > > > ---Mike > > > -- > ------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet services since 1994 www.sentex.net > Cambridge, Ontario Canada http://www.tancsa.com/ > > _______________________________________________ > 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 > " > -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Tue Sep 10 23:04:10 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AFBB3C57 for ; Tue, 10 Sep 2013 23:04:10 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 741692524 for ; Tue, 10 Sep 2013 23:04:10 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4MAAWkL1KDaFve/2dsb2JhbABYA4FxBoFIUYMqvzaBO3SCJQEBAQQBAQEgJgUYCAsbBwoEAQEBAgINFgMCKQEJFQkIBggHBAEcBIdhDLEUkgeBKYx5gQUkEAcRgliBNAOVLYN4kDyDPCAygQM5 X-IronPort-AV: E=Sophos;i="4.90,881,1371096000"; d="scan'208";a="51854391" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 10 Sep 2013 19:04:03 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 4096EB3F14; Tue, 10 Sep 2013 19:04:03 -0400 (EDT) Date: Tue, 10 Sep 2013 19:04:03 -0400 (EDT) From: Rick Macklem To: Mike Tancsa Message-ID: <332980519.21486297.1378854243253.JavaMail.root@uoguelph.ca> In-Reply-To: <522FA2C3.7010109@sentex.net> Subject: Re: TSO help or hindrance ? (was Re: TSO and FreeBSD vs Linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: Barney Cordoba , David Wolfskill , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 23:04:10 -0000 Mike Tancsa wrote: > On 9/10/2013 6:42 PM, Barney Cordoba wrote: > > NFS has been broken since Day 1, so lets not come to conclusions > > about > > anything > > as it relates to NFS. > > iSCSI is NFS ? > It would be really nice if you could try trasz`s new iSCSI stack and see how well it works. (I, for one, am hoping it makes it into 10.0, but it may be too late.) rick > ---Mike > > > > > BC > > > > ------------------------------------------------------------------------ > > *From:* Mike Tancsa > > *To:* Rick Macklem > > *Cc:* FreeBSD Net ; David Wolfskill > > > > *Sent:* Wednesday, September 4, 2013 11:26 AM > > *Subject:* TSO help or hindrance ? (was Re: TSO and FreeBSD vs > > Linux) > > > > On 9/4/2013 8:50 AM, Rick Macklem wrote: > >> David Wolfskill wrote: > >>> > >>> > >>> I noticed that when I tried to write files to NFS, I could write > >>> small > >>> files OK, but larger ones seemed to ... hang. > >>> * "ifconfig -v em0" showed flags TSO4 & VLAN_HWTSO turned on. > >>> * "sysctl net.inet.tcp.tso" showed "1" -- enabled. > >>> > >>> As soon as I issued "sudo net.inet.tcp.tso=0" ... the copy worked > >>> without > >>> a hitch or a whine. And I was able to copy all 117709618 bytes, > >>> not > >>> just > >>> 2097152 (2^21). > >>> > >>> Is the above expected? It came rather as a surprise to me. > >>> > >> Not surprising to me, I'm afraid. When there are serious NFS > >> problems > >> like this, it is often caused by a network fabric issue and broken > >> TSO is at the top of the list w.r.t. cause. > > > > > > I was just experimenting a bit with iSCSI via FreeNAS and was a > > little > > disappointed at the speeds I was getting. So, I tried disabling tso > > on > > both boxes and it did seem to speed things up a bit. Data and > > testing > > methods attached in a txt file. > > > > I did 3 cases. > > > > Just boot up FreeNAS and the initiator without tweaks. That had > > the > > worst performance. > > disable tso on the nic as well as via sysctl on both boxes. That > > had the > > best performance. > > re-enable tso on both boxes. That had better performance than the > > first > > case, but still not as good as totally disabling it. I am guessing > > something is not quite being re-enabled properly ? But its > > different > > than the other two cases ?!? > > > > tgt is FreeNAS-9.1.1-RELEASE-x64 (a752d35) and initiator is r254328 > > 9.2 > > AMD64 > > > > The FreeNAS box has 16G of RAM, so the file is being served out of > > cache > > as gstat shows no activity when sending out the file > > > > > > > > ---Mike > > > > > > -- > > ------------------- > > Mike Tancsa, tel +1 519 651 3400 > > Sentex Communications, mike@sentex.net > > Providing Internet services since 1994 www.sentex.net > > Cambridge, Ontario Canada http://www.tancsa.com/ > > > > _______________________________________________ > > 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 > > " > > > > > -- > ------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet services since 1994 www.sentex.net > Cambridge, Ontario Canada http://www.tancsa.com/ > From owner-freebsd-net@FreeBSD.ORG Tue Sep 10 23:12:02 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 262287C for ; Tue, 10 Sep 2013 23:12:02 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E44B225A3 for ; Tue, 10 Sep 2013 23:12:01 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.7/8.14.7) with ESMTP id r8ANBXVf034412; Tue, 10 Sep 2013 19:11:33 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <522FA71F.4000400@sentex.net> Date: Tue, 10 Sep 2013 19:11:27 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Rick Macklem Subject: Re: TSO help or hindrance ? (was Re: TSO and FreeBSD vs Linux) References: <332980519.21486297.1378854243253.JavaMail.root@uoguelph.ca> In-Reply-To: <332980519.21486297.1378854243253.JavaMail.root@uoguelph.ca> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 on 64.7.153.18 Cc: Barney Cordoba , David Wolfskill , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 23:12:02 -0000 On 9/10/2013 7:04 PM, Rick Macklem wrote: > Mike Tancsa wrote: >> On 9/10/2013 6:42 PM, Barney Cordoba wrote: >>> NFS has been broken since Day 1, so lets not come to conclusions >>> about >>> anything >>> as it relates to NFS. >> >> iSCSI is NFS ? >> > It would be really nice if you could try trasz`s new iSCSI stack and > see how well it works. (I, for one, am hoping it makes it into 10.0, > but it may be too late.) I was only doing limited testing of iSCSI both as target and initiator. I was a little disappointed at the slow speeds I was getting. Noticing the thread about TSO, I thought it would be interesting to test and sure enough it did make a difference. IIRC, the new iSCSI stack is currently tested more for correctness than performance? ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Tue Sep 10 23:31:53 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 20C075F4 for ; Tue, 10 Sep 2013 23:31:53 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from winston.madpilot.net (winston.madpilot.net [78.47.75.155]) by mx1.freebsd.org (Postfix) with ESMTP id 86781269D for ; Tue, 10 Sep 2013 23:31:52 +0000 (UTC) Received: from winston.madpilot.net (localhost [127.0.0.1]) by winston.madpilot.net (Postfix) with ESMTP id 3cZMvq4Z6NzFTsN; Wed, 11 Sep 2013 01:31:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at madpilot.net Received: from winston.madpilot.net ([127.0.0.1]) by winston.madpilot.net (winston.madpilot.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXv5DvwOZk3t; Wed, 11 Sep 2013 01:31:49 +0200 (CEST) Received: from tommy.madpilot.net (micro.madpilot.net [88.149.173.206]) by winston.madpilot.net (Postfix) with ESMTPSA; Wed, 11 Sep 2013 01:31:49 +0200 (CEST) Message-ID: <522FABE5.4090805@madpilot.net> Date: Wed, 11 Sep 2013 01:31:49 +0200 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130903 Thunderbird/17.0.8 MIME-Version: 1.0 To: pyunyh@gmail.com Subject: Re: re0 not working at boot on -CURRENT References: <51DC726D.6040601@madpilot.net> <20130710070431.GE2753@michelle.cdnetworks.com> <51DD9E15.7070609@madpilot.net> <20130906061521.GB3070@michelle.cdnetworks.com> <522A3E50.8080801@madpilot.net> <20130910021502.GA2962@michelle.cdnetworks.com> In-Reply-To: <20130910021502.GA2962@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 23:31:53 -0000 On 09/10/13 04:15, Yonghyeon PYUN wrote: > On Fri, Sep 06, 2013 at 10:42:56PM +0200, Guido Falsi wrote: >> On 09/06/13 08:15, Yonghyeon PYUN wrote: >>> On Wed, Jul 10, 2013 at 07:47:01PM +0200, Guido Falsi wrote: >>>> On 07/10/13 09:04, Yonghyeon PYUN wrote: >>>>> On Tue, Jul 09, 2013 at 10:28:29PM +0200, Guido Falsi wrote: >>>>>> Hi, >>>>>> >>>>>> I have a PC with an integrate re ethernet interface, pciconf identifies >>>>>> it like this: >>>>>> >>>>>> re0@pci0:3:0:0: class=0x020000 card=0x11c01734 chip=0x816810ec rev=0x07 >>>>>> hdr=0x00 >>>>>> >>>>>> I'm running FreeBSD current r252261. >>>>>> >>>>>> As stated in the subject after boot the interface does not work >>>>>> correctly. >>>>>> >>>>>> Using tcpdump on another host I noticed that packets (ICMP echo requests >>>>>> for example) do get sent, and replies generated by the other host, but >>>>>> the kernel does not seem to see them. Except that every now and then >>>>>> some packet does get to the system. >>>>>> >>>>>> I'm seeing packet 7, 27, 47, 66, 86, 106, 125, 144, 164, 183 and so on >>>>> >from a ping which has been running for some time. Just about one every >>>>>> twenty. Some pattern is showing up. >>>>>> >>>>>> this is the output of ifconfig re0 after boot: >>>>>> >>>>>> re0: flags=8843 metric 0 mtu >>>>>> 1500 >>>>>> >>>>>> options=8209b >>>>>> ether 00:19:99:f8:d3:0b >>>>>> inet 172.24.42.13 netmask 0xffffff00 broadcast 172.24.42.255 >>>>>> inet6 fe80::219:99ff:fef8:d30b%re0 prefixlen 64 scopeid 0x2 >>>>>> nd6 options=29 >>>>>> media: Ethernet autoselect (100baseTX ) >>>>>> status: active >>>>>> >>>>>> If I just touch any interface flag with ifconfig, anyone, tso, -txcsum >>>>>> -rxcsum, it starts working flawlessly. It keeps working also if I >>>>>> perform the opposite operation with ifconfig afterwards, so it is not >>>>>> the flag itself fixing it. >>>>>> >>>>>> This is an ifconfig after performing this exercise(it's the same, since >>>>>> I disabled txcsum and reactivated it in this instance): >>>>>> >>>>>> re0: flags=8843 metric 0 mtu >>>>>> 1500 >>>>>> >>>>>> options=8209b >>>>>> ether 00:19:99:f8:d3:0b >>>>>> inet 172.24.42.13 netmask 0xffffff00 broadcast 172.24.42.255 >>>>>> inet6 fe80::219:99ff:fef8:d30b%re0 prefixlen 64 scopeid 0x2 >>>>>> nd6 options=29 >>>>>> media: Ethernet autoselect (100baseTX ) >>>>>> status: active >>>>>> >>>>>> I don't know much about FreeBSD network drivers so i can't make theories >>>>>> about this. I hope someone has an idea what the problem could be. >>>>>> >>>>>> I'm available for any further information needed, test, experiment and >>>>>> so on. >>>>> >>>>> Could you show me dmesg output(re(4) and rgephy(4) only)? >>>> >>>> re0: port >>>> 0xd000-0xd0ff mem 0xf2104000-0xf2104fff,0xf2100000-0xf2103fff irq 17 at >>>> device 0.0 on pci3 >>>> re0: Using 1 MSI-X message >>>> re0: turning off MSI enable bit. >>>> re0: Chip rev. 0x2c800000 >>>> re0: MAC rev. 0x00000000 >>>> re0: Ethernet address: 00:19:99:f8:d3:0b >>>> miibus0: on re0 >>>> rgephy0: PHY 1 on miibus0 >>>> rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, >>>> 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, >>>> 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, >>>> 1000baseT-FDX-flow-master, auto, auto-flow >>>> >>>> Also, I'm loading this as a module, but, for as much as I know, this >>>> should not make any difference. >>>> >>>> >>>>> Did it ever work or you see the issue only on CURRENT? >>>> >>>> Never worked on this machine (I own it since the last days of February). >>>> >>>> I only installed current on it. If needed I can find time to test a >>>> recent 9.x snapshot on it. >>>> >>>> I worked around the problem till now using an USB ethernet adapter, >>>> always wanted to report this problem, but I've been lazy :) >>>> >>> >>> Would you try attached patch and let me know whether it makes any >>> difference? >>> >> >> Hi! >> >> Thanks for looking into this and sorry for the delay in reporting back. >> >> Unluckily the patch does not solve nor mitigates the problem. Symptoms >> are very similar. > > [...] > >> Only real difference is the re_eri_read timeout. It did not output that >> error message before. > > Oops, sorry. It seems there is logic error in the diff. > Try attached one again. > Hi, This patch shows the same behavior as the unpatched kernel: root@marvin:~ [1]# ping 172.24.42.1 PING 172.24.42.1 (172.24.42.1): 56 data bytes 64 bytes from 172.24.42.1: icmp_seq=3 ttl=64 time=0.569 ms 64 bytes from 172.24.42.1: icmp_seq=19 ttl=64 time=0.465 ms ^C --- 172.24.42.1 ping statistics --- 35 packets transmitted, 2 packets received, 94.3% packet loss round-trip min/avg/max/stddev = 0.465/0.517/0.569/0.052 ms root@marvin:~ [0]# ifconfig re0 tso root@marvin:~ [0]# ping 172.24.42.1 PING 172.24.42.1 (172.24.42.1): 56 data bytes ping: sendto: No route to host 64 bytes from 172.24.42.1: icmp_seq=1 ttl=64 time=0.949 ms 64 bytes from 172.24.42.1: icmp_seq=2 ttl=64 time=0.726 ms 64 bytes from 172.24.42.1: icmp_seq=3 ttl=64 time=0.793 ms 64 bytes from 172.24.42.1: icmp_seq=4 ttl=64 time=0.624 ms 64 bytes from 172.24.42.1: icmp_seq=5 ttl=64 time=0.736 ms 64 bytes from 172.24.42.1: icmp_seq=6 ttl=64 time=0.923 ms ^C --- 172.24.42.1 ping statistics --- 7 packets transmitted, 6 packets received, 14.3% packet loss round-trip min/avg/max/stddev = 0.624/0.792/0.949/0.114 ms I'd like to note that if I perform a tcpdump from the other machine (which is also the dns server) I do see the packets getting out as usual from this machine, and replies being sent. So the problem seems to be to receive packets, while sending them works fine. -- Guido Falsi From owner-freebsd-net@FreeBSD.ORG Tue Sep 10 23:40:03 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7AF88734 for ; Tue, 10 Sep 2013 23:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4FA5C26F0 for ; Tue, 10 Sep 2013 23:40:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r8ANe2dk061490 for ; Tue, 10 Sep 2013 23:40:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r8ANe2YD061489; Tue, 10 Sep 2013 23:40:02 GMT (envelope-from gnats) Date: Tue, 10 Sep 2013 23:40:02 GMT Message-Id: <201309102340.r8ANe2YD061489@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: "Neel Chauhan" Subject: Re: kern/181703: [re] [patch] Fix Realtek 8111G Ethernet controller not being detected X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Neel Chauhan List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 23:40:03 -0000 The following reply was made to PR kern/181703; it has been noted by GNATS. From: "Neel Chauhan" To: bug-followup@FreeBSD.org, neel@neelc.org Cc: Subject: Re: kern/181703: [re] [patch] Fix Realtek 8111G Ethernet controller not being detected Date: Tue, 10 Sep 2013 19:26:23 -0400 Update: I tested the patch. It just makes the ethernet controller useless until you unplug your computer. From owner-freebsd-net@FreeBSD.ORG Wed Sep 11 00:15:23 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 943E0C79 for ; Wed, 11 Sep 2013 00:15:23 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6BC35289B for ; Wed, 11 Sep 2013 00:15:23 +0000 (UTC) Received: by mail-pb0-f48.google.com with SMTP id ma3so8237583pbc.21 for ; Tue, 10 Sep 2013 17:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=PBDEFNrtROrGaNsjNtzi/2ronA1zEZ/BEfhK/0Y53IQ=; b=rPuhILDjSVKWqWmkJMmFZ0/1EpnxTFAfe8IwGhCLCH70AV6z8Ebz+A29aFNEvfF53z QSxv9KzZvfU4oZD1XbQDSWeW9w6BME5eiRwIU22Tb8n/d+ZwezThMsk4OrvdedF/0MKa LZ1pTbEcv3ZI2qQ/LAHK81FYLBfnw/xUTBmUsNQnXYvZA74b/B6DMQ/X2MKeZQadAkH9 +6wLnr+slwx4h7UmaPwDJrhvCMzXch+DHmDj+LasE9I+MbvObzspuVcsX5Fr2tjeSnq4 lo94W63ZyfvymmSopKm4DWVSNeA1D1xO4RXW2JkGydfvyerAYanW1ryafTKuj0+Cg8UI rcVg== X-Received: by 10.66.150.69 with SMTP id ug5mr468163pab.55.1378858522997; Tue, 10 Sep 2013 17:15:22 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id qf7sm27660758pac.14.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 10 Sep 2013 17:15:22 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 11 Sep 2013 09:15:15 +0900 From: Yonghyeon PYUN Date: Wed, 11 Sep 2013 09:15:15 +0900 To: Guido Falsi Subject: Re: re0 not working at boot on -CURRENT Message-ID: <20130911001515.GA3145@michelle.cdnetworks.com> References: <51DC726D.6040601@madpilot.net> <20130710070431.GE2753@michelle.cdnetworks.com> <51DD9E15.7070609@madpilot.net> <20130906061521.GB3070@michelle.cdnetworks.com> <522A3E50.8080801@madpilot.net> <20130910021502.GA2962@michelle.cdnetworks.com> <522FABE5.4090805@madpilot.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <522FABE5.4090805@madpilot.net> 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: Wed, 11 Sep 2013 00:15:23 -0000 On Wed, Sep 11, 2013 at 01:31:49AM +0200, Guido Falsi wrote: > On 09/10/13 04:15, Yonghyeon PYUN wrote: > >On Fri, Sep 06, 2013 at 10:42:56PM +0200, Guido Falsi wrote: > >>On 09/06/13 08:15, Yonghyeon PYUN wrote: > >>>On Wed, Jul 10, 2013 at 07:47:01PM +0200, Guido Falsi wrote: > >>>>On 07/10/13 09:04, Yonghyeon PYUN wrote: > >>>>>On Tue, Jul 09, 2013 at 10:28:29PM +0200, Guido Falsi wrote: > >>>>>>Hi, > >>>>>> > >>>>>>I have a PC with an integrate re ethernet interface, pciconf > >>>>>>identifies > >>>>>>it like this: > >>>>>> > >>>>>>re0@pci0:3:0:0: class=0x020000 card=0x11c01734 chip=0x816810ec > >>>>>>rev=0x07 > >>>>>>hdr=0x00 > >>>>>> > >>>>>>I'm running FreeBSD current r252261. > >>>>>> > >>>>>>As stated in the subject after boot the interface does not work > >>>>>>correctly. > >>>>>> > >>>>>>Using tcpdump on another host I noticed that packets (ICMP echo > >>>>>>requests > >>>>>>for example) do get sent, and replies generated by the other host, but > >>>>>>the kernel does not seem to see them. Except that every now and then > >>>>>>some packet does get to the system. > >>>>>> > >>>>>>I'm seeing packet 7, 27, 47, 66, 86, 106, 125, 144, 164, 183 and so on > >>>>>>from a ping which has been running for some time. Just about one every > >>>>>>twenty. Some pattern is showing up. > >>>>>> > >>>>>>this is the output of ifconfig re0 after boot: > >>>>>> > >>>>>>re0: flags=8843 metric 0 mtu > >>>>>>1500 > >>>>>> > >>>>>>options=8209b > >>>>>> ether 00:19:99:f8:d3:0b > >>>>>> inet 172.24.42.13 netmask 0xffffff00 broadcast 172.24.42.255 > >>>>>> inet6 fe80::219:99ff:fef8:d30b%re0 prefixlen 64 scopeid 0x2 > >>>>>> nd6 options=29 > >>>>>> media: Ethernet autoselect (100baseTX ) > >>>>>> status: active > >>>>>> > >>>>>>If I just touch any interface flag with ifconfig, anyone, tso, -txcsum > >>>>>>-rxcsum, it starts working flawlessly. It keeps working also if I > >>>>>>perform the opposite operation with ifconfig afterwards, so it is not > >>>>>>the flag itself fixing it. > >>>>>> > >>>>>>This is an ifconfig after performing this exercise(it's the same, > >>>>>>since > >>>>>>I disabled txcsum and reactivated it in this instance): > >>>>>> > >>>>>>re0: flags=8843 metric 0 mtu > >>>>>>1500 > >>>>>> > >>>>>>options=8209b > >>>>>> ether 00:19:99:f8:d3:0b > >>>>>> inet 172.24.42.13 netmask 0xffffff00 broadcast 172.24.42.255 > >>>>>> inet6 fe80::219:99ff:fef8:d30b%re0 prefixlen 64 scopeid 0x2 > >>>>>> nd6 options=29 > >>>>>> media: Ethernet autoselect (100baseTX ) > >>>>>> status: active > >>>>>> > >>>>>>I don't know much about FreeBSD network drivers so i can't make > >>>>>>theories > >>>>>>about this. I hope someone has an idea what the problem could be. > >>>>>> > >>>>>>I'm available for any further information needed, test, experiment and > >>>>>>so on. > >>>>> > >>>>>Could you show me dmesg output(re(4) and rgephy(4) only)? > >>>> > >>>>re0: port > >>>>0xd000-0xd0ff mem 0xf2104000-0xf2104fff,0xf2100000-0xf2103fff irq 17 at > >>>>device 0.0 on pci3 > >>>>re0: Using 1 MSI-X message > >>>>re0: turning off MSI enable bit. > >>>>re0: Chip rev. 0x2c800000 > >>>>re0: MAC rev. 0x00000000 > >>>>re0: Ethernet address: 00:19:99:f8:d3:0b > >>>>miibus0: on re0 > >>>>rgephy0: PHY 1 on > >>>>miibus0 > >>>>rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, > >>>>100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, > >>>>1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, > >>>>1000baseT-FDX-flow-master, auto, auto-flow > >>>> > >>>>Also, I'm loading this as a module, but, for as much as I know, this > >>>>should not make any difference. > >>>> > >>>> > >>>>>Did it ever work or you see the issue only on CURRENT? > >>>> > >>>>Never worked on this machine (I own it since the last days of February). > >>>> > >>>>I only installed current on it. If needed I can find time to test a > >>>>recent 9.x snapshot on it. > >>>> > >>>>I worked around the problem till now using an USB ethernet adapter, > >>>>always wanted to report this problem, but I've been lazy :) > >>>> > >>> > >>>Would you try attached patch and let me know whether it makes any > >>>difference? > >>> > >> > >>Hi! > >> > >>Thanks for looking into this and sorry for the delay in reporting back. > >> > >>Unluckily the patch does not solve nor mitigates the problem. Symptoms > >>are very similar. > > > >[...] > > > >>Only real difference is the re_eri_read timeout. It did not output that > >>error message before. > > > >Oops, sorry. It seems there is logic error in the diff. > >Try attached one again. > > > > Hi, > > This patch shows the same behavior as the unpatched kernel: [...] > I'd like to note that if I perform a tcpdump from the other machine > (which is also the dns server) I do see the packets getting out as usual > from this machine, and replies being sent. So the problem seems to be to > receive packets, while sending them works fine. Hmm, I thought the diff may reset internal RX filter but it seems it has no effect. If I find a clue I'll let you know. BTW, I guess the diff have showed IC revision of MAC. Could you show me the output of driver? Thanks for testing! From owner-freebsd-net@FreeBSD.ORG Wed Sep 11 07:44:35 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 77FC16A3 for ; Wed, 11 Sep 2013 07:44:35 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from winston.madpilot.net (winston.madpilot.net [78.47.75.155]) by mx1.freebsd.org (Postfix) with ESMTP id 32C222AEB for ; Wed, 11 Sep 2013 07:44:34 +0000 (UTC) Received: from winston.madpilot.net (localhost [127.0.0.1]) by winston.madpilot.net (Postfix) with ESMTP id 3cZZrD0XyszFTsM; Wed, 11 Sep 2013 09:44:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at madpilot.net Received: from winston.madpilot.net ([127.0.0.1]) by winston.madpilot.net (winston.madpilot.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoTEZ_y8YfwL; Wed, 11 Sep 2013 09:44:26 +0200 (CEST) Received: from vwg82.hq.ignesti.it (unknown [77.246.14.163]) by winston.madpilot.net (Postfix) with ESMTPSA; Wed, 11 Sep 2013 09:44:26 +0200 (CEST) Message-ID: <52301F56.4070805@madpilot.net> Date: Wed, 11 Sep 2013 09:44:22 +0200 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130904 Thunderbird/17.0.8 MIME-Version: 1.0 To: pyunyh@gmail.com Subject: Re: re0 not working at boot on -CURRENT References: <51DC726D.6040601@madpilot.net> <20130710070431.GE2753@michelle.cdnetworks.com> <51DD9E15.7070609@madpilot.net> <20130906061521.GB3070@michelle.cdnetworks.com> <522A3E50.8080801@madpilot.net> <20130910021502.GA2962@michelle.cdnetworks.com> <522FABE5.4090805@madpilot.net> <20130911001515.GA3145@michelle.cdnetworks.com> In-Reply-To: <20130911001515.GA3145@michelle.cdnetworks.com> Content-Type: text/plain; charset=us-ascii; 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: Wed, 11 Sep 2013 07:44:35 -0000 On 09/11/13 02:15, Yonghyeon PYUN wrote: > On Wed, Sep 11, 2013 at 01:31:49AM +0200, Guido Falsi wrote: >> Hi, >> >> This patch shows the same behavior as the unpatched kernel: > > [...] > >> I'd like to note that if I perform a tcpdump from the other machine >> (which is also the dns server) I do see the packets getting out as usual >> from this machine, and replies being sent. So the problem seems to be to >> receive packets, while sending them works fine. > > Hmm, I thought the diff may reset internal RX filter but it seems > it has no effect. If I find a clue I'll let you know. > BTW, I guess the diff have showed IC revision of MAC. Could you > show me the output of driver? > Thanks for testing! > re0: port 0xd000-0xd0ff mem 0xf2104000-0xf2104fff,0xf2100000-0xf2103fff irq 17 at device 0.0 on pci3 re0: Using 1 MSI-X message re0: Chip rev. 0x2c800000 re0: IC rev. 0x00100000 re0: MAC rev. 0x00000000 re0: Ethernet address: 00:19:99:f8:d3:0b miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow -- Guido Falsi From owner-freebsd-net@FreeBSD.ORG Wed Sep 11 11:26:45 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 787FDD8C for ; Wed, 11 Sep 2013 11:26:45 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4EF1E241F for ; Wed, 11 Sep 2013 11:26:44 +0000 (UTC) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 26537239C6 for ; Wed, 11 Sep 2013 07:26:43 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute5.internal (MEProxy); Wed, 11 Sep 2013 07:26:43 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date:in-reply-to :references; s=smtpout; bh=bmy07s4vihHY3BfBZyMMIoCjjPk=; b=gKXJu DSjxbpEeWLlKhxDHVR6VPSxrk98E3m7Sa8bg7rJeuPO09o1/uk0ZU/lAZvPS+dis G80q8JfzpV8GOXVbn4afKLabzdj4U+g34W1ZiDB7rIZHYVZwRpR2VvX0Hy5qA7YF 6UfzkErV6i7pyehe02WMBvzVopirHJN66BoogE= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 03B5CB000CF; Wed, 11 Sep 2013 07:26:42 -0400 (EDT) Message-Id: <1378898802.7360.20611953.59A82CBA@webmail.messagingengine.com> X-Sasl-Enc: fkF8GqZQE9XKKHOqcb/f6E1wAzOkuvjgy9y6cPF8fGlb 1378898802 From: Mark Felder To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-15090c31 Subject: Re: TSO help or hindrance ? (was Re: TSO and FreeBSD vs Linux) Date: Wed, 11 Sep 2013 06:26:42 -0500 In-Reply-To: <522FA71F.4000400@sentex.net> References: <332980519.21486297.1378854243253.JavaMail.root@uoguelph.ca> <522FA71F.4000400@sentex.net> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 11:26:45 -0000 On Tue, Sep 10, 2013, at 18:11, Mike Tancsa wrote: > > IIRC, the new iSCSI stack is currently tested more for correctness than > performance? > Yes, but it's in the kernel vs istgt which is all userland code. It could very well be faster. I'm quite interested in seeing someone put up some serious benchmarks. From owner-freebsd-net@FreeBSD.ORG Wed Sep 11 14:54:22 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 12E1D18C; Wed, 11 Sep 2013 14:54:22 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9274C211D; Wed, 11 Sep 2013 14:54:20 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id r8BEsJTk050873; Wed, 11 Sep 2013 18:54:19 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id r8BEsJTp050872; Wed, 11 Sep 2013 18:54:19 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 11 Sep 2013 18:54:18 +0400 From: Gleb Smirnoff To: Navdeep Parhar Subject: Re: Please review: atomic updates to mbuf's external refcount Message-ID: <20130911145418.GN4574@FreeBSD.org> References: <521FA792.9000807@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <521FA792.9000807@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 14:54:22 -0000 On Thu, Aug 29, 2013 at 12:57:06PM -0700, Navdeep Parhar wrote: N> I'd like to merge r254341 from user/np/cxl_tuning to head if there are N> no objections. It eliminates a couple of iffy looking constructs in N> uipc_mbuf.c N> N> http://svnweb.freebsd.org/base/user/np/cxl_tuning/sys/kern/uipc_mbuf.c?r1=254334&r2=254341&diff_format=u N> N> --------------------- N> Always increment or decrement an mbuf's external refcount atomically. N> Always decrement it in mb_free_ext() so that an external free routine N> can safely assert the refcount is 0 (and not 0 or 1) when it's called. N> --------------------- I'd like to second on this patch. The "iffy looking constructs" do not work if we break assumption that the mbuf is the only way to find a refcount for an external storage. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Wed Sep 11 15:10:46 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4931CC13 for ; Wed, 11 Sep 2013 15:10:46 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C88A12282 for ; Wed, 11 Sep 2013 15:10:45 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id r8BFAhqs050959; Wed, 11 Sep 2013 19:10:43 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id r8BFAgUg050958; Wed, 11 Sep 2013 19:10:42 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 11 Sep 2013 19:10:42 +0400 From: Gleb Smirnoff To: Yuri Subject: Re: LOCAL_CREDS are broken ? Message-ID: <20130911151042.GO4574@FreeBSD.org> References: <521F9789.5000903@rawbw.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <521F9789.5000903@rawbw.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 15:10:46 -0000 On Thu, Aug 29, 2013 at 11:48:41AM -0700, Yuri wrote: Y> The example below breaks with "Protocol not available" Y> But what is wrong? Isn't this the correct usage? Y> LOCAL_CREDS are only handled in kern/uipc_usrreq.c for AF_LOCAL, so it Y> isn't clear why this doesn't work. Y> Y> --- example.c --- Y> #include Y> #include Y> #include Y> #include Y> #include Y> Y> main() { Y> int sock; Y> int error; Y> int oval = 1; Y> Y> error = socket(AF_LOCAL, SOCK_SEQPACKET, 0); Y> if (error == -1) {perror("socket"); exit(-1);} Y> sock = error; Y> Y> error = setsockopt(sock, SOL_SOCKET, LOCAL_CREDS, &oval, sizeof(oval)); Y> if (error) {perror("setsockopt"); exit(-1);} Y> } Alfred is right, we should add uipc_ctloutput() as method for SOCK_SEQPACKET on local sockets. But your code actually fails because you request SOL_SOCKET level. LOCAL_CREDS is protocol level option, not socket. socket(AF_LOCAL, SOCK_DGRAM, 0); setsockopt(sock, 0, LOCAL_CREDS, &oval, sizeof(oval)); P.S. I will look at issue with SOCK_SEQPACKET. According to manual page, it should work. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Wed Sep 11 15:18:29 2013 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7DA9AEEC for ; Wed, 11 Sep 2013 15:18:29 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F111022FA for ; Wed, 11 Sep 2013 15:18:28 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id r8BFIQ8q050990; Wed, 11 Sep 2013 19:18:26 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id r8BFIQvM050989; Wed, 11 Sep 2013 19:18:26 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 11 Sep 2013 19:18:26 +0400 From: Gleb Smirnoff To: Yuri Subject: Re: Packet loss when 'control' messages are present with large data (sendmsg(2)) Message-ID: <20130911151826.GP4574@FreeBSD.org> References: <522300E3.6050303@rawbw.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <522300E3.6050303@rawbw.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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: Wed, 11 Sep 2013 15:18:29 -0000 Yuri, On Sun, Sep 01, 2013 at 01:54:59AM -0700, Yuri wrote: Y> I found the case when sendmsg(2) silently loses packets for AF_LOCAL Y> domain when large packets with control part in them are sent. Y> Y> Here is how: Y> There is the watermark limit on sockbuf determined by Y> net.local.stream.sendspace, default is 8192 bytes (field sockbuf.sb_hiwat). Y> When sendmsg(2) sends large enough data (8K+ that hits this 8192 limit) Y> with control message, sosend_generic will be cutting the message data Y> into separate mbufs based on 'sbspace' (derived from the above-mentioned Y> sb_hiwat limit) with adjustment for control message size as it sees it. Y> This way it tries to make sure this sb_hiwat limit is enforced. Y> Y> However, down on uipc level control message is being further modified in Y> two ways: unp_internalize modifies it into some 'internal' form, also Y> unp_addsockcred function adds another control message when LOCAL_CREDS Y> are requested by client. Both functions only increase control message Y> size beyond its original size (seen by sosend_generic). So that the Y> first final mbuf sent (concatenation of control and data) will always be Y> larger than 'sbspace' limit that sosend_generic was cutting data for. Y> Y> There is also the function sbappendcontrol_locked. It checks the Y> 'sbspace' limit again, and discards the packet when sbspace llimit is Y> exceeded. Its result code is essentially ignored in uipc_send. I Y> believe, sbappendcontrol_locked shouldn't be checking space at all, Y> since packets are expected to be properly sized to begin with. But this Y> won't be the right fix, since sizes would be exceeding the sbspace limit Y> anyway. Y> Y> sosend_default is one level up over uipc level, and it doesn't know what Y> uipc will do with control message. Therefore it can't know what the real Y> adjustment for control message is needed (to properly cut data). It Y> wrongly takes the original control size and this makes the first packet Y> too large and discarded by sbappendcontrol_locked. Y> Y> To solve the problem, I propose to add another function into struct Y> pr_usrreqs: Y> int (*pru_finalizecontrol)(struct socket *so, int flags, struct mbuf Y> **pcontrol); Y> Y> This function will be called from sosend_default and sosend_dgram. Y> uipc_finalizecontrol will do the same that unp_internalize and Y> unp_addsockcred do on uipc level, and it will allow sosend_default to Y> see the final version of the control message, and properly split data Y> into pieces when data is large enough to hit the limit. Y> Y> I felt I better discuss such addition to struct pr_usrreqs, because it Y> might seem like an overkill to add this function just to solve this one Y> local issue. But it seems there is no other solution (other than just Y> ignoring the occasionally larger mbuf size). Y> Y> I can easily make a patch fixing this issue with this new function. Thanks for investigation! Can you please send at least a program that is test case for the above problem? A patch that fixes would be also appreciated. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Wed Sep 11 15:43:34 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7B266976 for ; Wed, 11 Sep 2013 15:43:34 +0000 (UTC) (envelope-from mailinglists@martinlaabs.de) Received: from relay02.alfahosting-server.de (relay02.alfahosting-server.de [109.237.142.238]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 38B392499 for ; Wed, 11 Sep 2013 15:43:33 +0000 (UTC) Received: by relay02.alfahosting-server.de (Postfix, from userid 1001) id 370DD32C2223; Wed, 11 Sep 2013 17:43:11 +0200 (CEST) X-Spam-DCC: : X-Spam-Level: X-Spam-Status: No, score=0.0 required=7.0 tests=BAYES_50 autolearn=disabled version=3.2.5 Received: from alfa3018.alfahosting-server.de (alfa3018.alfahosting-server.de [109.237.140.30]) by relay02.alfahosting-server.de (Postfix) with ESMTPS id DFD5632C2223 for ; Wed, 11 Sep 2013 17:43:09 +0200 (CEST) Received: from desktop-01.martinlaabs.de (p54B32073.dip0.t-ipconnect.de [84.179.32.115]) by alfa3018.alfahosting-server.de (Postfix) with ESMTPSA id AEB77515DECA for ; Wed, 11 Sep 2013 17:43:09 +0200 (CEST) Message-ID: <52308F8C.3010804@martinlaabs.de> Date: Wed, 11 Sep 2013 17:43:08 +0200 From: Martin Laabs User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130809 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Kerberos problem with -current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Status: No X-Virus-Checker-Version: clamassassin 1.2.4 with ClamAV 0.97.3/17841/Wed Sep 11 15:45:20 2013 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, 11 Sep 2013 15:43:34 -0000 Hi, I set up a kerberos server on a raspberry platform. To prove that all is working I enabled the telnetd to use kerberos auth. When trying to connect to the localhost or the ip assigned (so just use the -current telnet with the -current telnetd and the -current kerberos server) to the network interface I get the following error: Trying 192.168.1.221... Connected to raspberry.martinlaabs.de. Escape character is '^]'. [ Trying mutual KERBEROS5 (host/raspberry.martinlaabs.de@MARTINLAABS.DE)... ] Kerberos V5: mk_req failed (encryption type des-cbc-crc is disabled) [ Trying KERBEROS5 (host/raspberry.martinlaabs.de@MARTINLAABS.DE)... ] Kerberos V5: mk_req failed (encryption type des-cbc-crc is disabled) This is very strange because there are no des-cbc-crc keys at all and I wonder why telnetd is asking for that deprecated key type. When enabling the weak crypto option in krb5.conf the error message changes but the main problem of the des-cbc-crc key remains: Trying 192.168.1.231... Connected to raspberry.martinlaabs.de. Escape character is '^]'. [ Trying mutual KERBEROS5 (host/raspberry.martinlaabs.de@MARTINLAABS.DE)... ] Kerberos V5: mk_req failed (KDC has no support for encryption type) [ Trying KERBEROS5 (host/raspberry.martinlaabs.de@MARTINLAABS.DE)... ] Kerberos V5: mk_req failed (KDC has no support for encryption type) So why does telnet or telnetd wants to use the des-cbc-crc key type and not some recent and secure key types? Thank you, Martin Laabs From owner-freebsd-net@FreeBSD.ORG Wed Sep 11 17:00: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2997498F; Wed, 11 Sep 2013 17:00:32 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F0F9D28E2; Wed, 11 Sep 2013 17:00:31 +0000 (UTC) Received: by mail-pb0-f43.google.com with SMTP id md4so9295244pbc.2 for ; Wed, 11 Sep 2013 10:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=WPHZ71yEBbSQ9EAJVEeXL+hw2s0+Gxt1HGI1pbv8AaI=; b=C2179KfLe0utG3p+tD324EB799Ye6Coy7EGnQVWFySV+aqYf+l34gd7mGNjvBv0+18 sSh6tqUa/7wlOuB9aSk9x4PQCkyIDArjigIrD1QUlqaRh2oNqeDm/i7T3V36pMOYUx8f y6fP5V9niehSxN3LdaZs7QUyVHnf/61TMX1wncuS8bUdffA0r6io5oyNhtELNvmzMDBq eQ+tqkvxgk6jq08VUKkKmv/nNPZVoJOjbkpJcdpPRgF9YjqChzE8FbhX2ufirSXY9F0m SS4GNz5UUmNMWvkQaGtVyiLH8O0C8x6uPT76Z7jj0ehjhxeXgRDdt7EB1vFRVbjYkE90 MxcA== X-Received: by 10.68.13.3 with SMTP id d3mr3050646pbc.62.1378918831528; Wed, 11 Sep 2013 10:00:31 -0700 (PDT) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPSA id dw3sm5681181pbc.17.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Sep 2013 10:00:30 -0700 (PDT) Sender: Navdeep Parhar Message-ID: <5230A1AC.8020209@FreeBSD.org> Date: Wed, 11 Sep 2013 10:00:28 -0700 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130819 Thunderbird/17.0.8 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: Please review: atomic updates to mbuf's external refcount References: <521FA792.9000807@FreeBSD.org> <20130911145418.GN4574@FreeBSD.org> In-Reply-To: <20130911145418.GN4574@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 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: Wed, 11 Sep 2013 17:00:32 -0000 On 09/11/13 07:54, Gleb Smirnoff wrote: > On Thu, Aug 29, 2013 at 12:57:06PM -0700, Navdeep Parhar wrote: > N> I'd like to merge r254341 from user/np/cxl_tuning to head if there are > N> no objections. It eliminates a couple of iffy looking constructs in > N> uipc_mbuf.c > N> > N> http://svnweb.freebsd.org/base/user/np/cxl_tuning/sys/kern/uipc_mbuf.c?r1=254334&r2=254341&diff_format=u > N> > N> --------------------- > N> Always increment or decrement an mbuf's external refcount atomically. > N> Always decrement it in mb_free_ext() so that an external free routine > N> can safely assert the refcount is 0 (and not 0 or 1) when it's called. > N> --------------------- > > I'd like to second on this patch. > > The "iffy looking constructs" do not work if we break assumption that > the mbuf is the only way to find a refcount for an external storage. > ok, I'll ask re@ to approve this for head. Regards, Navdeep From owner-freebsd-net@FreeBSD.ORG Wed Sep 11 18:23:16 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EE9D3101 for ; Wed, 11 Sep 2013 18:23:16 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 78D3E2E1F for ; Wed, 11 Sep 2013 18:23:15 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id r8BINDiF051824; Wed, 11 Sep 2013 22:23:13 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id r8BINDlF051823; Wed, 11 Sep 2013 22:23:13 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 11 Sep 2013 22:23:12 +0400 From: Gleb Smirnoff To: Yuri Subject: Re: LOCAL_CREDS are broken ? Message-ID: <20130911182312.GU4574@FreeBSD.org> References: <521F9789.5000903@rawbw.com> <20130911151042.GO4574@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130911151042.GO4574@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 18:23:17 -0000 On Wed, Sep 11, 2013 at 07:10:42PM +0400, Gleb Smirnoff wrote: T> On Thu, Aug 29, 2013 at 11:48:41AM -0700, Yuri wrote: T> Y> The example below breaks with "Protocol not available" T> Y> But what is wrong? Isn't this the correct usage? T> Y> LOCAL_CREDS are only handled in kern/uipc_usrreq.c for AF_LOCAL, so it T> Y> isn't clear why this doesn't work. T> Y> T> Y> --- example.c --- T> Y> #include T> Y> #include T> Y> #include T> Y> #include T> Y> #include T> Y> T> Y> main() { T> Y> int sock; T> Y> int error; T> Y> int oval = 1; T> Y> T> Y> error = socket(AF_LOCAL, SOCK_SEQPACKET, 0); T> Y> if (error == -1) {perror("socket"); exit(-1);} T> Y> sock = error; T> Y> T> Y> error = setsockopt(sock, SOL_SOCKET, LOCAL_CREDS, &oval, sizeof(oval)); T> Y> if (error) {perror("setsockopt"); exit(-1);} T> Y> } T> T> Alfred is right, we should add uipc_ctloutput() as method for T> SOCK_SEQPACKET on local sockets. T> T> But your code actually fails because you request SOL_SOCKET T> level. T> T> LOCAL_CREDS is protocol level option, not socket. T> T> socket(AF_LOCAL, SOCK_DGRAM, 0); T> setsockopt(sock, 0, LOCAL_CREDS, &oval, sizeof(oval)); T> T> P.S. I will look at issue with SOCK_SEQPACKET. T> According to manual page, it should work. I've fixed that in head. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri Sep 13 07:42:50 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id ACA17654 for ; Fri, 13 Sep 2013 07:42:50 +0000 (UTC) (envelope-from marek_sal@wp.pl) Received: from mx3.wp.pl (mx3.wp.pl [212.77.101.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2FFD72DBE for ; Fri, 13 Sep 2013 07:42:49 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 20093 invoked from network); 13 Sep 2013 09:42:47 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1379058167; bh=oiAbDm/qY6O0/MehpQAi4XY4llipavgbIbtLNbhbqn0=; h=From:To:CC:Subject; b=H3zJpbP4Sw2oPgdfZ+2NvicYlkDt01zTkAddoY+n7/6zRmS9ww9vV78p3QVqnZwNg 1J7w0imNXH4SSxQ9ea8bKNrOoRokmzIDxehGtc4e+Zi8SNN/W1OW4wfgfgkuZkfo0S B7c9LQRge1V1Eud1y808pCwZDWcnVQRpVGlugjZk= Received: from user-164-126-70-132.play-internet.pl (HELO [192.168.1.112]) (marek_sal@[164.126.70.132]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with CAMELLIA256-SHA encrypted SMTP for ; 13 Sep 2013 09:42:47 +0200 Message-ID: <5232C1F8.1080600@wp.pl> Date: Fri, 13 Sep 2013 09:42:48 +0200 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mark van der Meulen Subject: Re: igb Intel Gigabit Network Connection I350, lagg, vlan - increase mtu References: <522DC6DE.3040908@wp.pl> <522DC7DD.705@wp.pl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-WP-DKIM-Status: good (id: wp.pl) X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [0SOM] Cc: freebsd-net@freebsd.org, Marek Salwerowicz 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, 13 Sep 2013 07:42:50 -0000 W dniu 2013-09-09 15:11, Mark van der Meulen pisze: > As far as I can tell, if you are using the links in a lagg then you are going to need to make the change in /etc/rc.conf and reboot or perhaps restart netif. I recently came across a similar situation where I had to change the MTU across a bunch of different bsdrp boxes running as firewalls and routers and in the end after a lot of research I worked out the only way was either a reboot or possibly a restart of networking. Some machines had Intel(em) and Broadcom(bcd and bge) interfaces. > > I never tried restarting networking as there are a few things on my boxes which that will break so I am better off just rebooting. Hi, after setting up in /etc/rc.conf: ifconfig_igb{0,1,2,3}="mtu 9000 up" and rebooting everything worked and I have mtu 9000 in lagg0 and 2 vlans Thanks for hints! -- Marek Salwerowicz From owner-freebsd-net@FreeBSD.ORG Fri Sep 13 15:08:25 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E57EE4D9; Fri, 13 Sep 2013 15:08:24 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ADAE52829; Fri, 13 Sep 2013 15:08:24 +0000 (UTC) Received: from [209.249.190.124] (port=63489 helo=gnnmac.hudson-trading.com) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VKUys-0006KF-N7; Fri, 13 Sep 2013 11:08:23 -0400 Content-Type: multipart/signed; boundary="Apple-Mail=_C7AE7CBE-E315-44DA-B15B-4A00DFC704F3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Network stack changes From: George Neville-Neil In-Reply-To: Date: Fri, 13 Sep 2013 11:08:27 -0400 Message-Id: <6BDA4619-783C-433E-9819-A7EAA0BD3299@neville-neil.com> References: <521E41CB.30700@yandex-team.ru> To: Adrian Chadd X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com Cc: "Alexander V. Chernikov" , Luigi Rizzo , Andre Oppermann , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" , "Andrey V. Elsukov" , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 15:08:25 -0000 --Apple-Mail=_C7AE7CBE-E315-44DA-B15B-4A00DFC704F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 29, 2013, at 7:49 , Adrian Chadd wrote: > Hi, >=20 > There's a lot of good stuff to review here, thanks! >=20 > Yes, the ixgbe RX lock needs to die in a fire. It's kinda pointless to = keep > locking things like that on a per-packet basis. We should be able to = do > this in a cleaner way - we can defer RX into a CPU pinned taskqueue = and > convert the interrupt handler to a fast handler that just schedules = that > taskqueue. We can ignore the ithread entirely here. >=20 > What do you think? >=20 > Totally pie in the sky handwaving at this point: >=20 > * create an array of mbuf pointers for completed mbufs; > * populate the mbuf array; > * pass the array up to ether_demux(). >=20 > For vlan handling, it may end up populating its own list of mbufs to = push > up to ether_demux(). So maybe we should extend the API to have a = bitmap of > packets to actually handle from the array, so we can pass up a larger = array > of mbufs, note which ones are for the destination and then the upcall = can > mark which frames its consumed. >=20 > I specifically wonder how much work/benefit we may see by doing: >=20 > * batching packets into lists so various steps can batch process = things > rather than run to completion; > * batching the processing of a list of frames under a single lock = instance > - eg, if the forwarding code could do the forwarding lookup for 'n' = packets > under a single lock, then pass that list of frames up to = inet_pfil_hook() > to do the work under one lock, etc, etc. >=20 > Here, the processing would look less like "grab lock and process to > completion" and more like "mark and sweep" - ie, we have a list of = frames > that we mark as needing processing and mark as having been processed = at > each layer, so we know where to next dispatch them. >=20 One quick note here. Every time you increase batching you may increase = bandwidth but you will also increase per packet latency for the last packet in a = batch. That is fine so long as we remember that and that this is a tuning knob to balance the two. > I still have some tool coding to do with PMC before I even think about > tinkering with this as I'd like to measure stuff like per-packet = latency as > well as top-level processing overhead (ie, CPU_CLK_UNHALTED.THREAD_P / > lagg0 TX bytes/pkts, RX bytes/pkts, NIC interrupts on that core, etc.) >=20 This would be very useful in identifying the actual hot spots, and would = be helpful to anyone who can generate a decent stream of packets with, say, an = IXIA. Best, George --Apple-Mail=_C7AE7CBE-E315-44DA-B15B-4A00DFC704F3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlIzKmsACgkQYdh2wUQKM9Lk2QCeLeRhFPb5zHPhQ4hHJ+H/JXWv OR0AoMDJ9iHjwtGg4DblcC0ZSmxt/noE =gAUE -----END PGP SIGNATURE----- --Apple-Mail=_C7AE7CBE-E315-44DA-B15B-4A00DFC704F3-- From owner-freebsd-net@FreeBSD.ORG Fri Sep 13 22:44:58 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BA466CF7; Fri, 13 Sep 2013 22:44:58 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id F0B502CB0; Fri, 13 Sep 2013 22:44:57 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEAMaUM1KDaFve/2dsb2JhbABbhBGDKr1RgTN0giUBAQQBDhVCFBsYAgINGQJZBhOHfQanYJFpgSmOFDQHgmmBNQOpboNAIIFu X-IronPort-AV: E=Sophos;i="4.90,901,1371096000"; d="scan'208";a="51784977" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 13 Sep 2013 18:43:23 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 11462B3F45; Fri, 13 Sep 2013 18:43:23 -0400 (EDT) Date: Fri, 13 Sep 2013 18:43:23 -0400 (EDT) From: Rick Macklem To: George Neville-Neil Message-ID: <221093226.23439826.1379112203059.JavaMail.root@uoguelph.ca> In-Reply-To: <6BDA4619-783C-433E-9819-A7EAA0BD3299@neville-neil.com> Subject: Re: Network stack changes MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) X-Mailman-Approved-At: Fri, 13 Sep 2013 23:03:44 +0000 Cc: "Alexander V. Chernikov" , Luigi Rizzo , Andre Oppermann , freebsd-hackers@freebsd.org, FreeBSD Net , Adrian Chadd , "Andrey V. Elsukov" , freebsd-arch@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, 13 Sep 2013 22:44:58 -0000 George Neville-Neil wrote: > > On Aug 29, 2013, at 7:49 , Adrian Chadd wrote: > > > Hi, > > > > There's a lot of good stuff to review here, thanks! > > > > Yes, the ixgbe RX lock needs to die in a fire. It's kinda pointless > > to keep > > locking things like that on a per-packet basis. We should be able > > to do > > this in a cleaner way - we can defer RX into a CPU pinned taskqueue > > and > > convert the interrupt handler to a fast handler that just schedules > > that > > taskqueue. We can ignore the ithread entirely here. > > > > What do you think? > > > > Totally pie in the sky handwaving at this point: > > > > * create an array of mbuf pointers for completed mbufs; > > * populate the mbuf array; > > * pass the array up to ether_demux(). > > > > For vlan handling, it may end up populating its own list of mbufs > > to push > > up to ether_demux(). So maybe we should extend the API to have a > > bitmap of > > packets to actually handle from the array, so we can pass up a > > larger array > > of mbufs, note which ones are for the destination and then the > > upcall can > > mark which frames its consumed. > > > > I specifically wonder how much work/benefit we may see by doing: > > > > * batching packets into lists so various steps can batch process > > things > > rather than run to completion; > > * batching the processing of a list of frames under a single lock > > instance > > - eg, if the forwarding code could do the forwarding lookup for 'n' > > packets > > under a single lock, then pass that list of frames up to > > inet_pfil_hook() > > to do the work under one lock, etc, etc. > > > > Here, the processing would look less like "grab lock and process to > > completion" and more like "mark and sweep" - ie, we have a list of > > frames > > that we mark as needing processing and mark as having been > > processed at > > each layer, so we know where to next dispatch them. > > > > One quick note here. Every time you increase batching you may > increase bandwidth > but you will also increase per packet latency for the last packet in > a batch. > That is fine so long as we remember that and that this is a tuning > knob > to balance the two. > And any time you increase latency, that will have a negative impact on NFS performance. NFS RPCs are usually small messages (except Write requests and Read replies) and the RTT for these (mostly small, bidirectional) messages can have a significant impact on NFS perf. rick > > I still have some tool coding to do with PMC before I even think > > about > > tinkering with this as I'd like to measure stuff like per-packet > > latency as > > well as top-level processing overhead (ie, > > CPU_CLK_UNHALTED.THREAD_P / > > lagg0 TX bytes/pkts, RX bytes/pkts, NIC interrupts on that core, > > etc.) > > > > This would be very useful in identifying the actual hot spots, and > would be helpful > to anyone who can generate a decent stream of packets with, say, an > IXIA. > > Best, > George > > > From owner-freebsd-net@FreeBSD.ORG Sat Sep 14 03:23:22 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 194F1790 for ; Sat, 14 Sep 2013 03:23:22 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm48-vm2.bullet.mail.gq1.yahoo.com (nm48-vm2.bullet.mail.gq1.yahoo.com [67.195.87.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DC4B82D93 for ; Sat, 14 Sep 2013 03:23:21 +0000 (UTC) Received: from [98.137.12.55] by nm48.bullet.mail.gq1.yahoo.com with NNFMP; 14 Sep 2013 03:23:15 -0000 Received: from [208.71.42.198] by tm15.bullet.mail.gq1.yahoo.com with NNFMP; 14 Sep 2013 03:23:14 -0000 Received: from [127.0.0.1] by smtp209.mail.gq1.yahoo.com with NNFMP; 14 Sep 2013 03:23:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1379128994; bh=uNLNF+xp7oqjMSE1ID2sh8fmYNH6uDIhvSrV4woujGw=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:References:From:Content-Transfer-Encoding:Content-Type:In-Reply-To:Message-Id:Date:Cc:To:Mime-Version:X-Mailer; b=wyUQasFFw9CQhob2Kjtmj9MvsKxyZlXN+c4D7aDOkZ7y93Wtsw+u/rvp1rLVpcNWb+I0Jl4QoTtcS3S+3zbiPcR03FE15C+YgROgm7VAwj0xQ1h6i/4XRlC9DooK/thEAv+TtVmN+hYELJ7Wl+A7I6q9caaYY91Yv5MpAwKSGIA= X-Yahoo-Newman-Id: 861575.67445.bm@smtp209.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 5e_DUFsVM1mKMaXEDKYgrEqPJIX_aqV._y37IFCg0uouCWq .jeIMTv4U5BniQEfqoWHyGrDS5yUvG6YePIXbkwtI6BRE2gfUVWCg6Vy7NVQ g.SbYQcCmebj5AU6lerHNgMej4V17ZCR_6ohECiuAUG05RE3LTEK9UFUnYrQ MJGi_yDPyp2RIiGiguVtgxGDEG9yvU2PJdx0q0hDJ9ArVFgJIjezYys8v4at kPBskHmIk.bGS2YQ9xG2cGg67BHWzzpxM.xKBTNPDo1Bn9IedGWeSWrtFD3p AM.h9Fso.XYuIbpqbZC8gpnhCzeDnoou1EMuj6_rOGy.t50YBwuWsuwwZhT3 m4fs5an6uHclBdktuG_hTDFMlKSiHkFYP.8WS..5r50hgLUT8XgzE3rQ_HUt tnIeJAeHFm_5eFaYiHi5ywHNNYb7hDRw_0_Lw1SuCDDf3foioTBi2mds7s1x ItAOAX.oEnZV2dbYb53wqV_nNUZ.1sHIPwL0p4TjoQt5Z_qoejICT5Y2yvCd 3_diug3e5F1KgOzo2eGiT3Zqao8kYxlC62DpoIiWPjXdiWpuPdXnC1yP0eCc QvPHlYRlnyqO4klpLLgGRMyYBpKBZpZvYLsPyBfzGV7EapxamqtdglKq9buf Qx0r8JJk4vnO_at51iN1PEkTdiqmTyspucfASvId78OFfBo0F3iOWah2AW1C cBn7_e8t7cMjgKsKSbVmSB8q0e0lrH3edmKXggnw- X-Yahoo-SMTP: JS53x9KswBBbHwiASGkeEr3kN4kAksMTpmFe X-Rocket-Received: from [10.70.11.35] (barney_cordoba@166.147.111.164 with ) by smtp209.mail.gq1.yahoo.com with SMTP; 13 Sep 2013 20:23:14 -0700 PDT Subject: Re: TSO help or hindrance ? (was Re: TSO and FreeBSD vs Linux) References: <979862494.17918795.1378299005617.JavaMail.root@uoguelph.ca> <52275136.1010105@sentex.net> <1378852936.95477.YahooMailNeo@web121601.mail.ne1.yahoo.com> <522FA2C3.7010109@sentex.net> From: Barney Cordoba Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In-Reply-To: <522FA2C3.7010109@sentex.net> Message-Id: <596C2208-BC2A-417B-B46F-300D5886C087@yahoo.com> Date: Fri, 13 Sep 2013 23:08:11 -0400 To: Mike Tancsa Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (9A406) Cc: FreeBSD Net , Rick Macklem , David Wolfskill 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, 14 Sep 2013 03:23:22 -0000 Didn't read down far enough. There are def issues and gains are probably mo= stly in a lab with 9k frames. Turn it off. CPUs and buses are fast.=20 BC On Sep 10, 2013, at 6:52 PM, Mike Tancsa wrote: > On 9/10/2013 6:42 PM, Barney Cordoba wrote: >> NFS has been broken since Day 1, so lets not come to conclusions about >> anything >> as it relates to NFS. >=20 > iSCSI is NFS ? >=20 > ---Mike >=20 >>=20 >> BC >>=20 >> ------------------------------------------------------------------------ >> *From:* Mike Tancsa >> *To:* Rick Macklem >> *Cc:* FreeBSD Net ; David Wolfskill >> *Sent:* Wednesday, September 4, 2013 11:26 AM >> *Subject:* TSO help or hindrance ? (was Re: TSO and FreeBSD vs Linux) >>=20 >> On 9/4/2013 8:50 AM, Rick Macklem wrote: >>> David Wolfskill wrote: >>>>=20 >>>>=20 >>>> I noticed that when I tried to write files to NFS, I could write >>>> small >>>> files OK, but larger ones seemed to ... hang. >>>> * "ifconfig -v em0" showed flags TSO4 & VLAN_HWTSO turned on. >>>> * "sysctl net.inet.tcp.tso" showed "1" -- enabled. >>>>=20 >>>> As soon as I issued "sudo net.inet.tcp.tso=3D0" ... the copy worked >>>> without >>>> a hitch or a whine. And I was able to copy all 117709618 bytes, not >>>> just >>>> 2097152 (2^21). >>>>=20 >>>> Is the above expected? It came rather as a surprise to me. >>>>=20 >>> Not surprising to me, I'm afraid. When there are serious NFS problems >>> like this, it is often caused by a network fabric issue and broken >>> TSO is at the top of the list w.r.t. cause. >>=20 >>=20 >> I was just experimenting a bit with iSCSI via FreeNAS and was a little >> disappointed at the speeds I was getting. So, I tried disabling tso on >> both boxes and it did seem to speed things up a bit. Data and testing >> methods attached in a txt file. >>=20 >> I did 3 cases. >>=20 >> Just boot up FreeNAS and the initiator without tweaks. That had the >> worst performance. >> disable tso on the nic as well as via sysctl on both boxes. That had the >> best performance. >> re-enable tso on both boxes. That had better performance than the first >> case, but still not as good as totally disabling it. I am guessing >> something is not quite being re-enabled properly ? But its different >> than the other two cases ?!? >>=20 >> tgt is FreeNAS-9.1.1-RELEASE-x64 (a752d35) and initiator is r254328 9.2 >> AMD64 >>=20 >> The FreeNAS box has 16G of RAM, so the file is being served out of cache >> as gstat shows no activity when sending out the file >>=20 >>=20 >>=20 >> ---Mike >>=20 >>=20 >> --=20 >> ------------------- >> Mike Tancsa, tel +1 519 651 3400 >> Sentex Communications, mike@sentex.net >> Providing Internet services since 1994 www.sentex.net >> Cambridge, Ontario Canada http://www.tancsa.com/ >>=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 >=20 >=20 > --=20 > ------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet services since 1994 www.sentex.net > Cambridge, Ontario Canada http://www.tancsa.com/ > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Sep 14 08:59:14 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 77B8030A; Sat, 14 Sep 2013 08:59:14 +0000 (UTC) (envelope-from anshukla@juniper.net) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2D2842A2E; Sat, 14 Sep 2013 08:59:13 +0000 (UTC) Received: from mail101-tx2-R.bigfish.com (10.9.14.249) by TX2EHSOBE011.bigfish.com (10.9.40.31) with Microsoft SMTP Server id 14.1.225.22; Sat, 14 Sep 2013 08:44:06 +0000 Received: from mail101-tx2 (localhost [127.0.0.1]) by mail101-tx2-R.bigfish.com (Postfix) with ESMTP id 087621401BE; Sat, 14 Sep 2013 08:44:06 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zz4015Izz1202hzzz2fh2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail101-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=anshukla@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(164054003)(59766001)(83322001)(76482001)(56776001)(47736001)(81816001)(74366001)(83072001)(81542001)(76796001)(77982001)(56816003)(54316002)(81686001)(74706001)(80976001)(74876001)(79102001)(76786001)(63696002)(82746002)(4396001)(54356001)(46102001)(77096001)(53806001)(33656001)(74662001)(81342001)(36756003)(50986001)(49866001)(80022001)(65816001)(69226001)(47976001)(47446002)(51856001)(66066001)(76176001)(74502001)(31966008)(83716001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB126; H:BY2PR05MB111.namprd05.prod.outlook.com; CLIP:66.129.224.53; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail101-tx2 (localhost.localdomain [127.0.0.1]) by mail101-tx2 (MessageSwitch) id 137914824531622_17646; Sat, 14 Sep 2013 08:44:05 +0000 (UTC) Received: from TX2EHSMHS008.bigfish.com (unknown [10.9.14.226]) by mail101-tx2.bigfish.com (Postfix) with ESMTP id 031FB1E0050; Sat, 14 Sep 2013 08:44:05 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS008.bigfish.com (10.9.99.108) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 14 Sep 2013 08:44:04 +0000 Received: from BY2PR05MB126.namprd05.prod.outlook.com (10.242.38.22) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.353.4; Sat, 14 Sep 2013 08:44:03 +0000 Received: from BY2PR05MB111.namprd05.prod.outlook.com (10.242.38.26) by BY2PR05MB126.namprd05.prod.outlook.com (10.242.38.22) with Microsoft SMTP Server (TLS) id 15.0.775.9; Sat, 14 Sep 2013 08:44:01 +0000 Received: from BY2PR05MB111.namprd05.prod.outlook.com ([169.254.6.196]) by BY2PR05MB111.namprd05.prod.outlook.com ([169.254.6.196]) with mapi id 15.00.0745.000; Sat, 14 Sep 2013 08:44:01 +0000 From: Anuranjan Shukla To: "freebsd-net@freebsd.org" Subject: IFNAMSIZ/IF_NAMESIZE change proposal Thread-Topic: IFNAMSIZ/IF_NAMESIZE change proposal Thread-Index: AQHOsSaOJ+rmaQHm2keFzzUFg8ShKg== Date: Sat, 14 Sep 2013 08:44:00 +0000 Message-ID: <9527D72E-5871-4C5E-B2AB-A3BECA4925D4@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.53] x-forefront-prvs: 096943F07A Content-Type: text/plain; charset="us-ascii" Content-ID: <7FC910DFF375144FA42B338C8588FC2C@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Marcel Moolenaar , "freebsd-arch@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, 14 Sep 2013 08:59:14 -0000 Hi, At Juniper Networks, interface name size was needed to be longer than what = FreeBSD has. We're trying to reduce our local changes to FreeBSD to allow u= s an easier time upgrading to newer FreeBSD releases, and support the modul= arization of the network stack we'd proposed earlier. I'm sending this out= to propose changing IFNAMSIZ from 16 to 60 (this is the size we use) in Fr= eeBSD. We don't see any downside (other than increasing the ifreq structure= size for one) to doing this, as allowing longer interface names can be han= dy for vendors. I'd like to hear if there's a strong objection to this. If = not, we'd like to get this into to the FreeBSD codebase. Any thoughts/objec= tions highly appreciated. Thanks, Anu= From owner-freebsd-net@FreeBSD.ORG Fri Sep 13 23:50:56 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7F75BF5D; Fri, 13 Sep 2013 23:50:56 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AE58024DF; Fri, 13 Sep 2013 23:50:55 +0000 (UTC) Received: by mail-vc0-f176.google.com with SMTP id lf11so1477854vcb.35 for ; Fri, 13 Sep 2013 16:50:54 -0700 (PDT) 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=v+1K+CJy8FST36tLGRI1CopeWdhZIx7Suv24TJlXZrM=; b=g/b01xY6i+diDvG6LVOFtHGVgdT7+E8zNQUgDXY1AsBTKvepoYfhQ9v0/fH30G3+5q uZyXq/Yp2p4lcKeGcsGTTME0a9BexzNatw/Unmp5HbFbDPsgKvILeN0xrcyUhCb7Y7Mh /aZfU+E8w8MiutITXjHfnmVI1G/i2+iVmKB7pkaOPGl5nxjrJaeAiFWyC66ZuZOPpJTQ msGuo9cwQ9V2gd6iiuld+7+PYWq8dNIinCYlgKgLi3B9e6mvFFmCTVe0NF0j91fYRgRh 2ThzkZb+tm88RJ+GbzxziK6o5SeJM/+jY9FdZmvuRJyIwcezz+6yg9t5vxj9TyN2DkuF 2Srg== MIME-Version: 1.0 X-Received: by 10.58.137.167 with SMTP id qj7mr14239382veb.1.1379116254223; Fri, 13 Sep 2013 16:50:54 -0700 (PDT) Received: by 10.220.96.78 with HTTP; Fri, 13 Sep 2013 16:50:54 -0700 (PDT) In-Reply-To: <221093226.23439826.1379112203059.JavaMail.root@uoguelph.ca> References: <6BDA4619-783C-433E-9819-A7EAA0BD3299@neville-neil.com> <221093226.23439826.1379112203059.JavaMail.root@uoguelph.ca> Date: Fri, 13 Sep 2013 19:50:54 -0400 Message-ID: Subject: Re: Network stack changes From: "Sam Fourman Jr." To: Rick Macklem X-Mailman-Approved-At: Sat, 14 Sep 2013 11:19:09 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "Alexander V. Chernikov" , Luigi Rizzo , Andre Oppermann , freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org, Adrian Chadd , "Andrey V. Elsukov" , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 23:50:56 -0000 > > And any time you increase latency, that will have a negative impact on > NFS performance. NFS RPCs are usually small messages (except Write requests > and Read replies) and the RTT for these (mostly small, bidirectional) > messages can have a significant impact on NFS perf. > > rick > > this may be a bit off topic but not much... I have wondered with all of the new tcp algorithms http://freebsdfoundation.blogspot.com/2011/03/summary-of-five-new-tcp-congestion.html what algorithm is best suited for NFS over gigabit Ethernet, say FreeBSD to FreeBSD. and further more would a NFS optimized tcp algorithm be useful? Sam Fourman Jr. From owner-freebsd-net@FreeBSD.ORG Sat Sep 14 01:39:10 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 588CE92D; Sat, 14 Sep 2013 01:39:10 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 8B6B92916; Sat, 14 Sep 2013 01:39:08 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAP+9M1KDaFve/2dsb2JhbABbgz9Sgyq9U4E1dIIlAQEEASNWBRYYAgINGQJZBgqIBgYMp2aRc4EpjhQ0B4JpgTUDhRWWbY1sg0AggW4 X-IronPort-AV: E=Sophos;i="4.90,902,1371096000"; d="scan'208";a="51799604" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 13 Sep 2013 21:38:50 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 67F6EB404B; Fri, 13 Sep 2013 21:38:50 -0400 (EDT) Date: Fri, 13 Sep 2013 21:38:50 -0400 (EDT) From: Rick Macklem To: "Sam Fourman Jr." Message-ID: <1087948919.23486338.1379122730412.JavaMail.root@uoguelph.ca> In-Reply-To: Subject: Re: Network stack changes MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) X-Mailman-Approved-At: Sat, 14 Sep 2013 11:19:24 +0000 Cc: "Alexander V. Chernikov" , Luigi Rizzo , Andre Oppermann , freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org, Adrian Chadd , "Andrey V. Elsukov" , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 01:39:10 -0000 Sam Fourman Jr. wrote: > > > > > And any time you increase latency, that will have a negative impact > > on > > NFS performance. NFS RPCs are usually small messages (except Write > > requests > > and Read replies) and the RTT for these (mostly small, > > bidirectional) > > messages can have a significant impact on NFS perf. > > > > rick > > > > > this may be a bit off topic but not much... I have wondered with all > of the > new > tcp algorithms > http://freebsdfoundation.blogspot.com/2011/03/summary-of-five-new-tcp-congestion.html > > what algorithm is best suited for NFS over gigabit Ethernet, say > FreeBSD to > FreeBSD. > and further more would a NFS optimized tcp algorithm be useful? > I have no idea what effect they might have. NFS traffic is quite different than streaming or bulk data transfer. I think this might make a nice research project for someone. rick > Sam Fourman Jr. > From owner-freebsd-net@FreeBSD.ORG Sat Sep 14 03:20:11 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C15D375C; Sat, 14 Sep 2013 03:20:11 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 77D232D5A; Sat, 14 Sep 2013 03:20:10 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id b13so1846169wgh.23 for ; Fri, 13 Sep 2013 20:20:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=IFtRksCRmfL5B1+1wrQ7GTfCJsIIDDCQHX1+tZW4pFQ=; b=gI6Nxi2aoExXobnlohogoRzOt/qT7IXI0S9dphpVrKUea7aD4TIXmx63GGGEDMC1RJ RA27fo4BQDJ0VIiHocD9bvG5E37i8JnwODvAUpXEJn2OAIBJ2JGT6jwZfTwYLig5VAjm J7TZj0nj1NWZi1FqKh2SoMOjG0roERH3UT+4AbsBozTVV0yA36ecQqdvoYj2OkHeN4XN eB7iFW8OKSUD1qX1mVZhJ/ELCZNLJTkM8J5BBS8MQf192G62xmiN8QUTJ8ANiHntSpYH SC1bDAPmy6yBesJBrzoElWyK5AJ9DmzUj9+jkqOACAjjYPgoMyEzracI7lwUC/CdcGkW UZrQ== MIME-Version: 1.0 X-Received: by 10.180.10.136 with SMTP id i8mr4954841wib.46.1379128808906; Fri, 13 Sep 2013 20:20:08 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.73.133 with HTTP; Fri, 13 Sep 2013 20:20:08 -0700 (PDT) In-Reply-To: <221093226.23439826.1379112203059.JavaMail.root@uoguelph.ca> References: <6BDA4619-783C-433E-9819-A7EAA0BD3299@neville-neil.com> <221093226.23439826.1379112203059.JavaMail.root@uoguelph.ca> Date: Fri, 13 Sep 2013 20:20:08 -0700 X-Google-Sender-Auth: A0kv2cAHQtkyVSyFBvksPLrnLYs Message-ID: Subject: Re: Network stack changes From: Adrian Chadd To: Rick Macklem X-Mailman-Approved-At: Sat, 14 Sep 2013 12:12:53 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "Alexander V. Chernikov" , Luigi Rizzo , Andre Oppermann , "freebsd-hackers@freebsd.org" , FreeBSD Net , "Andrey V. Elsukov" , "freebsd-arch@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, 14 Sep 2013 03:20:11 -0000 On 13 September 2013 15:43, Rick Macklem wrote: > And any time you increase latency, that will have a negative impact on > NFS performance. NFS RPCs are usually small messages (except Write requests > and Read replies) and the RTT for these (mostly small, bidirectional) > messages can have a significant impact on NFS perf. > Hi, the penalties to go to main memory quite a few times each time we process a frame is expensive. If we can get some better behaviour through batching leading to more efficient cache usage, it may not actually _have_ a delay. But, that requires a whole lot of design stars to align. And I'm still knee deep elsewhere, so I haven't really finished getting up to speed with what everyone else has done / said about it.. -adrian From owner-freebsd-net@FreeBSD.ORG Sat Sep 14 12:33:51 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C8584735 for ; Sat, 14 Sep 2013 12:33:51 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A3F61246D for ; Sat, 14 Sep 2013 12:33:51 +0000 (UTC) Received: by mail-pd0-f179.google.com with SMTP id v10so2320494pde.24 for ; Sat, 14 Sep 2013 05:33:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:mime-version:to:cc:subject:content-type :content-transfer-encoding; bh=apZ54tyXGn5upoqaZmB67BYrr6hYVkVVi6sb0fyX7wg=; b=ETfeSTJGyf7Mlvm20oJyAKw2Z4vu4vWy5ABw8aZdbRGwyizXrJJbRSjQaOeMZJo5kX GPiid6qFImZuL0P4QzWR/zosPgYA1YAeCVF2h0K4FJtVzi/j1SnryyR5bUISfrEwxzcf 6t4MGzP3zWwy7MIw501o4ER1xegnhe/TYX29V5+vOVGhtkc7hc5gzuV91jeRt+ZdHKb7 S70MtNk4ln/FtEQqcli9Xudstc3EGRPZxCZznfgHOe89k2FXCmhV8OkdwyV/hQ0/XmtP xQnI5Gk7dZlWpHnDvBn3BaD8FX7c/KGo7+jYcxAu+K8vdueDSkXZd/h2cec4doae6gEv pnnQ== X-Received: by 10.68.232.3 with SMTP id tk3mr1827472pbc.121.1379162031183; Sat, 14 Sep 2013 05:33:51 -0700 (PDT) Received: from 127.0.0.1 (herngaard.torservers.net. [96.44.189.102]) by mx.google.com with ESMTPSA id va8sm1237175pbc.16.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 14 Sep 2013 05:33:50 -0700 (PDT) Sender: Robert Millan Message-ID: <523457A1.3090606@debian.org> Date: Sat, 14 Sep 2013 12:33:37 +0000 From: Robert Millan MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: IPSEC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "debian-bsd@lists.debian.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, 14 Sep 2013 12:33:51 -0000 Hi! Is there any particular reason (performance, stability concerns...) IPSEC support is not enabled in GENERIC? In Debian GNU/kFreeBSD we're considering enabling it in our default builds, due to increased user demand and as it is already enabled for our Linux-based flavours. However we're concerned about diverging from FreeBSD as there might be unforeseen consequences. Is there any specific concern on your side? If not, perhaps it could be considered for HEAD after 10.0 release? Thanks! -- Robert Millan From owner-freebsd-net@FreeBSD.ORG Sat Sep 14 16:27:51 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 05BB2A49 for ; Sat, 14 Sep 2013 16:27:51 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f50.google.com (mail-pb0-f50.google.com [209.85.160.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CF07E2E46 for ; Sat, 14 Sep 2013 16:27:50 +0000 (UTC) Received: by mail-pb0-f50.google.com with SMTP id uo5so2453199pbc.9 for ; Sat, 14 Sep 2013 09:27:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=UuM2F4Cd7SGqOWVDzT4jPsStz/HsrmK1gJpu6DlJwRc=; b=FU399cKsss6lJNPX2lIn3lPAJl98n3iftAJg47V8TegBvzmhf744/NQu3ihVkm6U1w Or/+3sZujcZ+elARyCquwYqWtAKBeQ6h8GHzh1gutmxgXmLNL79lnq74FeSdWWOgahZk 0VGEcRdyy3R7wW+UIhbTLBG3lYMD23wm3680dEco/Q2FT2V6550xtjIib6khfarZH7Hi PMKioEjd+pbnQYw56JXVmyAIKBkbofUUrEUjBB1Z5vAB/cH5Y7uCWYuwIm0855KRP3Ip HiSbZQu1abIJGExd1joUu6/UBfZVxBnj6OgvRzCYj37WrKZJjH+iv1yKyur6wo5uFkPt qa1g== X-Gm-Message-State: ALoCoQkSMabsTFJAve+56JqKXOrKiQK9OfqBjGvmMcGt7QhyJAjpJFoVlbwrsBZ5EIiysKB+aF1I X-Received: by 10.66.26.112 with SMTP id k16mr21187903pag.65.1379175686312; Sat, 14 Sep 2013 09:21:26 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id vz4sm26015491pab.11.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 14 Sep 2013 09:21:25 -0700 (PDT) Sender: Warner Losh Subject: Re: IFNAMSIZ/IF_NAMESIZE change proposal Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <9527D72E-5871-4C5E-B2AB-A3BECA4925D4@juniper.net> Date: Sat, 14 Sep 2013 10:21:25 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <19C0CA7F-2857-4533-B5E7-29E1085DE072@bsdimp.com> References: <9527D72E-5871-4C5E-B2AB-A3BECA4925D4@juniper.net> To: Anuranjan Shukla X-Mailer: Apple Mail (2.1085) Cc: "freebsd-net@freebsd.org" , Marcel Moolenaar , "freebsd-arch@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, 14 Sep 2013 16:27:51 -0000 On Sep 14, 2013, at 2:44 AM, Anuranjan Shukla wrote: > At Juniper Networks, interface name size was needed to be longer than = what FreeBSD has. We're trying to reduce our local changes to FreeBSD to = allow us an easier time upgrading to newer FreeBSD releases, and support = the modularization of the network stack we'd proposed earlier. I'm = sending this out to propose changing IFNAMSIZ from 16 to 60 (this is = the size we use) in FreeBSD. We don't see any downside (other than = increasing the ifreq structure size for one) to doing this, as allowing = longer interface names can be handy for vendors. I'd like to hear if = there's a strong objection to this. If not, we'd like to get this into = to the FreeBSD codebase. Any thoughts/objections highly appreciated. 56 or 64 would be better for alignment, wouldn't it? Warner From owner-freebsd-net@FreeBSD.ORG Sat Sep 14 17:30:58 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B733AF22; Sat, 14 Sep 2013 17:30:58 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 74C27210C; Sat, 14 Sep 2013 17:30:57 +0000 (UTC) Received: from mail95-co9-R.bigfish.com (10.236.132.251) by CO9EHSOBE027.bigfish.com (10.236.130.90) with Microsoft SMTP Server id 14.1.225.22; Sat, 14 Sep 2013 17:30:51 +0000 Received: from mail95-co9 (localhost [127.0.0.1]) by mail95-co9-R.bigfish.com (Postfix) with ESMTP id 5191F8C0132; Sat, 14 Sep 2013 17:30:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -4 X-BigFish: VPS-4(zzbb2dI98dI9371I1432Izz1202hzzz2fh2a8h668h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail95-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=marcelm@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(377454003)(479174003)(199002)(189002)(24454002)(65816001)(80022001)(31966008)(47446002)(74662001)(80976001)(74502001)(81686001)(76786001)(81816001)(76176001)(83506001)(76796001)(36756003)(66066001)(74706001)(50986001)(47976001)(53806001)(69226001)(83072001)(76482001)(49866001)(47736001)(46102001)(74366001)(74876001)(81342001)(51856001)(4396001)(81542001)(54316002)(54356001)(56776001)(77096001)(56816003)(79102001)(63696002)(83322001)(19580395003)(19580405001)(59766001)(77982001)(1941001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB109; H:BY2PR05MB127.namprd05.prod.outlook.com; CLIP:66.129.224.36; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail95-co9 (localhost.localdomain [127.0.0.1]) by mail95-co9 (MessageSwitch) id 1379179849451054_3462; Sat, 14 Sep 2013 17:30:49 +0000 (UTC) Received: from CO9EHSMHS024.bigfish.com (unknown [10.236.132.244]) by mail95-co9.bigfish.com (Postfix) with ESMTP id 5FFD8500041; Sat, 14 Sep 2013 17:30:49 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS024.bigfish.com (10.236.130.34) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 14 Sep 2013 17:30:49 +0000 Received: from BY2PR05MB109.namprd05.prod.outlook.com (10.242.38.15) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.353.4; Sat, 14 Sep 2013 17:30:48 +0000 Received: from BY2PR05MB127.namprd05.prod.outlook.com (10.242.38.24) by BY2PR05MB109.namprd05.prod.outlook.com (10.242.38.15) with Microsoft SMTP Server (TLS) id 15.0.745.25; Sat, 14 Sep 2013 17:30:46 +0000 Received: from BY2PR05MB127.namprd05.prod.outlook.com ([169.254.8.216]) by BY2PR05MB127.namprd05.prod.outlook.com ([169.254.8.216]) with mapi id 15.00.0775.005; Sat, 14 Sep 2013 17:30:45 +0000 From: Marcel Moolenaar To: Warner Losh , Anuranjan Shukla Subject: Re: IFNAMSIZ/IF_NAMESIZE change proposal Thread-Topic: IFNAMSIZ/IF_NAMESIZE change proposal Thread-Index: AQHOsSaOJ+rmaQHm2keFzzUFg8ShKpnFap2A//+eBIA= Date: Sat, 14 Sep 2013 17:30:45 +0000 Message-ID: In-Reply-To: <19C0CA7F-2857-4533-B5E7-29E1085DE072@bsdimp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [66.129.224.36] x-forefront-prvs: 096943F07A Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "freebsd-net@freebsd.org" , "freebsd-arch@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, 14 Sep 2013 17:30:58 -0000 On 9/14/13 9:21 AM, "Warner Losh" wrote: > >On Sep 14, 2013, at 2:44 AM, Anuranjan Shukla wrote: >> At Juniper Networks, interface name size was needed to be longer than >>what FreeBSD has. We're trying to reduce our local changes to FreeBSD to >>allow us an easier time upgrading to newer FreeBSD releases, and support >>the modularization of the network stack we'd proposed earlier. I'm >>sending this out to propose changing IFNAMSIZ from 16 to 60 (this is >>the size we use) in FreeBSD. We don't see any downside (other than >>increasing the ifreq structure size for one) to doing this, as allowing >>longer interface names can be handy for vendors. I'd like to hear if >>there's a strong objection to this. If not, we'd like to get this into >>to the FreeBSD codebase. Any thoughts/objections highly appreciated. > >56 or 64 would be better for alignment, wouldn't it? Yes, but then we need to change Junos' definition to match FreeBSD's and we're not sure yet if that's at all possible. Hence the suggestion to use what we have at Juniper. If a "nicer" length is preferred, then we'll see about making that happen. Thoughts? --=20 Marcel Moolenaar marcelm@juniper.net From owner-freebsd-net@FreeBSD.ORG Sat Sep 14 14:22:44 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AC2B03DC; Sat, 14 Sep 2013 14:22:44 +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 64E8129D4; Sat, 14 Sep 2013 14:22:43 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 9D36D7300B; Sat, 14 Sep 2013 16:28:02 +0200 (CEST) Date: Sat, 14 Sep 2013 16:28:02 +0200 From: Luigi Rizzo To: George Neville-Neil Subject: Re: Network stack changes Message-ID: <20130914142802.GC71010@onelab2.iet.unipi.it> References: <521E41CB.30700@yandex-team.ru> <6BDA4619-783C-433E-9819-A7EAA0BD3299@neville-neil.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6BDA4619-783C-433E-9819-A7EAA0BD3299@neville-neil.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Sat, 14 Sep 2013 19:44:27 +0000 Cc: "Alexander V. Chernikov" , Adrian Chadd , Andre Oppermann , "freebsd-hackers@freebsd.org" , FreeBSD Net , Luigi Rizzo , "Andrey V. Elsukov" , "freebsd-arch@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, 14 Sep 2013 14:22:44 -0000 On Fri, Sep 13, 2013 at 11:08:27AM -0400, George Neville-Neil wrote: > > On Aug 29, 2013, at 7:49 , Adrian Chadd wrote: ... > > I still have some tool coding to do with PMC before I even think about > > tinkering with this as I'd like to measure stuff like per-packet latency as > > well as top-level processing overhead (ie, CPU_CLK_UNHALTED.THREAD_P / > > lagg0 TX bytes/pkts, RX bytes/pkts, NIC interrupts on that core, etc.) > > > > This would be very useful in identifying the actual hot spots, and would be helpful > to anyone who can generate a decent stream of packets with, say, an IXIA. IXIA ? For the timescales we need to address we don't need an IXIA, a netmap sender is more than enough cheers luigi From owner-freebsd-net@FreeBSD.ORG Sat Sep 14 14:29:23 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 91632418; Sat, 14 Sep 2013 14:29:23 +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 4B73D29EB; Sat, 14 Sep 2013 14:29:23 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 015667300A; Sat, 14 Sep 2013 16:25:26 +0200 (CEST) Date: Sat, 14 Sep 2013 16:25:26 +0200 From: Luigi Rizzo To: George Neville-Neil Subject: Re: Network stack changes Message-ID: <20130914142526.GB71010@onelab2.iet.unipi.it> References: <521E41CB.30700@yandex-team.ru> <6BDA4619-783C-433E-9819-A7EAA0BD3299@neville-neil.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6BDA4619-783C-433E-9819-A7EAA0BD3299@neville-neil.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Sat, 14 Sep 2013 19:44:36 +0000 Cc: "Alexander V. Chernikov" , Adrian Chadd , Andre Oppermann , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" , Luigi Rizzo , "Andrey V. Elsukov" , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 14:29:23 -0000 On Fri, Sep 13, 2013 at 11:08:27AM -0400, George Neville-Neil wrote: > > On Aug 29, 2013, at 7:49 , Adrian Chadd wrote: ... > One quick note here. Every time you increase batching you may increase bandwidth > but you will also increase per packet latency for the last packet in a batch. The ones who suffer are the first ones, because their processing is somewhat delayed to 1) let the input batch build up, and 2) complete processing of the batch before pushing results to the next stage. However one should never wait for an input batch to grow; you process whatever your source gives you (one or more packets) by the time you are ready (and if you are slow/overloaded, of course you will get a large backlog at once). Either way, there is no reason to create additional delay on input. cheers luigi From owner-freebsd-net@FreeBSD.ORG Sat Sep 14 18:50:08 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B36D1F45; Sat, 14 Sep 2013 18:50:08 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E08292476; Sat, 14 Sep 2013 18:50:07 +0000 (UTC) Received: by mail-ve0-f177.google.com with SMTP id db12so1900995veb.22 for ; Sat, 14 Sep 2013 11:50:07 -0700 (PDT) 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:message-id :subject:to:cc:content-type; bh=/cuWua3KDkh6N+MoMwXcUoLKAbOeUwYx5AACQMHPtbc=; b=O1UlmyHnbTj+sgU6LCj9npvH4o6X88SBN3g84lWL/bVNWoLgp0H9Fv/TNJC0W+7M+R nEWGG/cFPTqz/WmR6+4t4pPZiEieyii4a8v3QixD/nIi42yANuRCy+jJjOQtJo77MBk3 tEfzncV5pH6zoBQmWpYQ+/UxZhJC4rcvku6++QPybEZZLnQAuddvfOoo3qFrEy4Bm+vo vLYCyTwqwd3SgENVZFUjENeCEk+AkPjypH4FmcXs6lKeVQTP8vaCE5FXbhI5Ifb1Pwc2 YzCv1t1m+KVkgRWn3MBK0Xcco/y2Evhg0/Fv5StOGd5NkzCH/j0GA858i7AQ9R7DywfI Dn/A== X-Received: by 10.220.13.20 with SMTP id z20mr18354266vcz.0.1379184607005; Sat, 14 Sep 2013 11:50:07 -0700 (PDT) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.58.221.9 with HTTP; Sat, 14 Sep 2013 11:49:46 -0700 (PDT) In-Reply-To: <20130914142802.GC71010@onelab2.iet.unipi.it> References: <521E41CB.30700@yandex-team.ru> <6BDA4619-783C-433E-9819-A7EAA0BD3299@neville-neil.com> <20130914142802.GC71010@onelab2.iet.unipi.it> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Sat, 14 Sep 2013 20:49:46 +0200 X-Google-Sender-Auth: jGoYAycMs8RBkfo6ZVCAv397HvM Message-ID: Subject: Re: Network stack changes To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Sat, 14 Sep 2013 20:00:24 +0000 Cc: "Alexander V. Chernikov" , Adrian Chadd , Andre Oppermann , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" , Luigi Rizzo , "Andrey V. Elsukov" , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 18:50:08 -0000 On Sat, Sep 14, 2013 at 4:28 PM, Luigi Rizzo wrote: > > IXIA ? For the timescales we need to address we don't need an IXIA, > a netmap sender is more than enough > The great netmap generates only one IP flow (same src/dst IP and same src/dst port). This don't permit to test multi-queue NIC (or SMP packet-filter) on a simple lab like this: netmap sender => freebsd router => netmap receiver Regards, Olivier From owner-freebsd-net@FreeBSD.ORG Sat Sep 14 19:24:05 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9DA1161C; Sat, 14 Sep 2013 19:24:05 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D8E8725FD; Sat, 14 Sep 2013 19:24:03 +0000 (UTC) Received: by mail-la0-f50.google.com with SMTP id lv10so1997565lab.37 for ; Sat, 14 Sep 2013 12:24:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5s/IVe0iDOLPQnHwtjKoQD9xkSMh7tizoAp5hr4lTvI=; b=GS901BZYZ5iM987h7sm7k/dxsSdQ2yBeR78dv6Lge9kVf1trBrPOztm95RxpEIGYFr XecerDCxWGsHvmRYSV8wCiEv9Ts1aWSsBGkK0d+CCqZw4b2RQ7HXz21lRWBK5BMfypkf sobNwbGh6oWQjxLiUEMK8/MZLb46xOlrZ0Mhs96D/aOKuLw17tiODK3RxRQsMPyKQ4Qm qxGT7/KH8CXkuL4SAHq5yhFsSoLIcqw16qNDwayLDIjcRv0XG3b31wdiSEPCv3uIKa1k 1EJH4qLw6aA/XhEsNU1OstWpBQPRQSFmkMDyqmyp9QbzneSzrWjI7A9VmiM08re6nYhG m9FA== MIME-Version: 1.0 X-Received: by 10.112.64.36 with SMTP id l4mr17268604lbs.15.1379186641610; Sat, 14 Sep 2013 12:24:01 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.200.165 with HTTP; Sat, 14 Sep 2013 12:24:01 -0700 (PDT) In-Reply-To: References: <521E41CB.30700@yandex-team.ru> <6BDA4619-783C-433E-9819-A7EAA0BD3299@neville-neil.com> <20130914142802.GC71010@onelab2.iet.unipi.it> Date: Sat, 14 Sep 2013 21:24:01 +0200 X-Google-Sender-Auth: As4PNyDtyJpFBvlZh6F6Ginwbys Message-ID: Subject: Re: Network stack changes From: Luigi Rizzo To: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= X-Mailman-Approved-At: Sat, 14 Sep 2013 20:00:24 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "Alexander V. Chernikov" , Adrian Chadd , Andre Oppermann , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" , Luigi Rizzo , "Andrey V. Elsukov" , FreeBSD Net , 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, 14 Sep 2013 19:24:05 -0000 On Saturday, September 14, 2013, Olivier Cochard-Labb=E9 wrote: > On Sat, Sep 14, 2013 at 4:28 PM, Luigi Rizzo wrote: >> >> IXIA ? For the timescales we need to address we don't need an IXIA, >> a netmap sender is more than enough >> > > The great netmap generates only one IP flow (same src/dst IP and same > src/dst port). True the sample app generates only one flow but it is trivial to modify it to generate multiple flows. My point was, we have the ability to generate high rate traffic, as long as we do tolerate a .1-1us jitter. Beyond that, you do need some ixia-like solution. Cheers Luigi > This don't permit to test multi-queue NIC (or SMP packet-filter) on a > simple lab like this: > netmap sender =3D> freebsd router =3D> netmap receiver > > Regards, > > Olivier > --=20 -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+-------------------------------