From owner-freebsd-net@FreeBSD.ORG Sun Jul 27 02:12:31 2014 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 ESMTPS id 7B9DEF11; Sun, 27 Jul 2014 02:12:31 +0000 (UTC) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 38E13286E; Sun, 27 Jul 2014 02:12:31 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id rd18so5338061iec.28 for ; Sat, 26 Jul 2014 19:12:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=HtSrc/d+1GgFnj651IHlgCUrqswmkj3TRHr0HHgIGAQ=; b=sCifC/0U/AmUSJy1OssE2F3KFTmHQNYIWYCsotXWrH4icdL0RC4AREmEnnxoQrkHaW +Oo2/XOT8UNStOhamGbNVtXgb9R0ysE/R0LNdIHddmvsrnjv5BnIhDxdPx2jhffKJcYV x6hrS92DOdN34iUu2t0TgM18/yZMVrZsB5oq/Sxlymp2N9CjGzcNrhaIR+gRVuOvy4by B18uMlZ1EQbV+AzgWEDGQtyolmVAjKdtBtv8BYzjeAgR6MI/B6rjAsxfi9xg2sIKpMvu rQEs/Q3GyI/vbvL4tOlMqug+dlLixQpoNFc9lZUrwGxuRRsnhYEx+K5LZeREjX7jQW7t 9OAg== X-Received: by 10.50.80.45 with SMTP id o13mr18858224igx.7.1406427149649; Sat, 26 Jul 2014 19:12:29 -0700 (PDT) Received: from [10.0.0.215] ([96.234.167.12]) by mx.google.com with ESMTPSA id l9sm2836577ige.2.2014.07.26.19.12.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 26 Jul 2014 19:12:28 -0700 (PDT) Message-ID: <53D4600A.1010505@gmail.com> Date: Sat, 26 Jul 2014 22:12:26 -0400 From: John Jasen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: fastforward/routing: a 3 million packet-per-second system? References: <53CE80DD.9090109@gmail.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 27 Jul 2014 02:12:31 -0000 flowtables enabled. This is a 30 second burst of lock profiling, processed via: head -2 debug.lock.pref.stats.out-20140726-1 ; cat debug.lock.pref.stats.out-20140726-1 | sort -nk4 | tail debug.lock.prof.stats: max wait_max total wait_total count avg wait_avg cnt_hold cnt_lock name 0 0 4758 31 22444 0 0 0 103 /usr/src/sys/kern/sched_ule.c:886 (spin mutex:sched lock 11) 1 1 770 45 2833 0 0 0 115 /usr/src/sys/kern/sched_ule.c:886 (spin mutex:sched lock 6) 3 16 50 54 30 1 1 0 8 /usr/src/sys/dev/usb/usb_device.c:2783 (sleep mutex:Giant) 0 14 5 61 28 0 2 0 13 /usr/src/sys/dev/usb/usb_device.c:2758 (sleep mutex:Giant) 1 1 3219 68 10452 0 0 0 161 /usr/src/sys/kern/sched_ule.c:886 (spin mutex:sched lock 7) 12 4 446 100 154 2 0 0 46 /usr/src/sys/kern/kern_condvar.c:145 (sleep mutex:Giant) 1 0 84164 976 405264 0 0 0 2681 /usr/src/sys/kern/subr_turnstile.c:552 (spin mutex:turnstile chain) 4 3 12812430 262856 68940690 0 0 0 546014 /usr/src/sys/net/route.c:439 (sleep mutex:rtentry) 3 4 4683374 1274675 68940690 0 0 0 3433615 /usr/src/sys/netinet/ip_fastfwd.c:593 (sleep mutex:rtentry) 5 6 3513959 2106043 68940690 0 0 0 7509422 /usr/src/sys/netinet/in_rmx.c:114 (sleep mutex:rtentry) The high level overview of pmc output is also attached. Profile trace for function: __rw_rlock() [19.54%] Profile trace for function: _rw_runlock_cookie() [9.25%] Profile trace for function: __mtx_unlock_flags() [5.97%] Profile trace for function: memcpy() [5.68%] Profile trace for function: bcopy() [5.53%] Profile trace for function: bcmp() [5.09%] Profile trace for function: _mtx_lock_spin_cookie() [4.77%] Profile trace for function: ip_fastforward() [4.27%] Profile trace for function: t4_eth_tx() [3.37%] Profile trace for function: rn_match() [2.92%] Profile trace for function: ether_output() [2.79%] Profile trace for function: rtalloc1_fib() [2.35%] Profile trace for function: get_scatter_segment() [1.68%] Profile trace for function: uma_zalloc_arg() [1.65%] Profile trace for function: rtfree() [1.58%] Profile trace for function: bzero() [1.54%] Profile trace for function: ether_nh_input() [1.47%] Profile trace for function: cxgbe_transmit() [1.39%] Profile trace for function: service_iq() [1.26%] Profile trace for function: rtalloc_ign_fib() [1.21%] Profile trace for function: __mtx_lock_sleep() [1.12%] Profile trace for function: arpresolve() [1.11%] Profile trace for function: uma_zfree_arg() [1.02%] Profile trace for function: reclaim_tx_descs() [0.92%] Profile trace for function: _mtx_trylock_flags_() [0.77%] Profile trace for function: bounce_bus_dmamap_load_buffer() [0.76%] Profile trace for function: ether_demux() [0.72%] Profile trace for function: mb_ctor_mbuf() [0.59%] Profile trace for function: in_localip() [0.51%] As usual, to save everyone's mail INBOX, the full output is available on request. Thanks again! On 07/25/2014 04:53 PM, Adrian Chadd wrote: > Yeah: > > Adrians-MacBook-Pro:Downloads adrian$ head -2 > debug.lock.prof.stats.out.20140725 ; cat > debug.lock.prof.stats.out.20140725 | sort -nk4 | tail -10 > > debug.lock.prof.stats: > > max wait_max total wait_total count avg wait_avg > cnt_hold cnt_lock name > > 6 3 419 145 160 2 0 > 0 63 /usr/src/sys/kern/kern_condvar.c:145 (sleep mutex:Giant) > > 282 133 991 215 8 123 26 > 0 2 /usr/src/sys/modules/cxgbe/if_cxgbe/../../../dev/cxgbe/t4_main.c:6657 > (sleep mutex:cxl3 txq26) > > 69 72 71 250 5 14 50 > 0 4 /usr/src/sys/modules/cxgbe/if_cxgbe/../../../dev/cxgbe/t4_main.c:6657 > (sleep mutex:cxl1 txq37) > > 281 197 1638 286 13 126 22 > 0 2 /usr/src/sys/modules/cxgbe/if_cxgbe/../../../dev/cxgbe/t4_main.c:6657 > (sleep mutex:cxl1 txq46) > > 351 182 2416 499 38 63 13 > 0 10 /usr/src/sys/modules/cxgbe/if_cxgbe/../../../dev/cxgbe/t4_main.c:6657 > (sleep mutex:cxl3 txq17) > > 276 193 802 643 10 80 64 > 0 5 /usr/src/sys/modules/cxgbe/if_cxgbe/../../../dev/cxgbe/t4_main.c:6657 > (sleep mutex:cxl3 txq27) > > 0 1 98578 1341 482441 0 0 > 0 3767 /usr/src/sys/kern/subr_turnstile.c:552 (spin mutex:turnstile > chain) > > 7 13 11543138 470545 63952832 0 0 > 0 815777 /usr/src/sys/net/route.c:439 (sleep mutex:rtentry) > > 6 15 3943582 1545195 63952779 0 0 > 0 3439254 /usr/src/sys/netinet/ip_fastfwd.c:593 (sleep mutex:rtentry) > > 7 17 3271389 2258698 63952832 0 0 > 0 6761237 /usr/src/sys/netinet/in_rmx.c:114 (sleep mutex:rtentry) > > .. try FLOWTABLE. > > The in_rmx.c is the hook to check for temporary routes installed by > redirect ICMP messages. It's .. not very pretty. Just use FLOWTABLE > for now and see if it improves things. > > (Yes, we likely can do better on the rtentry locking..) > > > -a > > > On 25 July 2014 13:51, Adrian Chadd wrote: >> Ugh, the forwarding table stupidity. Try enabling FLOWTABLE as an option. >> >> I really dislike how the rtentry locking works. But that isn't a >> rwlock - i'll have to look at your full lock profiling output to see. >> >> >> -a >> >> >> On 25 July 2014 09:20, John Jasen wrote: >>> Based on advice I received, I've collected lock profile debugging output, >>> and pmcannotate'd data from the system while it was processing about 3 >>> million packets/second. >>> >>> Combined, the files are about 325k in size, so I'll submit highlights here. >>> I can provide the raw files to interested parties privately. >>> >>> pmcannotate summary output: >>> >>> grep ^Profile pmcannotate.20140725 >>> Profile trace for function: __rw_rlock() [17.04%] >>> Profile trace for function: __mtx_unlock_flags() [9.10%] >>> Profile trace for function: _rw_runlock_cookie() [7.67%] >>> Profile trace for function: sched_idletd() [5.73%] >>> Profile trace for function: memcpy() [5.64%] >>> Profile trace for function: bcopy() [5.04%] >>> Profile trace for function: bcmp() [5.01%] >>> Profile trace for function: __mtx_lock_flags() [3.66%] >>> Profile trace for function: t4_eth_tx() [3.25%] >>> Profile trace for function: lock_profile_release_lock() [2.73%] >>> Profile trace for function: ip_fastforward() [2.68%] >>> Profile trace for function: ether_output() [2.50%] >>> Profile trace for function: get_scatter_segment() [1.75%] >>> Profile trace for function: rn_match() [1.74%] >>> Profile trace for function: _mtx_lock_spin_cookie() [1.53%] >>> Profile trace for function: lock_profile_obtain_lock_success() [1.49%] >>> Profile trace for function: cxgbe_transmit() [1.37%] >>> Profile trace for function: uma_zalloc_arg() [1.31%] >>> Profile trace for function: bzero() [1.30%] >>> Profile trace for function: service_iq() [1.26%] >>> Profile trace for function: ether_nh_input() [1.23%] >>> Profile trace for function: __mtx_lock_sleep() [1.19%] >>> Profile trace for function: arpresolve() [1.07%] >>> Profile trace for function: uma_zfree_arg() [0.95%] >>> Profile trace for function: reclaim_tx_descs() [0.87%] >>> Profile trace for function: _mtx_trylock_flags_() [0.80%] >>> Profile trace for function: bounce_bus_dmamap_load_buffer() [0.72%] >>> Profile trace for function: ether_demux() [0.64%] >>> Profile trace for function: mb_ctor_mbuf() [0.63%] >>> Profile trace for function: rtalloc1_fib() [0.54%] >>> >>> sysctl debug.lock.prof.stats summary: (some of the highest hit counts, >>> especially in cnt_hold: >>> >>> 7 17 3271389 2258698 63952832 0 0 0 >>> 6761237 /usr/src/sys/netinet/in_rmx.c:114 (sleep mutex:rtentry) >>> >>> 7 13 11543138 470545 63952832 0 0 0 >>> 815777 /usr/src/sys/net/route.c:439 (sleep mutex:rtentry) >>> >>> 6 15 3943582 1545195 63952779 0 0 0 >>> 3439254 /usr/src/sys/netinet/ip_fastfwd.c:593 (sleep mutex:rtentry >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Jul 22, 2014 at 11:18 AM, John Jasen wrote: >>> >>>> Feedback and/or tips and tricks more than welcome. >>>> >>> >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun Jul 27 02:20:01 2014 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 ESMTPS id 97A05FF6 for ; Sun, 27 Jul 2014 02:20:01 +0000 (UTC) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 56AAB2892 for ; Sun, 27 Jul 2014 02:20:01 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id j7so6365911qaq.28 for ; Sat, 26 Jul 2014 19:20:00 -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=8JbSqMnO8Trhw5HwA6kfRPI9AwCq2m9EBqZkr6LBB7Y=; b=rN3fYlnnDt1j8aG5OvrWC8rHTrBnF5h3zOosr2t8CNW6FT4j6/IjQCviNSFRJlVG2u M6mztOoYqHigTkVgPY/gTBh8E0sVCUPt7YS+wFuRwIbqS0ppNh9FlMnYlPJe67gLH7qa iivG6KnsIxp76hLWFVm6HLUfCyFW7l6VOcrueA5jQ0jZ1oXq5wSeeyLjhZbbQC4gizAL KoIYvYeokN92Wm/XTD3IdM16fKMtVxVP5FNnRQItyzRZkOiMaQ3tud8GvUXKfWaIuHl8 X6ilwwGwpv18RpNaIKV/ouBMOIWz/knKsP3ZKbix7dzuQD44ikwbzgcVmyphFR3BzVyC 6Hpw== MIME-Version: 1.0 X-Received: by 10.224.71.198 with SMTP id i6mr44228358qaj.76.1406427600433; Sat, 26 Jul 2014 19:20:00 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.1.6 with HTTP; Sat, 26 Jul 2014 19:20:00 -0700 (PDT) In-Reply-To: <53D4600A.1010505@gmail.com> References: <53CE80DD.9090109@gmail.com> <53D4600A.1010505@gmail.com> Date: Sat, 26 Jul 2014 19:20:00 -0700 X-Google-Sender-Auth: 8mHNfNI39Mk1Q8QfNwzsB2wNuZM Message-ID: Subject: Re: fastforward/routing: a 3 million packet-per-second system? From: Adrian Chadd To: John Jasen Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 27 Jul 2014 02:20:01 -0000 Flowtable is enabled? That's odd, it shouldn't be showing up like that. -a On 26 July 2014 19:12, John Jasen wrote: > flowtables enabled. This is a 30 second burst of lock profiling, > processed via: > head -2 debug.lock.pref.stats.out-20140726-1 ; cat > debug.lock.pref.stats.out-20140726-1 | sort -nk4 | tail > debug.lock.prof.stats: > > max wait_max total wait_total count avg wait_avg > cnt_hold cnt_lock name > 0 0 4758 31 22444 0 0 > 0 103 /usr/src/sys/kern/sched_ule.c:886 (spin mutex:sched lock 11) > 1 1 770 45 2833 0 0 > 0 115 /usr/src/sys/kern/sched_ule.c:886 (spin mutex:sched lock 6) > 3 16 50 54 30 1 1 > 0 8 /usr/src/sys/dev/usb/usb_device.c:2783 (sleep mutex:Giant) > 0 14 5 61 28 0 2 > 0 13 /usr/src/sys/dev/usb/usb_device.c:2758 (sleep mutex:Giant) > 1 1 3219 68 10452 0 0 > 0 161 /usr/src/sys/kern/sched_ule.c:886 (spin mutex:sched lock 7) > 12 4 446 100 154 2 0 > 0 46 /usr/src/sys/kern/kern_condvar.c:145 (sleep mutex:Giant) > 1 0 84164 976 405264 0 0 > 0 2681 /usr/src/sys/kern/subr_turnstile.c:552 (spin mutex:turnstile chain) > 4 3 12812430 262856 68940690 0 0 0 > 546014 /usr/src/sys/net/route.c:439 (sleep mutex:rtentry) > 3 4 4683374 1274675 68940690 0 0 0 > 3433615 /usr/src/sys/netinet/ip_fastfwd.c:593 (sleep mutex:rtentry) > 5 6 3513959 2106043 68940690 0 0 0 > 7509422 /usr/src/sys/netinet/in_rmx.c:114 (sleep mutex:rtentry) > > The high level overview of pmc output is also attached. > > Profile trace for function: __rw_rlock() [19.54%] > Profile trace for function: _rw_runlock_cookie() [9.25%] > Profile trace for function: __mtx_unlock_flags() [5.97%] > Profile trace for function: memcpy() [5.68%] > Profile trace for function: bcopy() [5.53%] > Profile trace for function: bcmp() [5.09%] > Profile trace for function: _mtx_lock_spin_cookie() [4.77%] > Profile trace for function: ip_fastforward() [4.27%] > Profile trace for function: t4_eth_tx() [3.37%] > Profile trace for function: rn_match() [2.92%] > Profile trace for function: ether_output() [2.79%] > Profile trace for function: rtalloc1_fib() [2.35%] > Profile trace for function: get_scatter_segment() [1.68%] > Profile trace for function: uma_zalloc_arg() [1.65%] > Profile trace for function: rtfree() [1.58%] > Profile trace for function: bzero() [1.54%] > Profile trace for function: ether_nh_input() [1.47%] > Profile trace for function: cxgbe_transmit() [1.39%] > Profile trace for function: service_iq() [1.26%] > Profile trace for function: rtalloc_ign_fib() [1.21%] > Profile trace for function: __mtx_lock_sleep() [1.12%] > Profile trace for function: arpresolve() [1.11%] > Profile trace for function: uma_zfree_arg() [1.02%] > Profile trace for function: reclaim_tx_descs() [0.92%] > Profile trace for function: _mtx_trylock_flags_() [0.77%] > Profile trace for function: bounce_bus_dmamap_load_buffer() [0.76%] > Profile trace for function: ether_demux() [0.72%] > Profile trace for function: mb_ctor_mbuf() [0.59%] > Profile trace for function: in_localip() [0.51%] > > As usual, to save everyone's mail INBOX, the full output is available on > request. > > Thanks again! > > > > > On 07/25/2014 04:53 PM, Adrian Chadd wrote: >> Yeah: >> >> Adrians-MacBook-Pro:Downloads adrian$ head -2 >> debug.lock.prof.stats.out.20140725 ; cat >> debug.lock.prof.stats.out.20140725 | sort -nk4 | tail -10 >> >> debug.lock.prof.stats: >> >> max wait_max total wait_total count avg wait_avg >> cnt_hold cnt_lock name >> >> 6 3 419 145 160 2 0 >> 0 63 /usr/src/sys/kern/kern_condvar.c:145 (sleep mutex:Giant) >> >> 282 133 991 215 8 123 26 >> 0 2 /usr/src/sys/modules/cxgbe/if_cxgbe/../../../dev/cxgbe/t4_main.c:6657 >> (sleep mutex:cxl3 txq26) >> >> 69 72 71 250 5 14 50 >> 0 4 /usr/src/sys/modules/cxgbe/if_cxgbe/../../../dev/cxgbe/t4_main.c:6657 >> (sleep mutex:cxl1 txq37) >> >> 281 197 1638 286 13 126 22 >> 0 2 /usr/src/sys/modules/cxgbe/if_cxgbe/../../../dev/cxgbe/t4_main.c:6657 >> (sleep mutex:cxl1 txq46) >> >> 351 182 2416 499 38 63 13 >> 0 10 /usr/src/sys/modules/cxgbe/if_cxgbe/../../../dev/cxgbe/t4_main.c:6657 >> (sleep mutex:cxl3 txq17) >> >> 276 193 802 643 10 80 64 >> 0 5 /usr/src/sys/modules/cxgbe/if_cxgbe/../../../dev/cxgbe/t4_main.c:6657 >> (sleep mutex:cxl3 txq27) >> >> 0 1 98578 1341 482441 0 0 >> 0 3767 /usr/src/sys/kern/subr_turnstile.c:552 (spin mutex:turnstile >> chain) >> >> 7 13 11543138 470545 63952832 0 0 >> 0 815777 /usr/src/sys/net/route.c:439 (sleep mutex:rtentry) >> >> 6 15 3943582 1545195 63952779 0 0 >> 0 3439254 /usr/src/sys/netinet/ip_fastfwd.c:593 (sleep mutex:rtentry) >> >> 7 17 3271389 2258698 63952832 0 0 >> 0 6761237 /usr/src/sys/netinet/in_rmx.c:114 (sleep mutex:rtentry) >> >> .. try FLOWTABLE. >> >> The in_rmx.c is the hook to check for temporary routes installed by >> redirect ICMP messages. It's .. not very pretty. Just use FLOWTABLE >> for now and see if it improves things. >> >> (Yes, we likely can do better on the rtentry locking..) >> >> >> -a >> >> >> On 25 July 2014 13:51, Adrian Chadd wrote: >>> Ugh, the forwarding table stupidity. Try enabling FLOWTABLE as an option. >>> >>> I really dislike how the rtentry locking works. But that isn't a >>> rwlock - i'll have to look at your full lock profiling output to see. >>> >>> >>> -a >>> >>> >>> On 25 July 2014 09:20, John Jasen wrote: >>>> Based on advice I received, I've collected lock profile debugging output, >>>> and pmcannotate'd data from the system while it was processing about 3 >>>> million packets/second. >>>> >>>> Combined, the files are about 325k in size, so I'll submit highlights here. >>>> I can provide the raw files to interested parties privately. >>>> >>>> pmcannotate summary output: >>>> >>>> grep ^Profile pmcannotate.20140725 >>>> Profile trace for function: __rw_rlock() [17.04%] >>>> Profile trace for function: __mtx_unlock_flags() [9.10%] >>>> Profile trace for function: _rw_runlock_cookie() [7.67%] >>>> Profile trace for function: sched_idletd() [5.73%] >>>> Profile trace for function: memcpy() [5.64%] >>>> Profile trace for function: bcopy() [5.04%] >>>> Profile trace for function: bcmp() [5.01%] >>>> Profile trace for function: __mtx_lock_flags() [3.66%] >>>> Profile trace for function: t4_eth_tx() [3.25%] >>>> Profile trace for function: lock_profile_release_lock() [2.73%] >>>> Profile trace for function: ip_fastforward() [2.68%] >>>> Profile trace for function: ether_output() [2.50%] >>>> Profile trace for function: get_scatter_segment() [1.75%] >>>> Profile trace for function: rn_match() [1.74%] >>>> Profile trace for function: _mtx_lock_spin_cookie() [1.53%] >>>> Profile trace for function: lock_profile_obtain_lock_success() [1.49%] >>>> Profile trace for function: cxgbe_transmit() [1.37%] >>>> Profile trace for function: uma_zalloc_arg() [1.31%] >>>> Profile trace for function: bzero() [1.30%] >>>> Profile trace for function: service_iq() [1.26%] >>>> Profile trace for function: ether_nh_input() [1.23%] >>>> Profile trace for function: __mtx_lock_sleep() [1.19%] >>>> Profile trace for function: arpresolve() [1.07%] >>>> Profile trace for function: uma_zfree_arg() [0.95%] >>>> Profile trace for function: reclaim_tx_descs() [0.87%] >>>> Profile trace for function: _mtx_trylock_flags_() [0.80%] >>>> Profile trace for function: bounce_bus_dmamap_load_buffer() [0.72%] >>>> Profile trace for function: ether_demux() [0.64%] >>>> Profile trace for function: mb_ctor_mbuf() [0.63%] >>>> Profile trace for function: rtalloc1_fib() [0.54%] >>>> >>>> sysctl debug.lock.prof.stats summary: (some of the highest hit counts, >>>> especially in cnt_hold: >>>> >>>> 7 17 3271389 2258698 63952832 0 0 0 >>>> 6761237 /usr/src/sys/netinet/in_rmx.c:114 (sleep mutex:rtentry) >>>> >>>> 7 13 11543138 470545 63952832 0 0 0 >>>> 815777 /usr/src/sys/net/route.c:439 (sleep mutex:rtentry) >>>> >>>> 6 15 3943582 1545195 63952779 0 0 0 >>>> 3439254 /usr/src/sys/netinet/ip_fastfwd.c:593 (sleep mutex:rtentry >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Tue, Jul 22, 2014 at 11:18 AM, John Jasen wrote: >>>> >>>>> Feedback and/or tips and tricks more than welcome. >>>>> >>>> >>>> _______________________________________________ >>>> freebsd-net@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Sun Jul 27 12:01:24 2014 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 ESMTPS id 6CCBC7B9 for ; Sun, 27 Jul 2014 12:01:24 +0000 (UTC) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1A24D2559 for ; Sun, 27 Jul 2014 12:01:23 +0000 (UTC) Received: from laptop3.herveybayaustralia.com.au (laptop3.herveybayaustralia.com.au [192.168.0.185]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id 7B3ED27371 for ; Sun, 27 Jul 2014 22:01:20 +1000 (EST) Message-ID: <53D4EA0F.9090302@herveybayaustralia.com.au> Date: Sun, 27 Jul 2014 22:01:19 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: systat -ifstat with missing statistics References: <53D39D9C.8040407@herveybayaustralia.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 27 Jul 2014 12:01:24 -0000 On 07/27/14 07:40, Adrian Chadd wrote: > Hi, > > Someone just needs to go through and audit which place(s) the physical > interface (ath0, iwn0, etc) and the VAPs (wlan0, wlan1, etc) should > have their interface statistics updated. > > I recall finding that this isn't consistently done by all NICs but > then I kinda got burnt out doing wifi stuff. I'd appreciate some help. How would one go about that exactly? I wouldn't mind getting a start on this somewhere if I can be mentored a bit :) One thing I'm studying atm is about hardware/firmware/software interfaces and drivers, for this very reason so that I can help in this area. > > Thanks, > > > > -a > > > On 26 July 2014 05:22, Da Rock wrote: >> I came across this in my late night searching that this was not new, but I >> can't seem to find it again. May not even have been on this list. I just >> wanted to say "me too". >> >> New install of FreeBSD 10, trying out the new wlan drivers and I wanted to >> see how fast it was actually going to compare with the old. Ran systat >> -ifstat and I only get half the results! >> >> I had some heavy network going, and it was going quite fast I know, just not >> how fast exactly. I could see the incoming but not the outgoing. >> Unfortunately my traffic was outgoing... I tried incoming after and got some >> good results, but still this is not a good position to be in. >> >> Anyone on this one? Or is a pr required? >> >> Cheers >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun Jul 27 12:58:39 2014 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 ESMTPS id 76A5B6F7; Sun, 27 Jul 2014 12:58:39 +0000 (UTC) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 376A229BA; Sun, 27 Jul 2014 12:58:39 +0000 (UTC) Received: by mail-ig0-f182.google.com with SMTP id c1so2575890igq.3 for ; Sun, 27 Jul 2014 05:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=jcGpyZHSuemqrMnt4dLQecbCKHrwo7NmLv+stc46XVw=; b=oD0Wtl9JokL2Y7cAiK5NR2q3QkQmFYZ3lDAZ5KKzTGqR3LpKXD0JlPgyQFqp9aPGOH 8JevRjlKRf9Zl7hPVTomINQ1bgPU6mmpbcYT09pQ6hZXwf/tj6Cca5plevZn3FZv1Cs6 bb5Fbm3KBuwxa/JbsMQsps6ain3ggkxpjrBvdD1arRVM06cr60ZxLs90tQfuMve3MKkH U7w0amfNhJulvXbgtS9fnnIdxRbwA8coE6szmL8WE/YvYeOtDKGEAoR0/MIoB4YIrqIH 8r5xlabW7duWU6ohKWCdkh98CFIN2xBPcpjst3+LtZhEgck9YLC9h1wj2CCCnK68Z178 HSPw== X-Received: by 10.50.6.36 with SMTP id x4mr11052930igx.47.1406465918613; Sun, 27 Jul 2014 05:58:38 -0700 (PDT) Received: from [10.0.0.215] ([96.234.167.12]) by mx.google.com with ESMTPSA id v8sm16192256igh.19.2014.07.27.05.58.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 27 Jul 2014 05:58:37 -0700 (PDT) Message-ID: <53D4F77B.9020009@gmail.com> Date: Sun, 27 Jul 2014 08:58:35 -0400 From: John Jasen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: fastforward/routing: a 3 million packet-per-second system? References: <53CE80DD.9090109@gmail.com> <53D4600A.1010505@gmail.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 27 Jul 2014 12:58:39 -0000 I shouldn't even be coming close to maxflows in this test scenario. net.flowtable.enable: 1 net.flowtable.maxflows: 1042468 On 07/26/2014 10:20 PM, Adrian Chadd wrote: > Flowtable is enabled? That's odd, it shouldn't be showing up like that. > > > > -a > > > From owner-freebsd-net@FreeBSD.ORG Sun Jul 27 15:03:18 2014 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 ESMTPS id 91634666 for ; Sun, 27 Jul 2014 15:03:18 +0000 (UTC) Received: from frv189.fwdcdn.com (frv189.fwdcdn.com [212.42.77.189]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D89A23C3 for ; Sun, 27 Jul 2014 15:03:18 +0000 (UTC) Received: from [10.10.1.29] (helo=frv197.fwdcdn.com) by frv189.fwdcdn.com with esmtp ID 1XBPiD-000GXA-T7 for net@freebsd.org; Sun, 27 Jul 2014 17:46:09 +0300 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:Cc:To:Subject:From:Date; bh=mYAGHFPQbN2S1N/XkZQ010SeQRv5XJjyaY4wYOgssc8=; b=ioLqbvEr0I3vmveSaN5FvcmifaQaHtvS8D3xcuH99qDoodOyGI8tqoktMr/rY2BlmqRwrLZXBpk6F5jBP7yPgR45cN9RQBofc9U5xWIEjlUzw/8utR1LEa1MX+kk2CuRJEjgSoKA9aUg2rMGR24MAPzenJZ7+c6zd5Fc0mJfl1s=; Received: from [10.10.10.35] (helo=frv35.fwdcdn.com) by frv197.fwdcdn.com with smtp ID 1XBPi3-000Cl3-FL for net@freebsd.org; Sun, 27 Jul 2014 17:45:59 +0300 Date: Sun, 27 Jul 2014 17:45:59 +0300 From: Vladislav Prodan Subject: Say me, please, how I can transfer between servers ZFS-partitions larger than 20Gb. To: questions@freebsd.org X-Mailer: mail.ukr.net 5.0 Message-Id: <1406471619.238727352.o7o2ccyx@frv35.fwdcdn.com> MIME-Version: 1.0 Received: from universite@ukr.net by frv35.fwdcdn.com; Sun, 27 Jul 2014 17:45:59 +0300 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary Content-Disposition: inline Cc: fs@freebsd.org, "net@freebsd.org net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 27 Jul 2014 15:03:18 -0000 Say me, please, how I can transfer between servers ZFS-partitions larger than 20Gb. I have 4 partitions with backup data. There are a lot of small pictures. NAME USED AVAIL REFER MOUNTPOINT tank2 1,42T 1,32T 118M legacy ... tank2/ay-files 31,9G 1,32T 31,8G /backup/beastie/upload_ftp/ay/files tank2/XXXXXmarket-images 135G 1,32T 135G /backup/beastie/upload_ftp/XXXXXmarket/images tank2/XXXXXmarket-uploads 17,6G 1,32T 17,5G /backup/beastie/upload_ftp/XXXXXmarket/uploads tank2/YYYYmarket 24,4G 1,32T 152K /backup/beastie/upload_ftp/YYYYmarket tank2/YYYYmarket/uploads 24,4G 1,32T 24,2G /backup/beastie/upload_ftp/YYYYmarket/uploads ... Say me, please, how I can transfer it at another server with ZFS. Servers are connected through unmanaged 100M switch. Sending via (zfs send) and (ssh host2 zfs recv) ends with error after 20GB of data. Sending via rsync is very lasting and requires often restart of rsync. What an alternative? -- Vladislav V. Prodan System & Network Administrator support.od.ua From owner-freebsd-net@FreeBSD.ORG Sun Jul 27 16:09:36 2014 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 ESMTPS id 3E687A4D; Sun, 27 Jul 2014 16:09:36 +0000 (UTC) Received: from denrei.darkbsd.org (denrei.darkbsd.org [IPv6:2001:41d0:1:f442::1]) by mx1.freebsd.org (Postfix) with ESMTP id E16F12918; Sun, 27 Jul 2014 16:09:35 +0000 (UTC) Received: from denrei.darkbsd.org (localhost [127.0.0.1]) by denrei.darkbsd.org (Postfix) with ESMTP id 5351116CB; Sun, 27 Jul 2014 18:09:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=darkbsd.org; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type; s=selector1; bh=9ziGo4FI2dwOOfTKymTjxF0m1YA=; b=A w0QwQEQN3103MLQL3ihknaG6teSBe6ANpkbT8EK5jULB5ly1llqyPesPzIsr4ZWV e4ym4MGJp+0/JOGOKslA5N1BltvNg5E4LiShoXHzmMucBk1RE6r4e9BnFTS3S+vF VJ3qGONh2qPQXHDga67iXJfN+n8lzpVnahhRx2mqWQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=darkbsd.org; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type; q=dns; s=selector1; b=giAu4V+82A77xxK9K4RfHNgPb0K eP0rbKkS96bfPxE5JFZ0Y+9JDp1m+jTByffk1296zdg4k+DUxgniyt5RvzPDpDMo M0YFLxQDU37NYqEkjb6KAJFoA63ZJZg0dgq6yTZ129f/62HuMZT24wPE8qEv6bEw 7qmJg3+sloMs/PgM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=darkbsd.org; h= content-type:content-type:in-reply-to:references:subject:subject :mime-version:user-agent:from:from:date:date:message-id:received :received; s=selector1; t=1406477370; bh=bEB9sTfAWicvBsqpyA0Y7wl bRFvKr+brzF+iesPqNrM=; b=igDWQGHdIrm5ZlHpN8jiNqYKzEi44E3WP7wLAgt igJIHG7k100xz2zaU+rX5YXahZ/FW4gLzmntCwx77RZ4ghgzYDBss/fRQYeKAI2E iwyqBj5XZwz2jXYGiVsPXVFFZX5HT9OrLmsmht8UhQ8aMvC0crKihvf/qEMboJOM TgQQ= X-Virus-Scanned: amavisd-new at darkbsd.org Received: from denrei.darkbsd.org ([127.0.0.1]) by denrei.darkbsd.org (denrei.darkbsd.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id nrSHC5BN46Nf; Sun, 27 Jul 2014 18:09:30 +0200 (CEST) Received: from [IPv6:2001:470:24:42d::42] (archer.yomi.darkbsd.org [IPv6:2001:470:24:42d::42]) (Authenticated sender: darksoul@darkbsd.org) by denrei.darkbsd.org (Postfix) with ESMTPSA id 2BED416CA; Sun, 27 Jul 2014 18:09:26 +0200 (CEST) Message-ID: <53D52434.7030308@darkbsd.org> Date: Mon, 28 Jul 2014 01:09:24 +0900 From: DarkSoul User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Vladislav Prodan , questions@freebsd.org Subject: Re: Say me, please, how I can transfer between servers ZFS-partitions larger than 20Gb. References: <1406471619.238727352.o7o2ccyx@frv35.fwdcdn.com> In-Reply-To: <1406471619.238727352.o7o2ccyx@frv35.fwdcdn.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5jXL8L7B7ukTrP2NGVQMs1IExhQWAeuPa" Cc: fs@freebsd.org, "net@freebsd.org net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 27 Jul 2014 16:09:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5jXL8L7B7ukTrP2NGVQMs1IExhQWAeuPa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 07/27/2014 11:45 PM, Vladislav Prodan wrote: > Say me, please, how I can transfer between servers ZFS-partitions large= r than 20Gb. > I have 4 partitions with backup data. There are a lot of small pictures= =2E > > NAME USED AVAIL REFER MOUNTPOINT > tank2 1,42T 1,32T 118M legacy > ... > tank2/ay-files 31,9G 1,32T 31,8G /backup/beas= tie/upload_ftp/ay/files > tank2/XXXXXmarket-images 135G 1,32T 135G /backup/beas= tie/upload_ftp/XXXXXmarket/images > tank2/XXXXXmarket-uploads 17,6G 1,32T 17,5G /backup/beas= tie/upload_ftp/XXXXXmarket/uploads > tank2/YYYYmarket 24,4G 1,32T 152K /backup/beas= tie/upload_ftp/YYYYmarket > tank2/YYYYmarket/uploads 24,4G 1,32T 24,2G /backup/beas= tie/upload_ftp/YYYYmarket/uploads > ... > > Say me, please, how I can transfer it at another server with ZFS. > Servers are connected through unmanaged 100M switch. > Sending via (zfs send) and (ssh host2 zfs recv) ends with error after 2= 0GB of data. > Sending via rsync is very lasting and requires often restart of rsync. > > What an alternative? For the initial 20G upload, you could zfs send to a file, and transfer that file via rsync or other resumable file transfer system that ensures integrity : host1# zfs send tank2/XXXXXmarket-images@snapshot > tank2-XXXXXmarket-images@snapshot.zfs host1# rsync tank2-XXXXXmarket-images@snapshot.zfs host2: host2# cat tank2-XXXXXmarket-images@snapshot.zfs | zfs recv tank3 Then the rest can be done via small snapshots and plain zfs send | ssh host2 zfs recv. You could even add bzip2 compression and decompression at each endpoint. This is what I am doing to replicate data of often updated filesystems (mailbox filesystems, with LOTS of small files) between ZFS servers. Cheers, > --=20 > Stephane LAPIE, EPITA SRS, Promo 2005 > "Even when they have digital readouts, I can't understand them." > --MegaTokyo > > --=20 > Stephane LAPIE, EPITA SRS, Promo 2005 > "Even when they have digital readouts, I can't understand them." > --MegaTokyo --5jXL8L7B7ukTrP2NGVQMs1IExhQWAeuPa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlPVJDQACgkQDJ4OK7D3FWR20wEAlEwxKf4EqYiLuYSTLua3Pkdo vGLQncD91yq63gc2CSoA/3skYXgw/ADY6Fq77LHEHxBnSeWhJYfID6Kd/pPtWy9B =1/W9 -----END PGP SIGNATURE----- --5jXL8L7B7ukTrP2NGVQMs1IExhQWAeuPa-- From owner-freebsd-net@FreeBSD.ORG Sun Jul 27 17:50:47 2014 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 ESMTPS id 3500B4CA for ; Sun, 27 Jul 2014 17:50:47 +0000 (UTC) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E772921D5 for ; Sun, 27 Jul 2014 17:50:46 +0000 (UTC) Received: by mail-qg0-f43.google.com with SMTP id a108so7445458qge.30 for ; Sun, 27 Jul 2014 10:50:45 -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=yo22lp2BsYDX6+fvcmgvtKwiTkRPBSgMZjoKZXQDMpg=; b=jGt3PTq2rmwIRnrBm9Byx2PAM2YVRQaBUlINlIdOJQYzGXQRnPG6ACAnh50zW5LYdo pZknx52TGFpqK6C3r1djXMBuOOuSiElZaXPCFq3AzZ7s2CyALuwi/j+1dyWAjpgTSPhq etDB76xDjrCN7PLKVAdfDJg2XM8nqiEECWK/L6aj0RqDVovwnVnIfNeXtjZIdKktA7fR kePxrWtzwKylbUVm6InUDLv9YazfL5DUV/52WpQ/YgRrEgL5Jm0fJBPIZLQTfpnGYtmt dfAV9uuyQHAFMvzo352ssq8tGTKYbcOqJGjHRRy23gKu5jwZaA8dOD5Oy35PpNUqWg1F 2UcQ== MIME-Version: 1.0 X-Received: by 10.140.107.4 with SMTP id g4mr38326836qgf.100.1406483445883; Sun, 27 Jul 2014 10:50:45 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.1.6 with HTTP; Sun, 27 Jul 2014 10:50:45 -0700 (PDT) In-Reply-To: <53D4F77B.9020009@gmail.com> References: <53CE80DD.9090109@gmail.com> <53D4600A.1010505@gmail.com> <53D4F77B.9020009@gmail.com> Date: Sun, 27 Jul 2014 10:50:45 -0700 X-Google-Sender-Auth: hMEAHDsePMohKwLBZpK2lnaXjhI Message-ID: Subject: Re: fastforward/routing: a 3 million packet-per-second system? From: Adrian Chadd To: John Jasen Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 27 Jul 2014 17:50:47 -0000 Yeah, there's something odd going on. You shouldn't see any of that lock contention if flowtable is enabled. Thus I think there's Oh wait, the fastfwd code doesn't know about flowtables. I just looked at it (sys/netinet/ip_fastfwd.c.) Try disabling fastfwd for a test and see if the lock profile improves. (Set debug.lock.prof.reset=1 to clear the profiling data before you do it.) -a On 27 July 2014 05:58, John Jasen wrote: > I shouldn't even be coming close to maxflows in this test scenario. > > net.flowtable.enable: 1 > net.flowtable.maxflows: 1042468 > > On 07/26/2014 10:20 PM, Adrian Chadd wrote: >> Flowtable is enabled? That's odd, it shouldn't be showing up like that. >> >> >> >> -a >> >> >> > From owner-freebsd-net@FreeBSD.ORG Sun Jul 27 18:08:51 2014 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 ESMTPS id C8DE9B6E; Sun, 27 Jul 2014 18:08:50 +0000 (UTC) Received: from relay2-bcrtfl2.verio.net (relay2-bcrtfl2.verio.net [131.103.218.177]) by mx1.freebsd.org (Postfix) with ESMTP id A92122388; Sun, 27 Jul 2014 18:08:50 +0000 (UTC) Received: from iad-wprd-xchw02.corp.verio.net (iad-wprd-xchw02.corp.verio.net [198.87.7.165]) by relay2-bcrtfl2.verio.net (Postfix) with ESMTP id 0FAC11FF00E8; Sun, 27 Jul 2014 13:41:46 -0400 (EDT) Received: from IAD-WPRD-XCHB01.corp.verio.net ([198.87.7.137]) by iad-wprd-xchw02.corp.verio.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 27 Jul 2014 13:41:45 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Content-Class: urn:content-classes:message Importance: normal Priority: normal MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: RE: Say me, please, how I can transfer between servers ZFS-partitions larger than 20Gb. Date: Sun, 27 Jul 2014 13:41:42 -0400 Message-ID: In-Reply-To: <1406471619.238727352.o7o2ccyx@frv35.fwdcdn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Say me, please, how I can transfer between servers ZFS-partitions larger than 20Gb. thread-index: Ac+pq/ouBkZN3D0USAGHxOeJGDC1jQAFeDjQ References: <1406471619.238727352.o7o2ccyx@frv35.fwdcdn.com> From: "David DeSimone" To: "Vladislav Prodan" , X-OriginalArrivalTime: 27 Jul 2014 17:41:45.0551 (UTC) FILETIME=[08ECA5F0:01CFA9C2] Cc: fs@freebsd.org, net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 27 Jul 2014 18:08:52 -0000 Mark Martinec just reported this problem a few days ago, and he found a = work-around. See the following: http://lists.freebsd.org/pipermail/freebsd-net/2014-July/039347.html -----Original Message----- From: owner-freebsd-net@freebsd.org = [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Vladislav Prodan Sent: Sunday, July 27, 2014 9:46 AM To: questions@freebsd.org Cc: fs@freebsd.org; net@freebsd.org net@freebsd.org Subject: Say me, please, how I can transfer between servers = ZFS-partitions larger than 20Gb. Say me, please, how I can transfer between servers ZFS-partitions larger = than 20Gb. I have 4 partitions with backup data. There are a lot of small pictures. NAME USED AVAIL REFER MOUNTPOINT tank2 1,42T 1,32T 118M legacy ... tank2/ay-files 31,9G 1,32T 31,8G = /backup/beastie/upload_ftp/ay/files tank2/XXXXXmarket-images 135G 1,32T 135G = /backup/beastie/upload_ftp/XXXXXmarket/images tank2/XXXXXmarket-uploads 17,6G 1,32T 17,5G = /backup/beastie/upload_ftp/XXXXXmarket/uploads tank2/YYYYmarket 24,4G 1,32T 152K = /backup/beastie/upload_ftp/YYYYmarket tank2/YYYYmarket/uploads 24,4G 1,32T 24,2G = /backup/beastie/upload_ftp/YYYYmarket/uploads ... Say me, please, how I can transfer it at another server with ZFS. Servers are connected through unmanaged 100M switch. Sending via (zfs send) and (ssh host2 zfs recv) ends with error after = 20GB of data. Sending via rsync is very lasting and requires often restart of rsync. What an alternative? -- Vladislav V. Prodan System & Network Administrator support.od.ua _______________________________________________ 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" This email message is intended for the use of the person to whom it has = been sent, and may contain information that is confidential or legally = protected. If you are not the intended recipient or have received this = message in error, you are not authorized to copy, distribute, or = otherwise use this message or its attachments. Please notify the sender = immediately by return e-mail and permanently delete this message and any = attachments. Verio Inc. makes no warranty that this email is error or = virus free. Thank you. From owner-freebsd-net@FreeBSD.ORG Sun Jul 27 20:31:52 2014 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 ESMTPS id 7DD467F0 for ; Sun, 27 Jul 2014 20:31:52 +0000 (UTC) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5694D255D for ; Sun, 27 Jul 2014 20:31:52 +0000 (UTC) Received: from a6.norwich.yourspac.nsdsl.net ([94.229.131.101]:51421 helo=[10.3.6.18]) by vps.hungerhost.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1XBV6i-00053E-1F for net@freebsd.org; Sun, 27 Jul 2014 16:31:48 -0400 From: "George Neville-Neil" To: net@freebsd.org Subject: Call for PF and IPFW rulesets Date: Sun, 27 Jul 2014 21:31:37 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.8r4214) 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 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 27 Jul 2014 20:31:52 -0000 Howdy, I am currently doing performance comparisons and related work on PF in FreeBSD. While I can certainly hand craft a bunch of rulesets that should be equivalent on both systems I'm putting out a call to those who might be willing to share some real world rulesets with me and the rest of the community. I'll be putting these into the netperf project I've started on GitHub, so, realize that these will be public. https://github.com/gvnn3/netperf The rulesets will also be used in papers and other material. Please email me off list if you have things you are willing to share. Best, George From owner-freebsd-net@FreeBSD.ORG Sun Jul 27 20:38:20 2014 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 ESMTPS id 53B9A94C; Sun, 27 Jul 2014 20:38:20 +0000 (UTC) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 27C3925A5; Sun, 27 Jul 2014 20:38:19 +0000 (UTC) Received: from a6.norwich.yourspac.nsdsl.net ([94.229.131.101]:51458 helo=[10.3.6.18]) by vps.hungerhost.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1XBVCy-00069X-Ga; Sun, 27 Jul 2014 16:38:16 -0400 From: "George Neville-Neil" To: "Garrett Cooper" Subject: Re: A new way to test systems in multiple machine scenarios... Date: Sun, 27 Jul 2014 21:38:05 +0100 Message-ID: <9207F596-D12C-4624-932C-631E47D40D66@neville-neil.com> In-Reply-To: <19D0342C-3635-4DC1-ACB8-5697F1D579F0@gmail.com> References: <19D0342C-3635-4DC1-ACB8-5697F1D579F0@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.8r4214) 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: "testing@freebsd.org" , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 27 Jul 2014 20:38:20 -0000 On 6 Jul 2014, at 4:52, Garrett Cooper wrote: >> On Jul 5, 2014, at 20:04, "George Neville-Neil" >> wrote: >> >> Hi, >> >> I've coded up a system to allow you to control multiple other systems >> for use in testing. >> >> https://github.com/gvnn3/conductor >> >> It's BSD licensed, of course, and is only alpha quality but I'm using >> it in the test lab >> to control hosts in forwarding tests. >> >> I'll be updating the system frequently over the coming months as I >> build out more test scenarios, >> add documentation and the like. >> >> There are two main scripts, player, and conductor. You run N >> players, one per machine, and >> a single conductor. The conductor controls the players by sending >> down phases which are >> encoded in INI style configs. There are a few, simple, samples in >> the config/ directory >> of the project. >> >> Best, >> George >> >> NOTE: Conductor MUST run as root to be useful. Do NOT run on the >> open Internet. It is meant >> for private test labs. > > I took a quick glance at the code -- have you considered using > multiprocessing managers instead? > > https://docs.python.org/2/library/multiprocessing.html#managers I had not. Thanks. I'll give it a look over. Best, George From owner-freebsd-net@FreeBSD.ORG Sun Jul 27 20:42:35 2014 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 ESMTPS id 65886A23; Sun, 27 Jul 2014 20:42:35 +0000 (UTC) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 34580263E; Sun, 27 Jul 2014 20:42:34 +0000 (UTC) Received: from a6.norwich.yourspac.nsdsl.net ([94.229.131.101]:51487 helo=[10.3.6.18]) by vps.hungerhost.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1XBVH6-0006vB-KO; Sun, 27 Jul 2014 16:42:33 -0400 From: "George Neville-Neil" To: "Adrian Chadd" Subject: Re: fastforward/routing: a 3 million packet-per-second system? Date: Sun, 27 Jul 2014 21:42:17 +0100 Message-ID: <83597B15-63B3-4AD7-A458-00B67C9E5396@neville-neil.com> In-Reply-To: References: <53CE80DD.9090109@gmail.com> <53CEB090.7030701@gmail.com> <53CEB670.9060600@gmail.com> <53CEB9B5.7020609@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.8r4214) 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: FreeBSD Net , Navdeep Parhar , John Jasen X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 27 Jul 2014 20:42:35 -0000 On 22 Jul 2014, at 20:30, Adrian Chadd wrote: > hi! > > You can use 'pmcstat -S CPU_CLK_UNHALTED_CORE -O pmc.out' (then ctrl-C > it after say 5 seconds), which will log the data to pmc.out; > then 'pmcannotate -k /boot/kernel pmc.out /boot/kernel/kernel' to find > out where the most cpu cycles are being spent. > Chiming in late, but don't you mean instruction-retired instead of CPU_CLK_UNHALTED_CORE? Best, George > It should give us the location(s) inside the top CPU users. > > Hopefully it'll then be much more obvious! > > I'm glad you're digging into it! > > -a > > > > On 22 July 2014 12:21, John Jasen wrote: >> Navdeep; >> >> I was struck by spending so much time in transmit as well. >> >> Adrian's suggestion on mining lock profiling gave me an excuse to up >> the >> tx queues in /boot/loader.conf. Our prior conversations indicated >> that >> up to 64 should be acceptable? >> >> >> >> >> >> On 07/22/2014 03:10 PM, Adrian Chadd wrote: >>> Hi >>> >>> Right. Time to figure out why you're spending so much time in >>> cxgbe_transmit() and t4_eth_tx(). Maybe ask Navdeep for some ideas? >>> >>> >>> -a >>> >>> On 22 July 2014 12:07, John Jasen wrote: >>>> The first is pretty easy to turn around. Reading on dtrace now. >>>> Thanks >>>> for the pointers and help! >>>> >>>> PMC: [CPU_CLK_UNHALTED_CORE] Samples: 142654 (100.0%) , 124560 >>>> unresolved >>>> >>>> %SAMP IMAGE FUNCTION CALLERS >>>> 34.0 if_cxgbe.k t4_eth_tx cxgbe_transmit:24.0 >>>> t4_tx_task:10.0 >>>> 28.8 if_cxgbe.k cxgbe_transmit >>>> 7.6 if_cxgbe.k service_iq t4_intr >>>> 6.4 if_cxgbe.k get_scatter_segment service_iq >>>> 4.9 if_cxgbe.k reclaim_tx_descs t4_eth_tx >>>> 3.2 if_cxgbe.k write_sgl_to_txd t4_eth_tx >>>> 2.8 hwpmc.ko pmclog_process_callc pmc_process_samples >>>> 2.1 libc.so.7 bcopy pmclog_read >>>> 1.9 if_cxgbe.k t4_eth_rx service_iq >>>> 1.7 hwpmc.ko pmclog_reserve pmclog_process_callchain >>>> 1.2 libpmc.so. pmclog_read >>>> 1.0 if_cxgbe.k write_txpkts_wr t4_eth_tx >>>> 0.8 kernel e1000_read_i2c_byte_ e1000_set_i2c_bb >>>> 0.6 libc.so.7 memset >>>> 0.5 if_cxgbe.k refill_fl service_iq >>>> >>>> >>>> >>>> >>>> On 07/22/2014 02:45 PM, Adrian Chadd wrote: >>>>> Hi, >>>>> >>>>> Well, start with CPU profiling with pmc: >>>>> >>>>> kldload hwpmc >>>>> pmcstat -S CPU_CLK_UNHALTED_CORE -T -w 1 >>>>> >>>>> .. look at the freebsd dtrace onliners (google that) for lock >>>>> contention and CPU usage. >>>>> >>>>> You could compile with LOCK_PROFILING (which will slow things down >>>>> a >>>>> little even when not in use) then enable it for a few seconds >>>>> (which >>>>> will definitely slow things down) to gather fine grained lock >>>>> contention data. >>>>> >>>>> (sysctl debug.lock.prof when you have it compiled in. sysctl >>>>> debug.lock.prof.enable=1; wait 10 seconds; sysctl >>>>> debug.lock.prof.enable=0; sysctl debug.lock.prof.stats) >>>>> >>>>> >>>>> -a >>>>> >>>>> >>>>> On 22 July 2014 11:42, John Jasen wrote: >>>>>> If you have ideas on what to instrument, I'll be happy to do it. >>>>>> >>>>>> I'm faintly familiar with dtrace, et al, so it might take me a >>>>>> few tries >>>>>> to get it right -- or bludgeoning with the documentation. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 07/22/2014 02:07 PM, Adrian Chadd wrote: >>>>>>> Hi! >>>>>>> >>>>>>> Well, what's missing is some dtrace/pmc/lockdebugging >>>>>>> investigations >>>>>>> into the system to see where it's currently maxing out at. >>>>>>> >>>>>>> I wonder if you're seeing contention on the transmit paths as >>>>>>> drivers >>>>>>> queue frames from one set of driver threads/queues to another >>>>>>> potentially completely different set of driver transmit >>>>>>> threads/queues. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -a >>>>>>> >>>>>>> >>>>>>> On 22 July 2014 08:18, John Jasen wrote: >>>>>>>> Feedback and/or tips and tricks more than welcome. >>>>>>>> >>>>>>>> Outstanding questions: >>>>>>>> >>>>>>>> Would increasing the number of processor cores help? >>>>>>>> >>>>>>>> Would a system where both processor QPI ports connect to each >>>>>>>> other >>>>>>>> mitigate QPI bottlenecks? >>>>>>>> >>>>>>>> Are there further performance optimizations I am missing? >>>>>>>> >>>>>>>> Server Description: >>>>>>>> >>>>>>>> The system in question is a Dell Poweredge R820, 16GB of RAM, >>>>>>>> and two >>>>>>>> Intel(R) Xeon(R) CPU E5-4610 0 @ 2.40GHz. >>>>>>>> >>>>>>>> Onboard, in a 16x PCIe slot, I have one Chelsio T-580-CR >>>>>>>> two-port 40GbE >>>>>>>> NIC, and in an 8x slot, another T-580-CR dual port. >>>>>>>> >>>>>>>> I am running FreeBSD 10.0-STABLE. >>>>>>>> >>>>>>>> BIOS tweaks: >>>>>>>> >>>>>>>> Hyperthreading (or Logical Processors) is turned off. >>>>>>>> Memory Node Interleaving is turned off, but did not appear to >>>>>>>> impact >>>>>>>> performance. >>>>>>>> >>>>>>>> /boot/loader.conf contents: >>>>>>>> #for CARP+PF testing >>>>>>>> carp_load="YES" >>>>>>>> #load cxgbe drivers. >>>>>>>> cxgbe_load="YES" >>>>>>>> #maxthreads appears to not exceed CPU. >>>>>>>> net.isr.maxthreads=12 >>>>>>>> #bindthreads may be indicated when using cpuset(1) on >>>>>>>> interrupts >>>>>>>> net.isr.bindthreads=1 >>>>>>>> #random guess based on googling >>>>>>>> net.isr.maxqlimit=60480 >>>>>>>> net.link.ifqmaxlen=90000 >>>>>>>> #discussions with cxgbe maintainer and list led me to trying >>>>>>>> this. >>>>>>>> Allows more interrupts >>>>>>>> #to be fixed to CPUs, which in some cases, improves interrupt >>>>>>>> balancing. >>>>>>>> hw.cxgbe.ntxq10g=16 >>>>>>>> hw.cxgbe.nrxq10g=16 >>>>>>>> >>>>>>>> /etc/sysctl.conf contents: >>>>>>>> >>>>>>>> #the following is also enabled by rc.conf gateway_enable. >>>>>>>> net.inet.ip.fastforwarding=1 >>>>>>>> #recommendations from BSD router project >>>>>>>> kern.random.sys.harvest.ethernet=0 >>>>>>>> kern.random.sys.harvest.point_to_point=0 >>>>>>>> kern.random.sys.harvest.interrupt=0 >>>>>>>> #probably should be removed, as cxgbe does not seem to >>>>>>>> affect/be >>>>>>>> affected by irq storm settings >>>>>>>> hw.intr_storm_threshold=25000000 >>>>>>>> #based on Calomel.Org performance suggestions. 4x40GbE, seemed >>>>>>>> reasonable to use 100GbE settings >>>>>>>> kern.ipc.maxsockbuf=1258291200 >>>>>>>> net.inet.tcp.recvbuf_max=1258291200 >>>>>>>> net.inet.tcp.sendbuf_max=1258291200 >>>>>>>> #attempting to play with ULE scheduler, making it serve packets >>>>>>>> versus >>>>>>>> netstat >>>>>>>> kern.sched.slice=1 >>>>>>>> kern.sched.interact=1 >>>>>>>> >>>>>>>> /etc/rc.conf contains: >>>>>>>> >>>>>>>> hostname="fbge1" >>>>>>>> #should remove, especially given below duplicate entry >>>>>>>> ifconfig_igb0="DHCP" >>>>>>>> sshd_enable="YES" >>>>>>>> #ntpd_enable="YES" >>>>>>>> # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable >>>>>>>> dumpdev="AUTO" >>>>>>>> # OpenBSD PF options to play with later. very bad for raw >>>>>>>> packet rates. >>>>>>>> #pf_enable="YES" >>>>>>>> #pflog_enable="YES" >>>>>>>> # enable packet forwarding >>>>>>>> # these enable forwarding and fastforwarding sysctls. inet6 >>>>>>>> does not >>>>>>>> have fastforward >>>>>>>> gateway_enable="YES" >>>>>>>> ipv6_gateway_enable="YES" >>>>>>>> # enable OpenBSD ftp-proxy >>>>>>>> # should comment out until actively playing with PF >>>>>>>> ftpproxy_enable="YES" >>>>>>>> #left in place, commented out from prior testing >>>>>>>> #ifconfig_mlxen1="inet 172.16.2.1 netmask 255.255.255.0 mtu >>>>>>>> 9000" >>>>>>>> #ifconfig_mlxen0="inet 172.16.1.1 netmask 255.255.255.0 mtu >>>>>>>> 9000" >>>>>>>> #ifconfig_mlxen3="inet 172.16.7.1 netmask 255.255.255.0 mtu >>>>>>>> 9000" >>>>>>>> #ifconfig_mlxen2="inet 172.16.8.1 netmask 255.255.255.0 mtu >>>>>>>> 9000" >>>>>>>> # -lro and -tso options added per mailing list suggestion from >>>>>>>> Bjoern A. >>>>>>>> Zeeb (bzeeb-lists at lists.zabbadoz.net) >>>>>>>> ifconfig_cxl0="inet 172.16.3.1 netmask 255.255.255.0 mtu 9000 >>>>>>>> -lro -tso up" >>>>>>>> ifconfig_cxl1="inet 172.16.4.1 netmask 255.255.255.0 mtu 9000 >>>>>>>> -lro -tso up" >>>>>>>> ifconfig_cxl2="inet 172.16.5.1 netmask 255.255.255.0 mtu 9000 >>>>>>>> -lro -tso up" >>>>>>>> ifconfig_cxl3="inet 172.16.6.1 netmask 255.255.255.0 mtu 9000 >>>>>>>> -lro -tso up" >>>>>>>> # aliases instead of reconfiguring test clients. See above >>>>>>>> commented out >>>>>>>> entries >>>>>>>> ifconfig_cxl0_alias0="172.16.7.1 netmask 255.255.255.0" >>>>>>>> ifconfig_cxl1_alias0="172.16.8.1 netmask 255.255.255.0" >>>>>>>> ifconfig_cxl2_alias0="172.16.1.1 netmask 255.255.255.0" >>>>>>>> ifconfig_cxl3_alias0="172.16.2.1 netmask 255.255.255.0" >>>>>>>> # for remote monitoring/admin of the test device >>>>>>>> ifconfig_igb0="inet 172.30.60.60 netmask 255.255.0.0" >>>>>>>> >>>>>>>> Additional configurations: >>>>>>>> cpuset-chelsio-6cpu-high >>>>>>>> # Original provided by Navdeep Parhar >>>>>>>> # takes vmstat -ai output into a list, and assigns interrupts >>>>>>>> in order to >>>>>>>> # the available CPU cores. >>>>>>>> # Modified: to assign only to the 'high CPUs', ie: on core1. >>>>>>>> # See: >>>>>>>> http://lists.freebsd.org/pipermail/freebsd-net/2014-July/039317.html >>>>>>>> #!/usr/local/bin/bash >>>>>>>> ncpu=12 >>>>>>>> irqlist=$(vmstat -ia | egrep 't4nex|t5nex|cxgbc' | cut -f1 -d: >>>>>>>> | cut -c4-) >>>>>>>> i=6 >>>>>>>> for irq in $irqlist; do >>>>>>>> cpuset -l $i -x $irq >>>>>>>> i=$((i+1)) >>>>>>>> [ $i -ge $ncpu ] && i=6 >>>>>>>> done >>>>>>>> >>>>>>>> Client Description: >>>>>>>> >>>>>>>> Two Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz processors >>>>>>>> 64 GB ram >>>>>>>> Mellanox Technologies MT27500 Family [ConnectX-3] >>>>>>>> Centos 6.4 with updates >>>>>>>> iperf3 installed from yum repositories: >>>>>>>> iperf3-3.0.3-3.el6.x86_64 >>>>>>>> >>>>>>>> Test setup: >>>>>>>> >>>>>>>> I've found about 3 streams between Centos clients is about the >>>>>>>> best way >>>>>>>> to get the most out of them. >>>>>>>> Above certain points, the -b flag does not change results. >>>>>>>> -N is an artifact from using TCP >>>>>>>> -l is needed, as -M doesn't work for UDP. >>>>>>>> >>>>>>>> I usually use launch scripts similar to the following: >>>>>>>> >>>>>>>> for i in `seq 41 60`; do ssh loader$i "export TIME=120; export >>>>>>>> STREAMS=1; export PORT=52$i; export PKT=64; export RATE=2000m; >>>>>>>> /root/iperf-test-8port-udp" & done >>>>>>>> >>>>>>>> The scripts execute the following on each host. >>>>>>>> >>>>>>>> #!/bin/bash >>>>>>>> PORT1=$PORT >>>>>>>> PORT2=$(($PORT+1000)) >>>>>>>> PORT3=$(($PORT+2000)) >>>>>>>> iperf3 -c loader41-40gbe -u -b 10000m -i 0 -N -l $PKT -t$TIME >>>>>>>> -P$STREAMS -p$PORT1 & >>>>>>>> iperf3 -c loader42-40gbe -u -b 10000m -i 0 -N -l $PKT -t$TIME >>>>>>>> -P$STREAMS -p$PORT1 & >>>>>>>> iperf3 -c loader43-40gbe -u -b 10000m -i 0 -N -l $PKT -t$TIME >>>>>>>> -P$STREAMS -p$PORT1 & >>>>>>>> ... (through all clients and all three ports) ... >>>>>>>> iperf3 -c loader60-40gbe -u -b 10000m -i 0 -N -l $PKT -t$TIME >>>>>>>> -P$STREAMS -p$PORT3 & >>>>>>>> >>>>>>>> >>>>>>>> Results: >>>>>>>> >>>>>>>> Summarized, netstat -w 1 -q 240 -bd, run through: >>>>>>>> cat test4-tuning | egrep -v {'packets | input '} | awk >>>>>>>> '{ipackets+=$1} >>>>>>>> {idrops+=$3} {opackets+=$5} {odrops+=$9} END {print "input " >>>>>>>> ipackets/NR, "idrops " idrops/NR, "opackets " opackets/NR, >>>>>>>> "odrops " >>>>>>>> odrops/NR}' >>>>>>>> >>>>>>>> input 1.10662e+07 idrops 8.01783e+06 opackets 3.04516e+06 >>>>>>>> odrops 3152.4 >>>>>>>> >>>>>>>> Snapshot of raw output: >>>>>>>> >>>>>>>> input (Total) output >>>>>>>> packets errs idrops bytes packets errs bytes >>>>>>>> colls drops >>>>>>>> 11189148 0 7462453 1230805216 3725006 0 409750710 >>>>>>>> 0 799 >>>>>>>> 10527505 0 6746901 1158024978 3779096 0 415700708 >>>>>>>> 0 127 >>>>>>>> 10606163 0 6850760 1166676673 3751780 0 412695761 >>>>>>>> 0 1535 >>>>>>>> 10749324 0 7132014 1182425799 3617558 0 397930956 >>>>>>>> 0 5972 >>>>>>>> 10695667 0 7022717 1176521907 3669342 0 403627236 >>>>>>>> 0 1461 >>>>>>>> 10441173 0 6762134 1148528662 3675048 0 404255540 >>>>>>>> 0 6021 >>>>>>>> 10683773 0 7005635 1175215014 3676962 0 404465671 >>>>>>>> 0 2606 >>>>>>>> 10869859 0 7208696 1195683372 3658432 0 402427698 >>>>>>>> 0 979 >>>>>>>> 11948989 0 8310926 1314387881 3633773 0 399714986 >>>>>>>> 0 725 >>>>>>>> 12426195 0 8864415 1366877194 3562311 0 391853156 >>>>>>>> 0 2762 >>>>>>>> 13006059 0 9432389 1430661751 3570067 0 392706552 >>>>>>>> 0 5158 >>>>>>>> 12822243 0 9098871 1410443600 3715177 0 408668500 >>>>>>>> 0 4064 >>>>>>>> 13317864 0 9683602 1464961374 3632156 0 399536131 >>>>>>>> 0 3684 >>>>>>>> 13701905 0 10182562 1507207982 3523101 0 387540859 >>>>>>>> 0 >>>>>>>> 8690 >>>>>>>> 13820227 0 10244870 1520221820 3562038 0 391823322 >>>>>>>> 0 >>>>>>>> 2426 >>>>>>>> 14437060 0 10955483 1588073033 3480105 0 382810557 >>>>>>>> 0 >>>>>>>> 2619 >>>>>>>> 14518471 0 11119573 1597028105 3397439 0 373717355 >>>>>>>> 0 >>>>>>>> 5691 >>>>>>>> 14890287 0 11675003 1637926521 3199812 0 351978304 >>>>>>>> 0 >>>>>>>> 11007 >>>>>>>> 14923610 0 11749091 1641594441 3171436 0 348857468 >>>>>>>> 0 >>>>>>>> 7389 >>>>>>>> 14738704 0 11609730 1621254991 3117715 0 342948394 >>>>>>>> 0 >>>>>>>> 2597 >>>>>>>> 14753975 0 11549735 1622935026 3207393 0 352812846 >>>>>>>> 0 >>>>>>>> 4798 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> freebsd-net@freebsd.org mailing list >>>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>>>>>> To unsubscribe, send any mail to >>>>>>>> "freebsd-net-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun Jul 27 21:27:14 2014 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 ESMTPS id F303494D for ; Sun, 27 Jul 2014 21:27:14 +0000 (UTC) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AFB9229EF for ; Sun, 27 Jul 2014 21:27:14 +0000 (UTC) Received: by mail-qa0-f46.google.com with SMTP id v10so7060873qac.19 for ; Sun, 27 Jul 2014 14:27:13 -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=5Vo3hlRl8Ue5Y7IJ2Ix5Iog+Rlv7xT4UzyP12UqQ5Sk=; b=fJX0haNtgXlNfSIr2+FTLeSqACBWvbvdRdxyAXV6hpNZ4hM2AUkAhvzLUtwuBa5ovh 1UXnnLVjoKceAniGcFNgWkb1I35Ot7riZkIYt+OckorteK797bx6D1KG2gFCNjTBJD+g 1x/330TkAoX0bwACV1D0suoCGsU4kZX9foL6yBLpPtvyxxonkbrRIcLr3t2BwOAJBxTB RKlQHFridwtYpyNpkDR1t74Q9YglB4E2F3TvSQckwNVTITjb9WMDY6jMN7irt83QYjfc 1U26/VUOwRZBJt2ZXPGWx3xoE0TaVL3gOkHecE2uSj4nSMZOvFT5YRWf+/SdIkOSRTzG NrbA== MIME-Version: 1.0 X-Received: by 10.140.38.169 with SMTP id t38mr51647991qgt.3.1406496433795; Sun, 27 Jul 2014 14:27:13 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.1.6 with HTTP; Sun, 27 Jul 2014 14:27:13 -0700 (PDT) In-Reply-To: <83597B15-63B3-4AD7-A458-00B67C9E5396@neville-neil.com> References: <53CE80DD.9090109@gmail.com> <53CEB090.7030701@gmail.com> <53CEB670.9060600@gmail.com> <53CEB9B5.7020609@gmail.com> <83597B15-63B3-4AD7-A458-00B67C9E5396@neville-neil.com> Date: Sun, 27 Jul 2014 14:27:13 -0700 X-Google-Sender-Auth: rZuEh8vVVwdh-zuCx0YsRnufHZs Message-ID: Subject: Re: fastforward/routing: a 3 million packet-per-second system? From: Adrian Chadd To: George Neville-Neil Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Net , Navdeep Parhar , John Jasen X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 27 Jul 2014 21:27:15 -0000 On 27 July 2014 13:42, George Neville-Neil wrote: > On 22 Jul 2014, at 20:30, Adrian Chadd wrote: > >> hi! >> >> You can use 'pmcstat -S CPU_CLK_UNHALTED_CORE -O pmc.out' (then ctrl-C >> it after say 5 seconds), which will log the data to pmc.out; >> then 'pmcannotate -k /boot/kernel pmc.out /boot/kernel/kernel' to find >> out where the most cpu cycles are being spent. >> > > Chiming in late, but don't you mean instruction-retired instead of > CPU_CLK_UNHALTED_CORE? Nope. the hardware retires instructions in parallel. That gives a different indication of a different class of bottlenecks. -a From owner-freebsd-net@FreeBSD.ORG Mon Jul 28 03:12:49 2014 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 ESMTPS id 1DBE3F91 for ; Mon, 28 Jul 2014 03:12:49 +0000 (UTC) Received: from quine.pinyon.org (quine.pinyon.org [65.101.5.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EB54D2895 for ; Mon, 28 Jul 2014 03:12:48 +0000 (UTC) Received: by quine.pinyon.org (Postfix, from userid 122) id C7905160364; Sun, 27 Jul 2014 20:03:15 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on quine.pinyon.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 Received: from feyerabend.n1.pinyon.org (feyerabend.n1.pinyon.org [10.0.10.6]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by quine.pinyon.org (Postfix) with ESMTPSA id B474016020E for ; Sun, 27 Jul 2014 20:03:13 -0700 (MST) Message-ID: <53D5BD71.40108@pinyon.org> Date: Sun, 27 Jul 2014 20:03:13 -0700 From: "Russell L. Carter" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: net@freebsd.org Subject: nfsd spam in /var/log/messages X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 28 Jul 2014 03:12:49 -0000 Hi, Still a newbie here after more than ae decade off. This is most likely a stupid question but I have invested an inordinate amount of effort to figure it out with no success. That is, I have not resorted to digging down into the source code to understand the error message. I will do so if I am the first person to ever see this. So the question(s): In order to support my linux NFSv4 clients AND my freebsd-current clients, after an extended boring trial and error session I ended up with a freebsd server /etc/exports: # Linux can mount nfsv4 ONLY if the line is exactly as # follows: V4: /export -sec=sys -network 10.0.10 -mask 255.255.255.0 /export/usr/src -maproot=root /export/usr/obj -maproot=root /export/usr/ports -maproot=root /export/packages -maproot=root /export/library -maproot=root This isn't about security so avert your eyes from the maproots. The security holes here are galaxy wide, I know. There's even wifi access to this network! Clutch yer perls. Here is an example of the /var/log/messages spam: Jul 27 11:19:32 terpsichore mountd[669]: bad exports list line /export/usr/obj Jul 27 11:19:32 terpsichore mountd[669]: can't change attributes for /export/usr/src: MNT_DEFEXPORTED already set for mount 0xfffff8022c3fdcc0 How do I stop this? I have iterated through many possibilities, to no avail. Best, Russell From owner-freebsd-net@FreeBSD.ORG Mon Jul 28 06:34:03 2014 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 ESMTPS id 51B7DF7C; Mon, 28 Jul 2014 06:34:03 +0000 (UTC) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 127F52491; Mon, 28 Jul 2014 06:34:02 +0000 (UTC) Received: from [2001:5c0:1000:a::e83] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XBeVM-0003NQ-63; Mon, 28 Jul 2014 08:33:52 +0200 Message-ID: <53D5DBD2.9050107@gont.com.ar> Date: Mon, 28 Jul 2014 01:12:50 -0400 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?UTF-8?B?56We5piO6YGU5ZOJ?= , Loganaden Velvindron Subject: Re: IPv6 nodeinfo default behaviour References: <20140720090410.GA7990@mx.elandsys.com> <20140722170150.GA971@mx.elandsys.com> <20140722193521.GA20775@mx.elandsys.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: FreeBSD Net , bz@freebsd.org, George Neville-Neil X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 28 Jul 2014 06:34:03 -0000 On 07/22/2014 04:38 PM, 神明達哉 wrote: > >>> usually subjective, and different people may have different opinions. >>> Personally, I often find "ping6 -w" quite useful for debugging >>> purposes, and I think limiting its use to link-local by default gives >> >> Agreed. Perhaps we should enable it only when we need to debug. >> >>> a reasonable level of defense (and, disabling it by default would >>> reduce the usability pretty much). So I'd rather prefer keeping the >>> current default, but, again, other people may have a different >>> preference. > > To be clear, in case I wasn't: in my opinion it would become useless > for debugging unless it's enabled by default, so I would like it to be > (kept) enabled by default (note that it's already limited to > link-local by default). But I understand YMMV. While node information message can be interesting at times, since they are only supported in BSDs and can only be used when on-link, it's not a debugging mechanism you can rely on. As a result of that, my 2cents would be "disable them by default". If in your particular setup woul'd benefit from them, you can always override such default on system installation. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From owner-freebsd-net@FreeBSD.ORG Mon Jul 28 08:00:12 2014 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 ESMTPS id C2C8A78F for ; Mon, 28 Jul 2014 08:00:12 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 97FD02D35 for ; Mon, 28 Jul 2014 08:00:12 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s6S80CX0062457 for ; Mon, 28 Jul 2014 08:00:12 GMT (envelope-from bugzilla-noreply@freebsd.org) Message-Id: <201407280800.s6S80CX0062457@kenobi.freebsd.org> From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bugzilla] Commit Needs MFC MIME-Version: 1.0 X-Bugzilla-Type: whine X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated Date: Mon, 28 Jul 2014 08:00:12 +0000 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 28 Jul 2014 08:00:12 -0000 Hi, You have a bug in the "Needs MFC" state which has not been touched in 7 or more days. This email serves as a reminder that you may want to MFC this bug or marked it as completed. In the event you have a longer MFC timeout you may update this bug with a comment and I won't remind you again for 7 days. This reminder is only sent on Mondays. Please file a bug about concerns you may have. This search was scheduled by eadler@FreeBSD.org. (1 bugs) Bug 183659: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183659 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-net@FreeBSD.org Status: Needs MFC Resolution: Summary: [tcp] TCP stack lock contention with short-lived connections From owner-freebsd-net@FreeBSD.ORG Mon Jul 28 08:08:34 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 21989C7B; Mon, 28 Jul 2014 08:08:34 +0000 (UTC) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id 5500828BA; Mon, 28 Jul 2014 08:08:31 +0000 (UTC) Message-ID: <53D604EA.2000203@FreeBSD.org> Date: Mon, 28 Jul 2014 12:08:10 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John Jasen , FreeBSD Net , "Alexander V. Chernikov" Subject: Re: fastforward/routing: a 3 million packet-per-second system? References: <53CE80DD.9090109@gmail.com> <53D0D0B2.6080600@yandex.ru> <53D10055.1050304@gmail.com> In-Reply-To: <53D10055.1050304@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 28 Jul 2014 08:08:34 -0000 On 24.07.2014 16:47, John Jasen wrote: > On 07/24/2014 05:24 AM, Andrey V. Elsukov wrote: >> On 22.07.2014 19:18, John Jasen wrote: >>> Feedback and/or tips and tricks more than welcome. >>> >>> Outstanding questions: >>> >>> Would increasing the number of processor cores help? >> AFAIR, increasing the number of cores will lead to worse results. >> With patched and tuned FreeBSD we able to route (with fastforwarding) >> about 7 Mpps IPv4 and 2.5Mpps IPv6. But the stock system is far from >> even half of this results. >> > > Increasing the physical CPU count can (and probably will) result in > performance degradation. However, from what I've seen, balancing IRQs > across the cores on a single physical CPU seems to help. > > I am curious as well, as to how you achieved 7 Mpps. Can you share the > system specs, the patches and tuning? Usually the systems have 2x8 cores (e.g. Intel Xeon E5-2660), 16-32G RAM, 2 ixgbe(4) network cards (82599EB). We slowly trying merge our patches to FreeBSD, but most of them are hackish and needs rethinking. We need reduce lock contention in routing code and optimize structures to fit cache lines. Some of patches were published here by melifaro@. Some are already committed. Also v6-related patches included in my svn branch user/ae/inet6. Tuning depends from your hardware. It is good to pin network adapter's taskq threads and interrupts. andre@ committed this functional recently in head/. -- WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Mon Jul 28 12:55:42 2014 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 ESMTPS id 8E78E2C8 for ; Mon, 28 Jul 2014 12:55:42 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 56DED25CE for ; Mon, 28 Jul 2014 12:55:41 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4EAJxF1lODaFve/2dsb2JhbABZg2BXBIJ0yQYKhnJTAYEod4QDAQEBAwEBAQEgKyALBRYYAgINGQIpAQkmBggHBAEcBIgZCA2maJZ9F4EsjU8BARs0B4J5gVEFlyqBMYRDknqDZSEvB4EFOQ X-IronPort-AV: E=Sophos;i="5.01,749,1400040000"; d="scan'208";a="144791919" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 28 Jul 2014 08:55:34 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id DD632B3EA2; Mon, 28 Jul 2014 08:55:34 -0400 (EDT) Date: Mon, 28 Jul 2014 08:55:34 -0400 (EDT) From: Rick Macklem To: "Russell L. Carter" Message-ID: <43564051.4211288.1406552134888.JavaMail.root@uoguelph.ca> In-Reply-To: <53D5BD71.40108@pinyon.org> Subject: Re: nfsd spam in /var/log/messages MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 28 Jul 2014 12:55:42 -0000 Russell L. Carter wrote: > Hi, > > Still a newbie here after more than ae decade off. This is most > likely a stupid question but I have invested an inordinate amount of > effort to figure it out with no success. That is, I have not > resorted > to digging down into the source code to understand the error message. > I will do so if I am the first person to ever see this. So the > question(s): > > In order to support my linux NFSv4 clients AND my freebsd-current > clients, after an extended boring trial and error session I ended up > with a freebsd server /etc/exports: > > # Linux can mount nfsv4 ONLY if the line is exactly as > # follows: Assuming /export is one file system on the server, put all the exports in a single entry, something like: V4: /export -sec=sys -network 10.0.10 -mask 255.255.255.0 /export/usr/src /export/usr/obj /export/usr/ports /export/packages /export/library -maproot=root OR you can just allow the clients to mount any location within the server file system using -alldirs like: V4: /export -sec=sys -network 10.0.10 -mask 255.255.255.0 /export -alldirs -maproot=root At least I think I got this correct;-) rick > This isn't about security so avert your eyes from the maproots. The > security holes here are galaxy wide, I know. There's even wifi > access > to this network! Clutch yer perls. > > Here is an example of the /var/log/messages spam: > > Jul 27 11:19:32 terpsichore mountd[669]: bad exports list line > /export/usr/obj > Jul 27 11:19:32 terpsichore mountd[669]: can't change attributes for > /export/usr/src: MNT_DEFEXPORTED already set for mount > 0xfffff8022c3fdcc0 > > How do I stop this? I have iterated through many possibilities, > to no avail. > > Best, > Russell > _______________________________________________ > 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 Jul 28 14:51:14 2014 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 ESMTPS id 28054B9; Mon, 28 Jul 2014 14:51:14 +0000 (UTC) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 743642407; Mon, 28 Jul 2014 14:51:13 +0000 (UTC) Received: by mail-lb0-f176.google.com with SMTP id u10so5766223lbd.7 for ; Mon, 28 Jul 2014 07:51:11 -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=aju0zPU5sla1Ca0BD0xKpmS4uBeMMMj7+sFJFvMsbUE=; b=T8nRJj23hwH4stzM5J+XFhRSRUDqLM37nkJ/hhyww5EqGl7yeVI/tP9V838QNn0+ss SdBbgjxMLLXXdYW7WpeR6aodb5lBqoVA8nGXTZhOOdpoqBzezRPF3NaLvezEqbBWIXq9 jjRyZfpJpQKzFn44t/Sf2SHE2cNoGB9VuV4Y21+AlxcGCNM7PU6cJtzbYrS7hpUsqsEK RkoevJ4K7ur9jCIqwLanPmJwuVWPa6g2O2pknCC9DiSBTA6dLLrr+CsjoPQlcEB74O3h T7BzYJ33xokOzCn3Yu7OsRlnV/+Xk3i3b2Nwf0Bp8pF56ad7lsVYASpcIGmJj3uuIyxL KeYw== MIME-Version: 1.0 X-Received: by 10.152.9.233 with SMTP id d9mr10897289lab.66.1406559071387; Mon, 28 Jul 2014 07:51:11 -0700 (PDT) Received: by 10.114.176.106 with HTTP; Mon, 28 Jul 2014 07:51:11 -0700 (PDT) In-Reply-To: References: <53CE80DD.9090109@gmail.com> <53D4600A.1010505@gmail.com> <53D4F77B.9020009@gmail.com> Date: Mon, 28 Jul 2014 10:51:11 -0400 Message-ID: Subject: Re: fastforward/routing: a 3 million packet-per-second system? From: John Jasen To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 28 Jul 2014 14:51:14 -0000 in_input crept up into the top 5, versus fastforward. Would PMC counters help? cat debug.lock.pref.stats.out-20140728-1 | sort -nk 4 | tail -5 5 4 413 115 160 2 0 0 63 /usr/src/sys/kern/kern_condvar.c:145 (sleep mutex:Giant) 1 1 148858 4095 650072 0 0 0 11184 /usr/src/sys/kern/subr_turnstile.c:552 (spin mutex:turnstile chain) 8 14 13747639 561636 72520256 0 0 0 689603 /usr/src/sys/net/route.c:439 (sleep mutex:rtentry) 3 20 3907071 2322975 72520256 0 0 0 2529589 /usr/src/sys/netinet/ip_input.c:1315 (sleep mutex:rtentry) 3 17 3665247 3715117 72520256 0 0 0 8425384 /usr/src/sys/netinet/in_rmx.c:114 (sleep mutex:rtentry) On Sun, Jul 27, 2014 at 1:50 PM, Adrian Chadd wrote: > Yeah, there's something odd going on. You shouldn't see any of that > lock contention if flowtable is enabled. Thus I think there's > > Oh wait, the fastfwd code doesn't know about flowtables. I just looked > at it (sys/netinet/ip_fastfwd.c.) > > Try disabling fastfwd for a test and see if the lock profile improves. > (Set debug.lock.prof.reset=1 to clear the profiling data before you do it.) > > > -a > > > On 27 July 2014 05:58, John Jasen wrote: > > I shouldn't even be coming close to maxflows in this test scenario. > > > > net.flowtable.enable: 1 > > net.flowtable.maxflows: 1042468 > > > > On 07/26/2014 10:20 PM, Adrian Chadd wrote: > >> Flowtable is enabled? That's odd, it shouldn't be showing up like that. > >> > >> > >> > >> -a > >> > >> > >> > > > From owner-freebsd-net@FreeBSD.ORG Mon Jul 28 17:30:50 2014 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 ESMTPS id 07CF196C for ; Mon, 28 Jul 2014 17:30:50 +0000 (UTC) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B894527BB for ; Mon, 28 Jul 2014 17:30:49 +0000 (UTC) Received: by mail-qa0-f42.google.com with SMTP id j15so8158492qaq.1 for ; Mon, 28 Jul 2014 10:30:48 -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=0d+VF/ElmmLOZTby5VDyA8P/11VWymKEbwSzbairIys=; b=R4mVCqjeUU2z+wvRD8pICylnso76iRaVj4FeN5cyN/t0nkubC1ZjGk3lQ7hgFj25M2 VMP1Ha+gE9YoF6j9m5tjnwMonEK5yXsE0V9kik65R7XC5f5fHVDF/qnC7DMzccoR8R+L ObXCBPhklLSKWB74X5mblNOb+NkUMe69LEgNkXL9o3R9HCWb7Ru51X2umLpbURXwxjds GTvDUwwBD0nqYp6MU38BBvyiObMrksHrVBfMRTl6mpVyRQOYckZTMpBseUBRJozjSxI9 1OQHNCCoh84ovCR2BQDWBXoUyMN8Xh0Xm2tw6+n2YdsHixCYTWrtxCPlah5tcS97rph+ cSMA== MIME-Version: 1.0 X-Received: by 10.224.161.83 with SMTP id q19mr6603925qax.26.1406568648715; Mon, 28 Jul 2014 10:30:48 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.1.6 with HTTP; Mon, 28 Jul 2014 10:30:48 -0700 (PDT) In-Reply-To: References: <53CE80DD.9090109@gmail.com> <53D4600A.1010505@gmail.com> <53D4F77B.9020009@gmail.com> Date: Mon, 28 Jul 2014 10:30:48 -0700 X-Google-Sender-Auth: 4gvSozSrnXVJb9xmqcN3efmdW8E Message-ID: Subject: Re: fastforward/routing: a 3 million packet-per-second system? From: Adrian Chadd To: John Jasen Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 28 Jul 2014 17:30:50 -0000 On 28 July 2014 07:51, John Jasen wrote: > in_input crept up into the top 5, versus fastforward. > > > Would PMC counters help? Not at the moment. This is a lock contention thing, not a pmc thing. I bet if you ran pmc the mutex/rwlock things would be up high. :) > > cat debug.lock.pref.stats.out-20140728-1 | sort -nk 4 | tail -5 > 5 4 413 115 160 2 0 0 > 63 /usr/src/sys/kern/kern_condvar.c:145 (sleep mutex:Giant) > 1 1 148858 4095 650072 0 0 0 > 11184 /usr/src/sys/kern/subr_turnstile.c:552 (spin mutex:turnstile chain) > 8 14 13747639 561636 72520256 0 0 0 > 689603 /usr/src/sys/net/route.c:439 (sleep mutex:rtentry) > 3 20 3907071 2322975 72520256 0 0 0 > 2529589 /usr/src/sys/netinet/ip_input.c:1315 (sleep mutex:rtentry) > 3 17 3665247 3715117 72520256 0 0 0 > 8425384 /usr/src/sys/netinet/in_rmx.c:114 (sleep mutex:rtentry) Try disabling net.inet.ip.redirect (sysctl net.inet.ip.redirect=0). That'll eliminate that in_rmx.c check. Oh look! The ip_output() path doesn't know about flowtable either. I'm kind of surprised that the 2-tuple flowtable (ie, only ipv4 and only ipv6 addresses, not TCP/UDP ports) isn't used in the ip forwarding case. All ip_rtaddr() is doing is doing a route lookup and taking a reference to the ifa. It's using that for things like network/netmask on that interface. Anyway - yeah, it looks like you've hit lock contention on that particular setup. You'll likely get a little more throughout out by disabling redirects for now. The real solution is to make the whole rtentry locking less stupid and bottleneck-y as well as extending the flowtable support to include the ip_forward() path. -a From owner-freebsd-net@FreeBSD.ORG Mon Jul 28 20:04:43 2014 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 ESMTPS id 18C057F1 for ; Mon, 28 Jul 2014 20:04:43 +0000 (UTC) Received: from quine.pinyon.org (quine.pinyon.org [65.101.5.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E4E062B08 for ; Mon, 28 Jul 2014 20:04:42 +0000 (UTC) Received: by quine.pinyon.org (Postfix, from userid 122) id 25C53160364; Mon, 28 Jul 2014 13:04:41 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on quine.pinyon.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 Received: from feyerabend.n1.pinyon.org (feyerabend.n1.pinyon.org [10.0.10.6]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by quine.pinyon.org (Postfix) with ESMTPSA id BD2E2160178 for ; Mon, 28 Jul 2014 13:04:38 -0700 (MST) Message-ID: <53D6ACD6.2030204@pinyon.org> Date: Mon, 28 Jul 2014 13:04:38 -0700 From: "Russell L. Carter" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: nfsd spam in /var/log/messages References: <43564051.4211288.1406552134888.JavaMail.root@uoguelph.ca> In-Reply-To: <43564051.4211288.1406552134888.JavaMail.root@uoguelph.ca> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 28 Jul 2014 20:04:43 -0000 On 07/28/14 05:55, Rick Macklem wrote: > Assuming /export is one file system on the server, put all > the exports in a single entry, something like: > V4: /export -sec=sys -network 10.0.10 -mask 255.255.255.0 > /export/usr/src /export/usr/obj /export/usr/ports /export/packages /export/library -maproot=root > > OR you can just allow the clients to mount any location > within the server file system using -alldirs like: > V4: /export -sec=sys -network 10.0.10 -mask 255.255.255.0 > /export -alldirs -maproot=root > > At least I think I got this correct;-) rick Then it would seem that that it is not possible to do per-host filesystem access control from a single server. Is that true? The larger project I am working on intermittently is to see if I can work out a way to secure NFSv4 so that the net transport is encrypted (via ssh|spiped tunnel, perhaps) and the server has per host (per user would be better) filesystem access control, WITHOUT kerberos. Maybe ACLs? I have looked into ACLs but they don't look very promising for multiple platform support. Thanks, Russell From owner-freebsd-net@FreeBSD.ORG Mon Jul 28 20:08:41 2014 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 ESMTPS id C1B5BC3C for ; Mon, 28 Jul 2014 20:08:41 +0000 (UTC) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9DAF32B46 for ; Mon, 28 Jul 2014 20:08:41 +0000 (UTC) Received: by mail-pd0-f180.google.com with SMTP id y13so10363899pdi.25 for ; Mon, 28 Jul 2014 13:08:41 -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=U8vP2nD1WVrQy5grC327I0SCXhvGf5GrKik6gVEBiPo=; b=mNWzxD9+5qMhG25TEFWx3tHue+XFbTYKu4zAMqhPlhfuhThSgcXRzuu0eRGReb+yPk CaZkAkwU7oQt7lG+rD49m4VXBmhHXiNe4BWc0TPzjvgacquZ1ZdC5+YpYcrVvNUAaYai R9lSh/VYimQIwnpuUfie6m2TpAlkma9vngGY/XFkcpDLeJNPQpEqY5lBavNufwDbN7kX ajCVkTdOYsXwnrneApFv58oYTuYmZeiZnxZ3hUUlVPeP1l+teXkciv1nVptffYQU3lnO Xr46qTacoyZoBU1BTcn0N2wYfAOfbaBKKXWL9jL3FKpN/Fs0NMDty4IDggMef5GfFSVp aQSg== MIME-Version: 1.0 X-Received: by 10.66.66.135 with SMTP id f7mr41599078pat.32.1406578121186; Mon, 28 Jul 2014 13:08:41 -0700 (PDT) Received: by 10.70.86.138 with HTTP; Mon, 28 Jul 2014 13:08:41 -0700 (PDT) Date: Mon, 28 Jul 2014 15:08:41 -0500 Message-ID: Subject: Adjust Ring Size From: Xiaoye Sun To: net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 28 Jul 2014 20:08:41 -0000 Hi all, I am new to netmap. I am current running netmap on Myricom 10G NIC and Linux machine. The problem in my case is that the maximum packet rate can achieve at the receiver is about 650kpp with 1514 frame length, about 8.3Gbps (1.7 from the 10Gbps line rate). if the sender sends faster than that, the receiving speed will decrease. So I am wondering if the netmap ring size is too small for my case. Can you guys tell me how to increase the ring size? Another question is can netmap handle (send/receive) jumbo ethernet frame with 9000 frame length? If so, do I need to change the slot size? (my understanding of the slot is that it is the unit in the ring contains packet) Thanks! Best, Xiaoye -- Xiaoye Steven Sun, Ph.D. Student 6100 Main St. MS-366 Department of Electrical and Computer Engineering (ECE) & Department of Computer Science (CS) George R. Brown School of Engineering Rice University, Houston, Texas, USA From owner-freebsd-net@FreeBSD.ORG Mon Jul 28 20:37:19 2014 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 ESMTPS id B8D2A930; Mon, 28 Jul 2014 20:37:19 +0000 (UTC) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 73A2A2F95; Mon, 28 Jul 2014 20:37:19 +0000 (UTC) Received: by mail-oi0-f52.google.com with SMTP id h136so6464802oig.25 for ; Mon, 28 Jul 2014 13:37:18 -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=yA9pTcDKz/LlR2usnUPpr6r/ORhje5Q98ij1UolRbcg=; b=U1jdd27vDImeFv/aqa4zbAkVUEsWpz7qAEACQWCWHJSFXg8uyBjTW0XMbRR3NvxMvx XKQQR50KelqS4FGcECWlSjaaUV4JoDAtbz2bbMQWk3wPJpG2iUo5AR38fqMdN9YYDAKM Oc/ostIQzjc5IDrvCFJx2DXBe7BKSqJBjgXrEeS+EPB1VSFrUG1BBjnGSuBd4Uj2kAe3 LF/SRgXDrLf7rjcnO/92mdpFigvC3lX9ob/3YnBi45Ov0OLGTorCI+KVHdc5EhYZ/v/a O4M1IQzecgOwoo+1rwVcp01wynoEDUQ31QVVcxMAQwflupQoaK4m6YCCvGBCS48i5wMw dUOA== MIME-Version: 1.0 X-Received: by 10.60.132.176 with SMTP id ov16mr53192103oeb.13.1406579838792; Mon, 28 Jul 2014 13:37:18 -0700 (PDT) Received: by 10.76.213.7 with HTTP; Mon, 28 Jul 2014 13:37:18 -0700 (PDT) In-Reply-To: <83597B15-63B3-4AD7-A458-00B67C9E5396@neville-neil.com> References: <53CE80DD.9090109@gmail.com> <53CEB090.7030701@gmail.com> <53CEB670.9060600@gmail.com> <53CEB9B5.7020609@gmail.com> <83597B15-63B3-4AD7-A458-00B67C9E5396@neville-neil.com> Date: Mon, 28 Jul 2014 16:37:18 -0400 Message-ID: Subject: Re: fastforward/routing: a 3 million packet-per-second system? From: Ryan Stone To: George Neville-Neil Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Net , Adrian Chadd , John Jasen , Navdeep Parhar X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 28 Jul 2014 20:37:19 -0000 On Sun, Jul 27, 2014 at 4:42 PM, George Neville-Neil wrote: > Chiming in late, but don't you mean instruction-retired instead of > CPU_CLK_UNHALTED_CORE? > > Best, > George In my experience instruction-retired gives very misleading profiler output in most cases. The problem is that instruction-retired gives equal weight to all instructions, which means that it does not take into account instructions with long latencies because they (for example) missed the cache. CPU_CLK_UNHALTED_CORE (or its alias, unhalted-cycles) is a much better event because it is a nearer proxy for time-based sampling, which is really what you're interested in when trying to reduce runtime of processes. My one big complaint with unhalted-cycles is that it does not take into effect CPU time spent in busy-wait loops that use the pause instruction, so it vastly unweights time spent adaptively spinning on kernel mutexes, for instance. I'm also not sure what it does when the CPU is adjusting its frequency, but that's not a case that I ever have to deal with personally. From owner-freebsd-net@FreeBSD.ORG Mon Jul 28 20:43:42 2014 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 ESMTPS id 85707E24 for ; Mon, 28 Jul 2014 20:43:42 +0000 (UTC) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 405A320B5 for ; Mon, 28 Jul 2014 20:43:42 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id k15so8772797qaq.27 for ; Mon, 28 Jul 2014 13:43:41 -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=htgdwhB6eTt6wa1XoZa556+gsj1qIiojsGi9feVAYoc=; b=BzGjWM1gjD+iHJnB1IfE/cv8zqaTJ/8V17rExt84iKh8I/130ymiSS4t/tbcSTtYj8 Koy4WYrwFQUsYnho/D02AWVgcY4VzxlOptblHcK9IPvKSvFFQ5ZjqdQOnGlGwnZDaYmv 6C2KIB2zF75DQ+AhhKj/73BEvVjEoIbZh/GAbtqC/zmTQXP8rr7O5IWCmUQx3nd0/ePE nGDqxxctqvjJXyFQrx/pyPhsRjuH3cduST2pQnOagYRVSir/jvudTDryYbttHe0dlB9b U8Q4SykBCm47e/u+uoAMsSYMfQgc6HTozIbWf5SMnd7oNdM8S6DNSbUB25ikYDWtPl2w r0Ew== MIME-Version: 1.0 X-Received: by 10.140.38.169 with SMTP id t38mr63787378qgt.3.1406580221322; Mon, 28 Jul 2014 13:43:41 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.1.6 with HTTP; Mon, 28 Jul 2014 13:43:41 -0700 (PDT) In-Reply-To: References: <53CE80DD.9090109@gmail.com> <53CEB090.7030701@gmail.com> <53CEB670.9060600@gmail.com> <53CEB9B5.7020609@gmail.com> <83597B15-63B3-4AD7-A458-00B67C9E5396@neville-neil.com> Date: Mon, 28 Jul 2014 13:43:41 -0700 X-Google-Sender-Auth: M4BJJUBZ-7hCftemg4Zz2rK5nGA Message-ID: Subject: Re: fastforward/routing: a 3 million packet-per-second system? From: Adrian Chadd To: Ryan Stone Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Net , John Jasen , Navdeep Parhar X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 28 Jul 2014 20:43:42 -0000 On 28 July 2014 13:37, Ryan Stone wrote: > On Sun, Jul 27, 2014 at 4:42 PM, George Neville-Neil > wrote: >> Chiming in late, but don't you mean instruction-retired instead of >> CPU_CLK_UNHALTED_CORE? >> >> Best, >> George > > In my experience instruction-retired gives very misleading profiler > output in most cases. The problem is that instruction-retired gives > equal weight to all instructions, which means that it does not take > into account instructions with long latencies because they (for > example) missed the cache. CPU_CLK_UNHALTED_CORE (or its alias, > unhalted-cycles) is a much better event because it is a nearer proxy > for time-based sampling, which is really what you're interested in > when trying to reduce runtime of processes. Right. It is a union of all the things that screw with you - frontend stall, backend/retire stall, microcode operation stall, FPU length stall, branch misprediction stalls, L3 miss (ie, memory) stall, cache ping-ponging stalls. Figuring out -which- of those above are the problem requires a little further digging. > My one big complaint with unhalted-cycles is that it does not take > into effect CPU time spent in busy-wait loops that use the pause > instruction, so it vastly unweights time spent adaptively spinning on > kernel mutexes, for instance. Well, it depends if you want to know about the places that it's spending in busy-wait loops using PAUSE or not. (Are there any flags / modifiers that have the CPU not count that?) > I'm also not sure what it does when the > CPU is adjusting its frequency, but that's not a case that I ever have > to deal with personally. That's the difference between _CORE and _REF. -a From owner-freebsd-net@FreeBSD.ORG Mon Jul 28 21:41:24 2014 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 ESMTPS id 81A65C74 for ; Mon, 28 Jul 2014 21:41:24 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 561B0272E for ; Mon, 28 Jul 2014 21:41:23 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s6SLfN6q078054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2014 14:41:23 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s6SLfMmA078053; Mon, 28 Jul 2014 14:41:22 -0700 (PDT) (envelope-from jmg) Date: Mon, 28 Jul 2014 14:41:21 -0700 From: John-Mark Gurney To: Carlos Ferreira Subject: Re: netmap Message-ID: <20140728214121.GU43962@funkthat.com> Mail-Followup-To: Carlos Ferreira , Luigi Rizzo , "freebsd-net@freebsd.org" , Prashant Upadhyaya References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 28 Jul 2014 14:41:23 -0700 (PDT) Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , Prashant Upadhyaya X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 28 Jul 2014 21:41:24 -0000 Carlos Ferreira wrote this message on Sat, Jul 12, 2014 at 11:52 +0100: > Ok,I solved that problem that I was having but now I have another one. For > what I was able to determine, SMP is not supported for IXP4xx processors on > OpenWRT. > I'm able to compile it for x86, but not for IXP4xx, the CPU's that the SBC > Cambria from Gateworks use. > I'm still investigating if this is really the problem and if it is, if it > is possible to overcome. Well, considering that these processors are single processor.. Making other code compile properly when SMP is not defined would be better... Having SMP not defined allows things to be better optimized and less locks used... > I will try to keep regular updates on this situation. Also, I'm pretty sure the npe interface doesn't support netmap and you'll need to do a bit of coding to make it support it... > On 11 July 2014 22:54, Carlos Ferreira wrote: > > > OK, ignore what I said in the last e-mail. My Makefile is nor working > > properly and I'm trying to figure out why. OpenWRT documentation for module > > Makefiles creation is scarce and confuse... > > > > > > On 11 July 2014 18:27, Carlos Ferreira wrote: > > > >> I'm building for OpenWRT (trunk) for the IXP4xx target. > >> > >> Attached goes the output for the compile attempt. Maybe I'm missing > >> something very basic... > >> > >> > >> On 11 July 2014 17:13, Luigi Rizzo wrote: > >> > >>> > >>> > >>> > >>> On Fri, Jul 11, 2014 at 6:07 PM, Carlos Ferreira > >>> wrote: > >>> > >>>> Luigi one question. Does netmap requires a processor with 64 bits? I'm > >>>> having some trouble in compiling netmap, using the same Makefile I used > >>>> previously, but for an Intel IXP435 CPU (Gateworks Cambria). > >>>> > >>> > >>> ???it used to build and work on 32 bit archs but we have not tried that > >>> there i a while. > >>> Hopefully it is just a matter of casts in printfs. > >>> > >>> which OS and netmap versions are you using ? > >>> can you send me an error log ? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Mon Jul 28 22:47:34 2014 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 ESMTPS id 1FB0DA7E for ; Mon, 28 Jul 2014 22:47:34 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id DC68E2F28 for ; Mon, 28 Jul 2014 22:47:33 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUEAE7R1lODaFve/2dsb2JhbABZg2BXBIJ0yQ4KhnhTAYEnd4QDAQEBAwEBAQEgKyALBRYYAgINGQIpAQkmBggHBAEcBIgZCA2nCpc7F4EsjU8BARs0B4J5gVEFmFuEQ5J6g2UhLweBBTk X-IronPort-AV: E=Sophos;i="5.01,752,1400040000"; d="scan'208";a="144057329" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 28 Jul 2014 18:47:26 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id BEB2879294; Mon, 28 Jul 2014 18:47:26 -0400 (EDT) Date: Mon, 28 Jul 2014 18:47:26 -0400 (EDT) From: Rick Macklem To: "Russell L. Carter" Message-ID: <1817833305.4592918.1406587646770.JavaMail.root@uoguelph.ca> In-Reply-To: <53D6ACD6.2030204@pinyon.org> Subject: Re: nfsd spam in /var/log/messages 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.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 28 Jul 2014 22:47:34 -0000 Russell L. Carter wrote: > > > On 07/28/14 05:55, Rick Macklem wrote: > > > Assuming /export is one file system on the server, put all > > the exports in a single entry, something like: > > V4: /export -sec=sys -network 10.0.10 -mask 255.255.255.0 > > /export/usr/src /export/usr/obj /export/usr/ports /export/packages > > /export/library -maproot=root > > > > OR you can just allow the clients to mount any location > > within the server file system using -alldirs like: > > V4: /export -sec=sys -network 10.0.10 -mask 255.255.255.0 > > /export -alldirs -maproot=root > > > > At least I think I got this correct;-) rick > > Then it would seem that that it is not possible to do per-host > filesystem access control from a single server. Is that true? > Yes, you can. Each line must be unique w.r.t. the tuple of . When there are multiple directories within a file system that needs to be mounted by a given host (or subnet), those must be specified in a single entry. > The larger project I am working on intermittently is to see if I can > work out a way to secure NFSv4 so that the net transport is encrypted > (via ssh|spiped tunnel, perhaps) and the server has per host (per > user > would be better) filesystem access control, WITHOUT kerberos. Maybe > ACLs? I have looked into ACLs but they don't look very promising for > multiple platform support. > On my "someday" list is trying to figure out how to allow a mount to work over IPsec, but I've never done it (and don't actually know if it is currently possible, although I suspect the answer is no). ACLs allow finer grained access control to a file, but still use whatever authentication is being used (auth_sys is just a uid# and list of gid#s vs Kerberos, which authenticates a kerberos principal). rick > Thanks, > Russell > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Jul 29 04:03:14 2014 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 ESMTPS id A9CDFF78 for ; Tue, 29 Jul 2014 04:03:14 +0000 (UTC) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 31EFE2F7F for ; Tue, 29 Jul 2014 04:03:14 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id k14so8231180wgh.32 for ; Mon, 28 Jul 2014 21:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=bUklx9HZB5IdL4nHgkGzGtZ2hM2tE0wJhCmLmxun5sE=; b=JCwGmTcLadMWtz44wOZbGU+6jA+v0oa0BUvjgjCvKJU+R0TEj/lIDnG6TEGJ7QBthx h5Vp1JAp5/i5a/j2Wm/fOJ/NSSvQGvl+TCQk3yJh04aBXW74FqvStDB3qDMY1+AuKiyq edzaOAO4kfCbL57Y2fBDCvchsDSapjUGqJIRDbOxE/hBqL+sGBfcimo3rtE2revfRbqy QIs9fmml1Z4FMPPKEtnQthxDGE8liqMU1MEL8xGRrsHf5iW2w52BN45hKtNmioDmmXnb qDMPup6t9M0o0POMP8WpIZrZp34L81nzu4TLGHmK8uR/yKr5tTv3MedG4Pn0+p2eGFZi +jyA== MIME-Version: 1.0 X-Received: by 10.194.219.193 with SMTP id pq1mr21510090wjc.5.1406606592234; Mon, 28 Jul 2014 21:03:12 -0700 (PDT) Received: by 10.216.159.136 with HTTP; Mon, 28 Jul 2014 21:03:12 -0700 (PDT) Reply-To: araujo@FreeBSD.org Date: Tue, 29 Jul 2014 12:03:12 +0800 Message-ID: Subject: Re: [patch][lagg] - Set a better granularity and distribution on roundrobin protocol. From: Marcelo Araujo To: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 29 Jul 2014 04:03:14 -0000 > > > > > > 2014-07-19 2:18 GMT+08:00 Navdeep Parhar > >: > > > > On 07/18/14 00:49, Marcelo Araujo wrote: > > > Hello guys, > > > > > > I made few changes on the lagg(4) patch. Also, I made tests using > > igb(4), > > > ixgbe(4) and em(4); seems everything worked pretty well. > > > > > > I'm wondering if anyone else could make a review, and what I need > > to do, to > > > see this patch committed. > > > > Deliberately putting out-of-order packets on the wire is never a good > > idea. This would count as a serious regression in lagg(4) imho. > > > > Regards, > > Navdeep > > > > > > > > I'm wondering if anyone have tested the patch; because as I have > > explained in another email, the number of SACK is much less with this > > patch. I have put some pcap files > > here: http://people.freebsd.org/~araujo/lagg/ > > > > Also, as far as I know, the current roundrobin implementation has no > > such kind of mechanism to control the order of the packages that goes to > > the wire. And this patch, what it only does is, instead to send only one > > package through one interface and switch to the another one, it will > > send X(where X is the number of packets defined via sysctl) packets and > > then, switch to the next interface. > > > > So, could you show me, where this patch deliberately put out-of-order > > packets? Did I miss anything? > Hey np@ > > Are you saying lagg's roundrobin implementation is already spraying > packets for the same flow across interfaces? Yes it does, if you check the SACK counter you can see that it does out of order by itself, with the patch or without the patch. The only thing that this patch helps is, send more packets throughout an interface before switch to the next one, and we will end up with less SACK and a better throughput, and also we can make a fine tuning. > That would make it > unsuitable for anything TCP. This is something that everybody knows, it breaks TCP by itself, I mean, performance will drop. > But then your patch isn't making it any > worse so I don't have any objection to it any more. > Thank you so much, and sorry by my late reply, I got busy testing other things. > > Looks like loadbalance does the right thing for flows. > Yes, loadbalance has no issue, it is mainly on round robin. Best Regards, -- Marcelo Araujo (__)araujo@FreeBSD.org \\\'',)http://www.FreeBSD.org \/ \ ^ Power To Server. .\. /_) From owner-freebsd-net@FreeBSD.ORG Tue Jul 29 13:06:29 2014 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 ESMTPS id 7735D263 for ; Tue, 29 Jul 2014 13:06:29 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 208F22C72 for ; Tue, 29 Jul 2014 13:06:28 +0000 (UTC) Received: from Mail-PC.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s6TD2Gdk058980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 29 Jul 2014 14:02:17 +0100 (BST) Date: Tue, 29 Jul 2014 14:02:16 +0100 From: Karl Pielorz To: freebsd-net@FreeBSD.org Subject: FreeBSD 10.0-R connected to Cisco switch (in 'trunk' mode with native VLAN) - doesn't work? Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 29 Jul 2014 13:06:29 -0000 Hi, I've got a Cisco 3750X switch a colleague is setting up. We've got this configured - but it doesn't seem to talk nicely to our FBSD 10.0-R box, looks like some kind of VLAN issue (but shouldn't be). Switch side - the port is configured with: switchport trunk encapsulation dot1q switchport trunk native vlan 2000 switchport trunk allowed vlan 2000,2200-2300 switchport mode trunk >From what I understand this tells the Cisco to present all the 'allowed' VLAN's to the port, and that untagged traffic traversing the port should be sent/received as VLAN 2000? So, we connect our BSD box and do: ifconfig bge0 inet 192.168.100.10 netmask 255.255.255.0 But we can't ping another host connected on the network, on '192.168.100.1'. The above ifconfig uses no VLAN spec, but that should be covered by the 'trunk native vlan'? The only way we can fix this - is to take the system 'as-is' and change the Cisco port to: switchport mode access switchport access vlan 2000 This sets the port to be 1 VLAN only, and sets that VLAN to VLAN 2000 - so traffic traversing the port will be untagged, but carried as part of VLAN 2000. I've been told in theory the bottom config should be the 'same' as the previous one (i.e. untagged traffic is treated as VLAN 2000). But with the top config - the BSD box can't connect anywhere, with the bottom config (with the BSD box setup the same) - it can. Presuming someone here has used Cisco kit with FreeBSD - can anyone see why the top config doesn't work? - The guy setting up the switches says he always uses the top config - and hasn't had an issue with it, but this obviously doesn't work with our FreeBSD boxes. I would say we'd try it with a different O/S but at the moment, all the kit on 'our' side is FreeBSD based... Cheers, -Karl From owner-freebsd-net@FreeBSD.ORG Tue Jul 29 13:25:05 2014 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 ESMTPS id 5F50A2E8 for ; Tue, 29 Jul 2014 13:25:05 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 263852F66 for ; Tue, 29 Jul 2014 13:25:05 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.9/8.14.9) with ESMTP id s6TDP095058497; Tue, 29 Jul 2014 09:25:00 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <53D7A0AA.3090200@sentex.net> Date: Tue, 29 Jul 2014 09:24:58 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Karl Pielorz , freebsd-net@freebsd.org Subject: Re: FreeBSD 10.0-R connected to Cisco switch (in 'trunk' mode with native VLAN) - doesn't work? References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 29 Jul 2014 13:25:05 -0000 On 7/29/2014 9:02 AM, Karl Pielorz wrote: > Switch side - the port is configured with: > > switchport trunk encapsulation dot1q > switchport trunk native vlan 2000 > switchport trunk allowed vlan 2000,2200-2300 > switchport mode trunk Would it not be better to have switchport trunk allowed vlan 2200-2300 otherwise its not clear to me what would be tagged and what would not be tagged as vlan 2000, no ? Do you really need to send a mix of tagged and untagged frames on the port ? ---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 Jul 29 15:18:14 2014 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 ESMTPS id 1A500BC for ; Tue, 29 Jul 2014 15:18:14 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id B5B2E2B56 for ; Tue, 29 Jul 2014 15:18:13 +0000 (UTC) Received: from Mail-PC.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s6TFIBPP070196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2014 16:18:11 +0100 (BST) Date: Tue, 29 Jul 2014 16:18:10 +0100 From: Karl Pielorz To: Mike Tancsa , freebsd-net@freebsd.org Subject: Re: FreeBSD 10.0-R connected to Cisco switch (in 'trunk' mode with native VLAN) - doesn't work? Message-ID: <7DC3480C170619DBCF9BB9DD@Mail-PC.tdx.co.uk> In-Reply-To: <53D7A0AA.3090200@sentex.net> References: <53D7A0AA.3090200@sentex.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 29 Jul 2014 15:18:14 -0000 --On 29 July 2014 09:24 -0400 Mike Tancsa wrote: > Would it not be better to have > > switchport trunk allowed vlan 2200-2300 > > otherwise its not clear to me what would be tagged and what would not be > tagged as vlan 2000, no ? I don't think that's the issue - I've had a couple of emails from other people who have this setup working, so I'd guess that's just a syntactical 'whats better / worse' kind of thing... > Do you really need to send a mix of tagged and > untagged frames on the port ? Yes, the project involves an element of migration - existing hosts being brought over will not have VLAN support, and a requirement is for them to just 'drop in' to the network, and still work. Thanks to those who replied (on and off list) - I've been able to create a test setup in house, which doesn't seem to have the issue - so I'll do some more digging around comparing that, to the remote kit / setup. I was just ruling out any known issues doing this kind of thing (which there doesn't appear to be). Regards, -Karl From owner-freebsd-net@FreeBSD.ORG Tue Jul 29 16:36:55 2014 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 ESMTPS id 2DA1FADE for ; Tue, 29 Jul 2014 16:36:55 +0000 (UTC) Received: from relay1-bcrtfl2.verio.net (relay1-bcrtfl2.verio.net [131.103.218.142]) by mx1.freebsd.org (Postfix) with ESMTP id D935C2612 for ; Tue, 29 Jul 2014 16:36:54 +0000 (UTC) Received: from iad-wprd-xchw02.corp.verio.net (iad-wprd-xchw02.corp.verio.net [198.87.7.165]) by relay1-bcrtfl2.verio.net (Postfix) with ESMTP id 6E09EB038040; Tue, 29 Jul 2014 12:09:42 -0400 (EDT) Received: from IAD-WPRD-XCHB01.corp.verio.net ([198.87.7.137]) by iad-wprd-xchw02.corp.verio.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Jul 2014 12:09:41 -0400 Content-Class: urn:content-classes:message Subject: RE: FreeBSD 10.0-R connected to Cisco switch (in 'trunk' mode with native VLAN) - doesn't work? Importance: normal Priority: normal MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Jul 2014 12:09:40 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FreeBSD 10.0-R connected to Cisco switch (in 'trunk' mode with native VLAN) - doesn't work? thread-index: Ac+rLf4J9m9qfwnmQN2W0zA7o17t8gAGMvrw References: From: "David DeSimone" To: "Karl Pielorz" X-OriginalArrivalTime: 29 Jul 2014 16:09:41.0751 (UTC) FILETIME=[814F2870:01CFAB47] Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 29 Jul 2014 16:36:55 -0000 We use exactly the sort of configuration you showed, and it works = perfectly with our FreeBSD systems. It is possible you are running afoul of spanning-tree behavior on the = port. Access ports are treated as "edge" ports and can activate right = away, while trunk ports must go through the full listen/learn/forward = cycle before they will start forwarding traffic, making the port appear = dead during its first 30-40 seconds. Consider adding to the 3750 configuration: interface GigabitEthernet_/0/__ spanning-tree portfast trunk The switch will give you a big warning about why this is a terrible = idea, but it is in fact a very good idea, since your server (hopefully) = isn't doing any bridging of traffic. If you do have any bridging code enabled, however, then this is actually = a terrible suggestion. :) -----Original Message----- From: owner-freebsd-net@freebsd.org = [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Karl Pielorz Sent: Tuesday, July 29, 2014 8:02 AM To: freebsd-net@FreeBSD.org Subject: FreeBSD 10.0-R connected to Cisco switch (in 'trunk' mode with = native VLAN) - doesn't work? Hi, I've got a Cisco 3750X switch a colleague is setting up. We've got this=20 configured - but it doesn't seem to talk nicely to our FBSD 10.0-R box,=20 looks like some kind of VLAN issue (but shouldn't be). Switch side - the port is configured with: switchport trunk encapsulation dot1q switchport trunk native vlan 2000 switchport trunk allowed vlan 2000,2200-2300 switchport mode trunk >From what I understand this tells the Cisco to present all the = 'allowed'=20 VLAN's to the port, and that untagged traffic traversing the port should = be=20 sent/received as VLAN 2000? So, we connect our BSD box and do: ifconfig bge0 inet 192.168.100.10 netmask 255.255.255.0 But we can't ping another host connected on the network, on = '192.168.100.1'. The above ifconfig uses no VLAN spec, but that should be covered by the=20 'trunk native vlan'? The only way we can fix this - is to take the system 'as-is' and change = the=20 Cisco port to: switchport mode access switchport access vlan 2000 This sets the port to be 1 VLAN only, and sets that VLAN to VLAN 2000 - = so=20 traffic traversing the port will be untagged, but carried as part of = VLAN=20 2000. I've been told in theory the bottom config should be the 'same' as the=20 previous one (i.e. untagged traffic is treated as VLAN 2000). But with the top config - the BSD box can't connect anywhere, with the=20 bottom config (with the BSD box setup the same) - it can. Presuming someone here has used Cisco kit with FreeBSD - can anyone see = why=20 the top config doesn't work? - The guy setting up the switches says he=20 always uses the top config - and hasn't had an issue with it, but this=20 obviously doesn't work with our FreeBSD boxes. I would say we'd try it with a different O/S but at the moment, all the = kit=20 on 'our' side is FreeBSD based... Cheers, -Karl _______________________________________________ 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" This email message is intended for the use of the person to whom it has = been sent, and may contain information that is confidential or legally = protected. If you are not the intended recipient or have received this = message in error, you are not authorized to copy, distribute, or = otherwise use this message or its attachments. Please notify the sender = immediately by return e-mail and permanently delete this message and any = attachments. Verio Inc. makes no warranty that this email is error or = virus free. Thank you. From owner-freebsd-net@FreeBSD.ORG Tue Jul 29 18:21:36 2014 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 ESMTPS id A67A01D9 for ; Tue, 29 Jul 2014 18:21:36 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6500F21F2 for ; Tue, 29 Jul 2014 18:21:36 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s6TILZn6093997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2014 11:21:35 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s6TILYCt093995; Tue, 29 Jul 2014 11:21:34 -0700 (PDT) (envelope-from jmg) Date: Tue, 29 Jul 2014 11:21:34 -0700 From: John-Mark Gurney To: Rick Macklem Subject: Re: nfsd spam in /var/log/messages Message-ID: <20140729182134.GA43962@funkthat.com> Mail-Followup-To: Rick Macklem , "Russell L. Carter" , freebsd-net@freebsd.org References: <53D6ACD6.2030204@pinyon.org> <1817833305.4592918.1406587646770.JavaMail.root@uoguelph.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1817833305.4592918.1406587646770.JavaMail.root@uoguelph.ca> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 29 Jul 2014 11:21:35 -0700 (PDT) Cc: "Russell L. Carter" , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 29 Jul 2014 18:21:36 -0000 Rick Macklem wrote this message on Mon, Jul 28, 2014 at 18:47 -0400: > Russell L. Carter wrote: > > On 07/28/14 05:55, Rick Macklem wrote: > > > > > Assuming /export is one file system on the server, put all > > > the exports in a single entry, something like: > > > V4: /export -sec=sys -network 10.0.10 -mask 255.255.255.0 > > > /export/usr/src /export/usr/obj /export/usr/ports /export/packages > > > /export/library -maproot=root > > > > > > OR you can just allow the clients to mount any location > > > within the server file system using -alldirs like: > > > V4: /export -sec=sys -network 10.0.10 -mask 255.255.255.0 > > > /export -alldirs -maproot=root > > > > > > At least I think I got this correct;-) rick > > > > Then it would seem that that it is not possible to do per-host > > filesystem access control from a single server. Is that true? > > > Yes, you can. Each line must be unique w.r.t. the tuple of > . > > When there are multiple directories within a file system that > needs to be mounted by a given host (or subnet), those must be > specified in a single entry. You know.. mountd really should grow the smarts to handle this, and warn if the various settings for the fs don't match between lines... i.e. union the lines as long as they match... Could be a good project for someone(tm)... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Tue Jul 29 20:34:12 2014 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 ESMTPS id D6228D76 for ; Tue, 29 Jul 2014 20:34:12 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 9DDD7219B for ; Tue, 29 Jul 2014 20:34:12 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEANsD2FODaFve/2dsb2JhbABXA4Q7gnTNLIMcAYEod4QEAQUjVhsYAgINGQJZBohVqACXQxeBLI1sJBAHEYJogVEFlysHmGuDZSGBdA X-IronPort-AV: E=Sophos;i="5.01,759,1400040000"; d="scan'208";a="144249128" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 29 Jul 2014 16:34:10 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id BBDC0B40C9; Tue, 29 Jul 2014 16:34:10 -0400 (EDT) Date: Tue, 29 Jul 2014 16:34:10 -0400 (EDT) From: Rick Macklem To: John-Mark Gurney Message-ID: <1627097637.4992011.1406666050759.JavaMail.root@uoguelph.ca> In-Reply-To: <20140729182134.GA43962@funkthat.com> Subject: Re: nfsd spam in /var/log/messages MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: "Russell L. Carter" , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 29 Jul 2014 20:34:12 -0000 John-Mark Gurney wrote: > Rick Macklem wrote this message on Mon, Jul 28, 2014 at 18:47 -0400: > > Russell L. Carter wrote: > > > On 07/28/14 05:55, Rick Macklem wrote: > > > > > > > Assuming /export is one file system on the server, put all > > > > the exports in a single entry, something like: > > > > V4: /export -sec=sys -network 10.0.10 -mask 255.255.255.0 > > > > /export/usr/src /export/usr/obj /export/usr/ports > > > > /export/packages > > > > /export/library -maproot=root > > > > > > > > OR you can just allow the clients to mount any location > > > > within the server file system using -alldirs like: > > > > V4: /export -sec=sys -network 10.0.10 -mask 255.255.255.0 > > > > /export -alldirs -maproot=root > > > > > > > > At least I think I got this correct;-) rick > > > > > > Then it would seem that that it is not possible to do per-host > > > filesystem access control from a single server. Is that true? > > > > > Yes, you can. Each line must be unique w.r.t. the tuple of > > . > > > > When there are multiple directories within a file system that > > needs to be mounted by a given host (or subnet), those must be > > specified in a single entry. > > You know.. mountd really should grow the smarts to handle this, and > warn if the various settings for the fs don't match between lines... > > i.e. union the lines as long as they match... > > Could be a good project for someone(tm)... > Yep. Of course, once they take a look at the really old, very ugly mountd.c, they may change their minds. I, for one, am not volunteering;-) Btw, there was a somewhat non-backwards compatible utility called nfse, but the author has withdrawn his support, so I am not sure what state the sources are in. rick > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > From owner-freebsd-net@FreeBSD.ORG Tue Jul 29 20:35:00 2014 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 ESMTPS id 8009DF42 for ; Tue, 29 Jul 2014 20:35:00 +0000 (UTC) Received: from quine.pinyon.org (quine.pinyon.org [65.101.5.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 550BB21AD for ; Tue, 29 Jul 2014 20:34:59 +0000 (UTC) Received: by quine.pinyon.org (Postfix, from userid 122) id DEE581602CD; Tue, 29 Jul 2014 13:34:52 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on quine.pinyon.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 Received: from feyerabend.n1.pinyon.org (feyerabend.n1.pinyon.org [10.0.10.6]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by quine.pinyon.org (Postfix) with ESMTPSA id 8879C1601D3 for ; Tue, 29 Jul 2014 13:34:50 -0700 (MST) Message-ID: <53D8056A.1010908@pinyon.org> Date: Tue, 29 Jul 2014 13:34:50 -0700 From: "Russell L. Carter" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: nfsd spam in /var/log/messages References: <53D6ACD6.2030204@pinyon.org> <1817833305.4592918.1406587646770.JavaMail.root@uoguelph.ca> <20140729182134.GA43962@funkthat.com> In-Reply-To: <20140729182134.GA43962@funkthat.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 29 Jul 2014 20:35:00 -0000 On 07/29/14 11:21, John-Mark Gurney wrote: > Rick Macklem wrote this message on Mon, Jul 28, 2014 at 18:47 -0400: >> Russell L. Carter wrote: >>> On 07/28/14 05:55, Rick Macklem wrote: >>> >>>> Assuming /export is one file system on the server, put all >>>> the exports in a single entry, something like: >>>> V4: /export -sec=sys -network 10.0.10 -mask 255.255.255.0 >>>> /export/usr/src /export/usr/obj /export/usr/ports /export/packages >>>> /export/library -maproot=root >>>> >>>> OR you can just allow the clients to mount any location >>>> within the server file system using -alldirs like: >>>> V4: /export -sec=sys -network 10.0.10 -mask 255.255.255.0 >>>> /export -alldirs -maproot=root >>>> >>>> At least I think I got this correct;-) rick >>> >>> Then it would seem that that it is not possible to do per-host >>> filesystem access control from a single server. Is that true? >>> >> Yes, you can. Each line must be unique w.r.t. the tuple of >> . This seems to work, and I don't have spam in my log: V4: /export -sec=sys /export/library -maproot=root linuxen /export -maproot=root fbsden However, 'linuxen' and 'fbsden' are defined in netgroup(5): linuxen (bruno,,n1.pinyon.org) fbsden (psf,,n1.pinyon.org) (knuth,,n1.pinyon.org) but the linux host can mount /export/usr/* just fine :-(. >> When there are multiple directories within a file system that >> needs to be mounted by a given host (or subnet), those must be >> specified in a single entry. > > You know.. mountd really should grow the smarts to handle this, and > warn if the various settings for the fs don't match between lines... > > i.e. union the lines as long as they match... > > Could be a good project for someone(tm)... > vfs_export and friends are impressively densely written... Cheers, Russell From owner-freebsd-net@FreeBSD.ORG Tue Jul 29 20:48:21 2014 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 ESMTPS id 99418703 for ; Tue, 29 Jul 2014 20:48:21 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 61C4922D5 for ; Tue, 29 Jul 2014 20:48:21 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArIEAJ0H2FODaFve/2dsb2JhbABag2BXBIJ0yHgKhnhTAYEod4QDAQEBAwEBAQEgKyALGxgCAg0ZAikBCSYGCAcEARwEiBkIDad6l0QXgSyNTwEBGzQHgnmBUQWXKweBLIRDknyDZSEvB4EFOQ X-IronPort-AV: E=Sophos;i="5.01,759,1400040000"; d="scan'208";a="144253012" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 29 Jul 2014 16:48:20 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 5DB32B4082; Tue, 29 Jul 2014 16:48:20 -0400 (EDT) Date: Tue, 29 Jul 2014 16:48:20 -0400 (EDT) From: Rick Macklem To: "Russell L. Carter" Message-ID: <1188535120.4997158.1406666900373.JavaMail.root@uoguelph.ca> In-Reply-To: <53D8056A.1010908@pinyon.org> Subject: Re: nfsd spam in /var/log/messages 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.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 29 Jul 2014 20:48:21 -0000 Russell L. Carter: > > > On 07/29/14 11:21, John-Mark Gurney wrote: > > Rick Macklem wrote this message on Mon, Jul 28, 2014 at 18:47 > > -0400: > >> Russell L. Carter wrote: > >>> On 07/28/14 05:55, Rick Macklem wrote: > >>> > >>>> Assuming /export is one file system on the server, put all > >>>> the exports in a single entry, something like: > >>>> V4: /export -sec=sys -network 10.0.10 -mask 255.255.255.0 > >>>> /export/usr/src /export/usr/obj /export/usr/ports > >>>> /export/packages > >>>> /export/library -maproot=root > >>>> > >>>> OR you can just allow the clients to mount any location > >>>> within the server file system using -alldirs like: > >>>> V4: /export -sec=sys -network 10.0.10 -mask 255.255.255.0 > >>>> /export -alldirs -maproot=root > >>>> > >>>> At least I think I got this correct;-) rick > >>> > >>> Then it would seem that that it is not possible to do per-host > >>> filesystem access control from a single server. Is that true? > >>> > >> Yes, you can. Each line must be unique w.r.t. the tuple of > >> . > > This seems to work, and I don't have spam in my log: > > V4: /export -sec=sys > /export/library -maproot=root linuxen > /export -maproot=root fbsden > > However, 'linuxen' and 'fbsden' are defined in netgroup(5): > > linuxen (bruno,,n1.pinyon.org) > fbsden (psf,,n1.pinyon.org) (knuth,,n1.pinyon.org) > > but the linux host can mount /export/usr/* just fine :-(. > Well, the host checks are enforced in the kernel on a per filesystem basis only. This implies that any location within a file system can be mounted via NFSv4, if any location within the file system has been exported to the host. (I'm assuming that /export/usr is a subtree of the /export file system.) The "directories within a file system" exports are only enforced by the Mount protocol that NFSv3 uses to talk to mountd. (NFSv4 does not use the Mount protocol.) These are considered "administrative controls", which is a nice way of saying "they aren't actually enforced by the kernel because there is no easy way to do so, but will discourage trivial attempts to do NFSv3 mounts". Personally, I've never liked these "administrative controls", but others feel they are useful (introduced long long ago by SunOS) and getting rid of them would be considered a POLA violation. (This was one of the reasons why nfse was never adopted as a replacement for mountd.) Various people have tried to clarify this in "man exports". Any patches that improve this will be appreciated. (It just seems to be a difficult thing to explain.) rick > >> When there are multiple directories within a file system that > >> needs to be mounted by a given host (or subnet), those must be > >> specified in a single entry. > > > > You know.. mountd really should grow the smarts to handle this, and > > warn if the various settings for the fs don't match between > > lines... > > > > i.e. union the lines as long as they match... > > > > Could be a good project for someone(tm)... > > > > vfs_export and friends are impressively densely written... > > Cheers, > Russell > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Jul 29 21:59:39 2014 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 ESMTPS id C580C907 for ; Tue, 29 Jul 2014 21:59:39 +0000 (UTC) Received: from quine.pinyon.org (quine.pinyon.org [65.101.5.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9AE642ADA for ; Tue, 29 Jul 2014 21:59:39 +0000 (UTC) Received: by quine.pinyon.org (Postfix, from userid 122) id 4720E1602CD; Tue, 29 Jul 2014 14:59:38 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on quine.pinyon.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 Received: from feyerabend.n1.pinyon.org (feyerabend.n1.pinyon.org [10.0.10.6]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by quine.pinyon.org (Postfix) with ESMTPSA id 142CA160189; Tue, 29 Jul 2014 14:59:36 -0700 (MST) Message-ID: <53D81947.2060801@pinyon.org> Date: Tue, 29 Jul 2014 14:59:35 -0700 From: "Russell L. Carter" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Rick Macklem , freebsd-net@freebsd.org Subject: Re: nfsd spam in /var/log/messages References: <1188535120.4997158.1406666900373.JavaMail.root@uoguelph.ca> In-Reply-To: <1188535120.4997158.1406666900373.JavaMail.root@uoguelph.ca> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 29 Jul 2014 21:59:39 -0000 On 07/29/14 13:48, Rick Macklem wrote: > Russell L. Carter: > > The "directories within a file system" exports are only enforced by > the Mount protocol that NFSv3 uses to talk to mountd. (NFSv4 does not > use the Mount protocol.) These are considered "administrative controls", > which is a nice way of saying "they aren't actually enforced by the kernel > because there is no easy way to do so, but will discourage trivial attempts > to do NFSv3 mounts". > > Personally, I've never liked these "administrative controls", but others > feel they are useful (introduced long long ago by SunOS) and getting rid > of them would be considered a POLA violation. (This was one of the reasons > why nfse was never adopted as a replacement for mountd.) > > Various people have tried to clarify this in "man exports". Any patches > that improve this will be appreciated. (It just seems to be a difficult > thing to explain.) I performed two more experiments with more than one "V4:" line in exports(5) (all zfs sharenfs=on filesystems): V4: /export/usr V4: /export/library and V4: /export V4: /export2 but mountd complains e.g.: "different V4 dirpath /export/usr" (Note that the So to tighten up just slightly the situation as you have described it: "There can only be one NFSv4 root filesystem per server, and any client host granted NFSv4 access to any subdirectory of that root exported filesystem can also mount any other subdirectory of the root exported filesystem." Why not just say this in exports(5)? As I originally observed, another way of saying this is that for -sec=sys, no per-host (or per-network) access control for the subdirectories of the single NFSv4 exported filesystem is possible. I don't actually think very much is problematical about this situation, because w/o krb5 the protocol is insecure (IMHO). I was just very curious what the current state of play was, *exactly*. Anyway, thanks for your patience explaining this stuff to me. Ok, I think that I can stop gnawing on this bone now... Best, Russell From owner-freebsd-net@FreeBSD.ORG Wed Jul 30 00:01:40 2014 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 ESMTPS id 2FB90F3D for ; Wed, 30 Jul 2014 00:01:40 +0000 (UTC) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E2F4D28E1 for ; Wed, 30 Jul 2014 00:01:39 +0000 (UTC) Received: by mail-qg0-f53.google.com with SMTP id q107so561577qgd.26 for ; Tue, 29 Jul 2014 17:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=clintarmstrong.net; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=yVz7LSmeH/z/IQPON1bbVZmCRAaiXgbr0jjzi+4bNpM=; b=gJ3aUUHpLZrB1JIfghGXSRoDV+wb2ZF1lazDqEt9FYXXFCF3G50iKbCegKJIDJiPMv y9KHLD4H7QG6XegpvmRWRud0W7kakTVPYrVSdGYp4ojub59JY1DfiSAt6ffx6FbLUk8P KcePK3P+LvfFQE2oL2Yfyz0+vnmIYwAwn99aI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=yVz7LSmeH/z/IQPON1bbVZmCRAaiXgbr0jjzi+4bNpM=; b=PF13iqa+EPsG15Vsd6vPkmiZ/y99AWZUQCsb1cFn8OMnDkEeYkqAyMSb0SOpAFMzyU aaAEd5PcOrpwym7X+2+2UPhl9460FgWWEv8MPDd03JiRJi9QIGxiseCYorcNFah+NtdU of4O8PcZXR0kFzMX+kRSQsnwyBaqXhVDbfz7wCdlqAo9JAq2YUVHX0xKG42SPHgTnGk6 lqdIp5vvKNoFolnyNT/zbnVoo1JqGcDF8oqaTx00oSZmFnG+JElngngemIfDTl3orD0q 1+oNDSI4twFOa1LU6yyuL7C3Y57/KvS2pTMrTKFCsio41X8xk5HuGu9sBBmZcVaELJLr pSkw== X-Gm-Message-State: ALoCoQl0yy5WBpsNFn1ncj+X+ypb7aoCKcnAmFm/REORYpiM9gPUqSOV2R6yYcpg96Jg+UKSJoHi MIME-Version: 1.0 X-Received: by 10.224.86.5 with SMTP id q5mr814861qal.36.1406678499080; Tue, 29 Jul 2014 17:01:39 -0700 (PDT) Received: by 10.140.84.37 with HTTP; Tue, 29 Jul 2014 17:01:39 -0700 (PDT) X-Originating-IP: [2601:4:2a80:2e5:199b:8a33:c335:bff2] Date: Tue, 29 Jul 2014 20:01:39 -0400 Message-ID: Subject: Cannot disable link local addresses on bridge or lagg members From: Clint Armstrong To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 30 Jul 2014 00:01:40 -0000 Is there any known issue that prevents disabling ipv6 and auto_linklocal on members of a lagg or bridge that is using ipv6? I have em0 and em1 which are members of lagg0 and lagg0 is a member of bridge0. This is for a server that runs man jails, including some vnet jails that have tap devices that are a member of the bridge. The handbook says that the host IP address should be on the bridge device itself, which I'm doing, but I can't seem to stop the other interfaces from getting link_local addresses. I have "inet6 ifdisabled -auto_linklocal" set in rc.conf for em0, em1 and lagg0, but all of them get link local addresses regardless. This isn't really causing a problem, because bridge0 is the only one that accepts RAs and ends up being used for IPV6. But I'd still like to clean it up if possible. I've anonymized the mac addresses, but the em0, em1 and lagg0 interfaces all show the same mac address, which I believe is expected. The bridge0 device has a mac address. # rc.conf ifconfig_em0="up" ifconfig_em0_ipv6="inet6 ifdisabled -auto_linklocal" ifconfig_em1="up" ifconfig_em1_ipv6="inet6 ifdisabled -auto_linklocal" ifconfig_lagg0="up laggport em0 laggport em1 laggproto roundrobin" ifconfig_lagg0_ipv6="inet6 ifdisabled -auto_linklocal" ifconfig_bridge0="up addm lagg0 192.168.10.10/24" ifconfig_bridge0_ipv6="inet6 auto_linklocal accept_rtadv" # ifconfig em0: flags=8943 metric 0 mtu 1500 options=4019b ether 00:15:17:XX:XX:XX inet6 fe80::XXXXX:XXXX:XXXX:XXXX%em0 prefixlen 64 scopeid 0x2 nd6 options=9 media: Ethernet autoselect (1000baseT ) status: active em1: flags=8943 metric 0 mtu 1500 options=4019b ether 00:15:17:XX:XX:XX inet6 fe80::XXXX:XXXX:XXXX:XXXX%em1 prefixlen 64 scopeid 0x3 nd6 options=9 media: Ethernet autoselect (1000baseT ) status: active lagg0: flags=8943 metric 0 mtu 1500 options=4019b ether 00:15:17:XX:XX:XX inet6 fe80::XXXX:XXXX:XXXX:XXXX%lagg0 prefixlen 64 scopeid 0x5 nd6 options=9 media: Ethernet autoselect status: active laggproto roundrobin lagghash l2,l3,l4 laggport: em1 flags=4 laggport: em0 flags=4 bridge0: flags=8843 metric 0 mtu 1500 ether 02:34:2f:XX:XX:XX inet 192.168.10.10 netmask 0xffffff00 broadcast 192.168.10.255 inet6 fe80::XXXX:XXXX:XXXX:XXXX%bridge0 prefixlen 64 scopeid 0x6 inet6 2601:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX prefixlen 64 autoconf inet6 fdc3:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX prefixlen 64 autoconf nd6 options=23 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: lagg0 flags=143 ifmaxaddr 0 port 5 priority 128 path cost 55 From owner-freebsd-net@FreeBSD.ORG Wed Jul 30 09:26:40 2014 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 ESMTPS id 5B8258E7 for ; Wed, 30 Jul 2014 09:26:40 +0000 (UTC) Received: from pandora.amnic.net (pandora.amnic.net [IPv6:2001:67c:21c:a610::11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 091F52238 for ; Wed, 30 Jul 2014 09:26:40 +0000 (UTC) Received: from ran by pandora.amnic.net with local (Exim 4.83 (FreeBSD)) (envelope-from ) id 1XCQ9Y-00090I-HL; Wed, 30 Jul 2014 13:26:32 +0400 Subject: Re: FreeBSD 10.0-R connected to Cisco switch (in 'trunk' mode with native VLAN) - doesn't work? In-Reply-To: To: Karl Pielorz Date: Wed, 30 Jul 2014 13:26:32 +0400 (AMT) From: Hrant Dadivanyan Reply-To: Hrant Dadivanyan X-PGP: https://amnic.net/pgpkeys/hrant.asc X-NCC-RegID: am.isoc X-Mailer: ELM [version 2.4ME+ PL126 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: Sender: Hrant Dadivanyan Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 30 Jul 2014 09:26:40 -0000 > > Hi, > > I've got a Cisco 3750X switch a colleague is setting up. We've got this > configured - but it doesn't seem to talk nicely to our FBSD 10.0-R box, > looks like some kind of VLAN issue (but shouldn't be). > > > Switch side - the port is configured with: > > switchport trunk encapsulation dot1q > switchport trunk native vlan 2000 > switchport trunk allowed vlan 2000,2200-2300 > switchport mode trunk > Hi Karl, I'm not sure whether it's on by default, but many Cisco switches (including all in 3750 family) can tag native vlan, so no a packet will leave ports untagged. no vlan dot1q tag native in configuration mode will switch this off. Thank you, Hrant > > >From what I understand this tells the Cisco to present all the 'allowed' > VLAN's to the port, and that untagged traffic traversing the port should be > sent/received as VLAN 2000? > > So, we connect our BSD box and do: > > ifconfig bge0 inet 192.168.100.10 netmask 255.255.255.0 > > But we can't ping another host connected on the network, on '192.168.100.1'. > > The above ifconfig uses no VLAN spec, but that should be covered by the > 'trunk native vlan'? > > > The only way we can fix this - is to take the system 'as-is' and change the > Cisco port to: > > switchport mode access > switchport access vlan 2000 > > This sets the port to be 1 VLAN only, and sets that VLAN to VLAN 2000 - so > traffic traversing the port will be untagged, but carried as part of VLAN > 2000. > > I've been told in theory the bottom config should be the 'same' as the > previous one (i.e. untagged traffic is treated as VLAN 2000). > > But with the top config - the BSD box can't connect anywhere, with the > bottom config (with the BSD box setup the same) - it can. > > > Presuming someone here has used Cisco kit with FreeBSD - can anyone see why > the top config doesn't work? - The guy setting up the switches says he > always uses the top config - and hasn't had an issue with it, but this > obviously doesn't work with our FreeBSD boxes. > > I would say we'd try it with a different O/S but at the moment, all the kit > on 'our' side is FreeBSD based... > > > Cheers, > > -Karl > > > > _______________________________________________ > 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" -- Hrant Dadivanyan (aka Ran d'Adi) hrant(at)dadivanyan.net /* "Feci quod potui, faciant meliora potentes." */ ran(at)psg.com From owner-freebsd-net@FreeBSD.ORG Wed Jul 30 14:41:05 2014 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 ESMTPS id 316B51D6 for ; Wed, 30 Jul 2014 14:41:05 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 190F22789 for ; Wed, 30 Jul 2014 14:41:05 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s6UEf4oC013155 for ; Wed, 30 Jul 2014 14:41:04 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 187341] [netinet] [patch] CARP addresses in backup state should't be used as source Date: Wed, 30 Jul 2014 14:41:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: des@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.isobsolete attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 30 Jul 2014 14:41:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D187341 Dag-Erling Sm=C3=B8rgrav changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #140669|0 |1 is obsolete| | --- Comment #2 from Dag-Erling Sm=C3=B8rgrav --- Created attachment 145159 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D145159&action= =3Dedit Proposed patch --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@FreeBSD.ORG Wed Jul 30 14:43:13 2014 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 ESMTPS id 41F24459 for ; Wed, 30 Jul 2014 14:43:13 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 29EEB27BF for ; Wed, 30 Jul 2014 14:43:13 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s6UEhDBx017563 for ; Wed, 30 Jul 2014 14:43:13 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 187341] [netinet] [patch] CARP addresses in backup state should't be used as source Date: Wed, 30 Jul 2014 14:43:13 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: des@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 30 Jul 2014 14:43:13 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D187341 --- Comment #3 from Dag-Erling Sm=C3=B8rgrav --- Forgot to mention that the attached patch is ae@'s work, not mine. I have tested it on a production system and can confirm that it works as intended. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@FreeBSD.ORG Wed Jul 30 15:09:06 2014 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 ESMTPS id 80CDE3AB for ; Wed, 30 Jul 2014 15:09:06 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 690B12AB3 for ; Wed, 30 Jul 2014 15:09:06 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s6UF96Z6066878 for ; Wed, 30 Jul 2014 15:09:06 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 187341] [netinet] [patch] CARP addresses in backup state should't be used as source Date: Wed, 30 Jul 2014 15:09:06 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 30 Jul 2014 15:09:06 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187341 --- Comment #4 from commit-hook@freebsd.org --- A commit references this bug: Author: ae Date: Wed Jul 30 15:08:12 UTC 2014 New revision: 269306 URL: http://svnweb.freebsd.org/changeset/base/269306 Log: Add new rule to source address selection algorithm. It prefers address with better virtual status. Use ifa_preferred() to choose better address. PR: 187341 Tested by: des MFC after: 1 week Changes: head/sys/netinet6/in6_src.c -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Jul 31 04:06:16 2014 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 ESMTPS id 5EDA26F8 for ; Thu, 31 Jul 2014 04:06:16 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 472272FB4 for ; Thu, 31 Jul 2014 04:06:16 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s6V46GYV094895 for ; Thu, 31 Jul 2014 04:06:16 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 108197] [panic] [gif] [ip6] if_delmulti reference counting panic Date: Thu, 31 Jul 2014 04:06:16 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 6.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jamie@dyslexicfish.net X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 04:06:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=108197 --- Comment #16 from Jamie Landeg-Jones --- Just stumbled across this now due to bugzilla. For what it's worth, I've been using/adding/removing gifs on various machines now for years with no problem. Back at the time this PR was raised the panics were often, and replicable. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Jul 31 12:33:45 2014 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 ESMTPS id 40FC0E67 for ; Thu, 31 Jul 2014 12:33:45 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id DCF2025F5 for ; Thu, 31 Jul 2014 12:33:44 +0000 (UTC) Received: from Mail-PC.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s6VCXHHv007608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jul 2014 13:33:18 +0100 (BST) Date: Thu, 31 Jul 2014 13:33:18 +0100 From: Karl Pielorz To: Hrant Dadivanyan Subject: Re: FreeBSD 10.0-R connected to Cisco switch (in 'trunk' mode with native VLAN) - doesn't work? Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 12:33:45 -0000 --On 30 July 2014 13:26 +0400 Hrant Dadivanyan wrote: > Hi Karl, > > I'm not sure whether it's on by default, but many Cisco switches > (including all in 3750 family) can tag native vlan, so no a packet will > leave ports untagged. > no vlan dot1q tag native > in configuration mode will switch this off. Thanks to all that replied - the issue in the end was a switch config issue (as suspected - i.e. not an O/S issue). Something to do with QinQ being setup on it - and the switch then not de-tagging native trunk vlan's... I'm not setting up the switches - so I don't know for sure what config option was changed (i.e. the one above?), but it is resolved now. Thanks again, -Karl From owner-freebsd-net@FreeBSD.ORG Thu Jul 31 13:12:48 2014 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 ESMTPS id 5ECAB88B for ; Thu, 31 Jul 2014 13:12:48 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 235EA2B9F for ; Thu, 31 Jul 2014 13:12:47 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIEADZA2lODaFve/2dsb2JhbABZg2BXBIJ0yBAeCoZ4UwGBHHeEAwEBAQECAQEBASArIAsFFhgCAg0ZAikBCSYGCAcEARwEiBkIDaUql1gXgSyNTwEBGzQHgnmBUQWXPAeBL4REkwGDZSEvB4EFOQ X-IronPort-AV: E=Sophos;i="5.01,772,1400040000"; d="scan'208";a="144566768" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 31 Jul 2014 09:12:40 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id EB668B4132; Thu, 31 Jul 2014 09:12:40 -0400 (EDT) Date: Thu, 31 Jul 2014 09:12:40 -0400 (EDT) From: Rick Macklem To: "Russell L. Carter" Message-ID: <1996576511.5775381.1406812360936.JavaMail.root@uoguelph.ca> In-Reply-To: <53D81947.2060801@pinyon.org> Subject: Re: nfsd spam in /var/log/messages MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 13:12:48 -0000 Russell L. Carter wrote: > > > On 07/29/14 13:48, Rick Macklem wrote: > > Russell L. Carter: > > > > > The "directories within a file system" exports are only enforced by > > the Mount protocol that NFSv3 uses to talk to mountd. (NFSv4 does > > not > > use the Mount protocol.) These are considered "administrative > > controls", > > which is a nice way of saying "they aren't actually enforced by the > > kernel > > because there is no easy way to do so, but will discourage trivial > > attempts > > to do NFSv3 mounts". > > > > Personally, I've never liked these "administrative controls", but > > others > > feel they are useful (introduced long long ago by SunOS) and > > getting rid > > of them would be considered a POLA violation. (This was one of the > > reasons > > why nfse was never adopted as a replacement for mountd.) > > > > Various people have tried to clarify this in "man exports". Any > > patches > > that improve this will be appreciated. (It just seems to be a > > difficult > > thing to explain.) > > I performed two more experiments with more than one "V4:" line in > exports(5) (all zfs sharenfs=on filesystems): > > V4: /export/usr > V4: /export/library > > and > > V4: /export > V4: /export2 > > but mountd complains e.g.: "different V4 dirpath /export/usr" > (Note that the > Well, I think this one is fairly clearly stated in the description of the "V4:" line, where it says that it must be the same directory path for all entries. > So to tighten up just slightly the situation as you have described > it: > > "There can only be one NFSv4 root filesystem per server, and any > client > host granted NFSv4 access to any subdirectory of that root exported > filesystem can also mount any other subdirectory of the root > exported > filesystem." > > Why not just say this in exports(5)? As I originally observed, > another way of saying this is that for -sec=sys, no per-host (or > per-network) access control for the subdirectories of the single > NFSv4 exported filesystem is possible. > Yeh, the one about "mounting any subdir" is hidden in the first page of "man exports", where it mentions this and how "-alldirs" is assumed for NFSv4. I think words similar to the above would make it clearer. I'll post a exports(5) patch soon for review. > I don't actually think very much is problematical about this > situation, because w/o krb5 the protocol is insecure (IMHO). I was > just very curious what the current state of play was, *exactly*. > > Anyway, thanks for your patience explaining this stuff to me. > > Ok, I think that I can stop gnawing on this bone now... > > Best, > Russell > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu Jul 31 14:21:29 2014 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 ESMTPS id 1CF40CC2 for ; Thu, 31 Jul 2014 14:21:29 +0000 (UTC) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AB1622632 for ; Thu, 31 Jul 2014 14:21:28 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id k48so2883864wev.41 for ; Thu, 31 Jul 2014 07:21:26 -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:subject :content-type:content-transfer-encoding; bh=EqduJKT0pjRJJsq7XPX3uWQKP8IOUyqNM4J54BXcmvc=; b=acRbU6pFn9jgtNmhVeEbI1r8WwlhRH99lBVmbNFTVERcqhcVBzEgYzFLdVk5EEFAtS gG/HdWFetdwa+1sS1s58GxIjlneiaT/mkK1u8mkrO7V2VY6Lmi1Vilv2A1M/3AGhMW2B JXED4e0nKULh2wjU9ywZnouhn9r62Bv/UfZJKzCJ3jJAcz4+vDP14dxNiCUaIJebrvZ2 asVp1CWmC2RZjfU/I7CSvUQgCVqY7Gk9fxAgMWhayI6+hfKDdWOrFDPtXfWg41NS2+Ya dlLyz4UE8t1LnwYBQgviLBsjsQrRHejjq0pPg06GgOGx7o4lBCAj84xpD8CGyfw0J7w/ i63Q== X-Received: by 10.180.7.163 with SMTP id k3mr8053592wia.0.1406816485801; Thu, 31 Jul 2014 07:21:25 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([134.249.139.101]) by mx.google.com with ESMTPSA id gc8sm21053890wic.3.2014.07.31.07.21.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Jul 2014 07:21:25 -0700 (PDT) Sender: Alexander Motin Message-ID: <53DA50E2.6070606@FreeBSD.org> Date: Thu, 31 Jul 2014 17:21:22 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Multicast races on vlan & lagg X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 14:21:29 -0000 Hi. Doing some tests on FreeNAS (FreeBSD 9.2+) I hit series of panic during active interfaces manipulation in some scenarios including multicast and several vlans on top of lagg. I am not ready to reproduce the full environment on head, but the code looks equal, so probably the bugs. I've made a patch to improve locking in that area, that seems fixes the problems: http://people.freebsd.org/~mav/mcast_vlan_lagg.patch Could somebody with more experience in the area please take a look? Thanks! -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Thu Jul 31 17:39:16 2014 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 ESMTPS id BF48F3BE for ; Thu, 31 Jul 2014 17:39:16 +0000 (UTC) Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D76E2FA5 for ; Thu, 31 Jul 2014 17:39:15 +0000 (UTC) Received: by mail-we0-f169.google.com with SMTP id u56so3127462wes.0 for ; Thu, 31 Jul 2014 10:39:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=qwrLhlByfV3FK3lEsoitKHndQBYB4IuOBetvrF0V4GY=; b=dxJrzcJi+LL7ARLMzgC3ME5Xp9hDQao7bm7tO6FMul3OFx8VSXbUkXdzx99N6Ro7rK vKG+ZADVxvKPCxKHByraSYoFgr6yKYqYhVOhltwakVY7slVEzADeDxXZXiZCLPm4ojWv 4zsJbYr/0wEGEJTV5yP9sNOKWi/QuSI3TXJZJhmBa1D4gUbpNciZZ8kCVEBvqQbQcu0C sZwIz5HxLaq72L+a0k/u0ZMwsBRS+nCp/V6ihNs9Gj+B8G5JAP/NT5AgbdytXeh9sMyz 5Wh9diUHv3i4PIDohYQRj/DsCJYwSO/yrUIzrVaT1KOf8WZ3NZDhztmU5Ve7YbcUOjqF vkCg== X-Gm-Message-State: ALoCoQkZRJQ+0YKN03vvg7PYFKHNpJ6Hu3nT/3jN1aldE1AtsHtHrkeL2al3CVzXT+DS1NuoCzxv X-Received: by 10.194.243.99 with SMTP id wx3mr18869765wjc.58.1406825199633; Thu, 31 Jul 2014 09:46:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.148.3 with HTTP; Thu, 31 Jul 2014 09:46:19 -0700 (PDT) From: Robert Clipsham Date: Thu, 31 Jul 2014 17:46:19 +0100 Message-ID: Subject: Using the loopback interface with BPF To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 17:39:16 -0000 Hi there, I've been using BPF to read and write Ethernet packets from the network, however I have encountered issues while writing a test suite for my code. The tests run on the loopback interface, however when calling write(), I received an EAFNOSUPPORT error (looutput: af=0 unexpected). When investigating further my findings were unexpected. It seems there are three main functions involved with writing packets on the loopback interface using BPF: looutput() from sys/net/if_loop.c; bpfwrite() and bpf_movein() from sys/net/bpf.c. When write()ing, bpf_movein() generates a sockaddr which is later used in looutput(). When using the loopback interface (DLT_NULL), the sa_family field is initialised to AF_UNSPEC, and it specifies a pseudo-header of 4 bytes should exist at the start of the buffer provided to write(). In bpfwrite(), after bpf_movein() has been called, if BIOCSHDRCMPLT has been set, the sa_family field is overwritten with pseudo_AF_HDRCMPLT. After this initial setup, looutput() is called. It handles BPF calls specially, by checking if the sa_family is AF_UNSPEC, and if so treating sa_family as whatever is stored in sa_data. There is then a switch statement, which only handles AF_INET and AF_INET6 packets. This has a number of consequences: * When using BPF on the loopback interface, the first 4 bytes of the buffer being sent are used for a pseudo-header. This pseudo-header remains in-tact when receiving, so the loopback interface must be special-cased for sending/receiving (alternatively a corrupt packet is sent/received, depending on how you look at it). * The need for any kind of pseudo-header is undocumented in the BPF man pages. It is mentioned briefly in the pcap man pages. * When BIOSHDRCMPLT is set, BPF cannot work on the loopback interface (since looutput() checks for AF_UNSPEC, but sa_family is pseudo_AF_HDRCMPLT). So my question is, what is the best way to test data link protocols with BPF offline with FreeBSD? My current ideas: * Special-case the loopback interface to add the pseudo-header and remove the BIOCSHDRCMPLT ioctl() (intresting note here: the ioctl() call does not fail, despite the option being invalid). * Modify the loopback device to support data link protocols properly, without the need for a pseudo-header (of course this would break backwards compatability). * Create an additional type of loopback interface designed to emulate other data link protocols. Your input would be appreciated. Thanks, Robert From owner-freebsd-net@FreeBSD.ORG Thu Jul 31 17:50:20 2014 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 ESMTPS id A241F989 for ; Thu, 31 Jul 2014 17:50:20 +0000 (UTC) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 165662104 for ; Thu, 31 Jul 2014 17:50:19 +0000 (UTC) Received: by mail-lb0-f172.google.com with SMTP id z11so2375567lbi.3 for ; Thu, 31 Jul 2014 10:50:17 -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=+1OWhNy4CnpwMB6YZXJFXisHpfaBWuiyDZJv2ZF9b9M=; b=PUHuPq+iqbPFqTyi1Na/neWELdaox2MLjxQri3Z3a3EiBAcSl+hGpTcMij+fnyH67m QD6OyJ8QVon+C/fU5+cK9XreaUNXz+OxXjT+TWotc9p6bFfR8AGDyEvPt3AZJJc7ASYs 5yb/KvWLuO65tUT4TLM9MEtNI65i4JLk4VHgrG9FJqelVQlNh73QRnK9gPVWOyP0R0v9 LmnMznvcd91K/rfjiY04BQubVrMsck8Dj3hpJqaJ/1UHrJYT+ZF7NbQintrggEqmumQ7 8s38MZ+K6+WuM9EEw4QQPer+/lVaayvEkSSxKavrZ+qwynx1N/khnn6T5QK37ErbhKBb nHqw== MIME-Version: 1.0 X-Received: by 10.112.171.134 with SMTP id au6mr13277684lbc.21.1406829017392; Thu, 31 Jul 2014 10:50:17 -0700 (PDT) Received: by 10.114.109.6 with HTTP; Thu, 31 Jul 2014 10:50:17 -0700 (PDT) Date: Thu, 31 Jul 2014 13:50:17 -0400 Message-ID: Subject: 4 million packets per second: Re: fastforward/routing: a 3 million packet-per-second system? From: John Jasen To: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 17:50:20 -0000 Following up, toggling hw.cxgbe.cong_drop yielded over 4 million packets per second in testing. This is probably an artifact of the switch I'm using, and should not be used unless your switch or clients don't respect ethernet pause. Turning off ip/icmp redirects yielded a little more, perhaps another 100k or so. Increasing the hw.cxgbe.n*xq10g in loader.conf (below) pushed a bottleneck from t4_transmit into kernel locking, so should be considered for busy servers. I removed the kern.sched sysctls, without notable changes to performance. It looks like the system spends a lot of time in locks, which it looks like there are patches in HEAD to address this. There are also patches in HEAD to make the cxgbe drivers work with netmap, which can also be useful. more /boot/loader.conf carp_load="YES" netmap_load="YES" cxgbe_load="YES" net.isr.maxthreads=12 net.isr.bindthreads=1 net.isr.maxqlimit=60480 net.link.ifqmaxlen=90000 # additions in discussions with cxgbe maintainer, Navdeep Parhar ( np@freebsd.org) hw.cxgbe.toecaps_allowed=0 hw.cxgbe.ntxq10g=48 hw.cxgbe.nrxq10g=16 # end cxgbe recommended additions # experimenting with cluster size, no effect hw.cxgbe.largest_rx_cluster=65536 hw.cxgbe.safest_rx_cluster=16384 #cong_drop: increased throughput by ~20%. # not recommended for use with real switches that respond to tx_pause hw.cxgbe.cong_drop=1 more /etc/sysctl.conf net.inet.ip.fastforwarding=1 kern.random.sys.harvest.ethernet=0 kern.random.sys.harvest.point_to_point=0 kern.random.sys.harvest.interrupt=0 hw.intr_storm_threshold=25000000 # not even coming close to this. could be dropped kern.ipc.maxsockbuf=258291200 net.inet.tcp.recvbuf_max=258291200 net.inet.tcp.sendbuf_max=258291200 #kern.sched.slice=1 #kern.sched.interact=1 net.inet.icmp.log_redirect=0 net.inet.icmp.redirect=0 net.inet.ip.redirect=0 net.inet.icmp.drop_redirect=1 more /etc/rc.conf hostname="fb-test" #ifconfig_igb0="DHCP" sshd_enable="YES" #ntpd_enable="YES" # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable dumpdev="AUTO" # OpenBSD PF options #pf_enable="YES" #pflog_enable="YES" # enable packet forwarding gateway_enable="YES" ipv6_gateway_enable="YES" # enable OpenBSD ftp-procy ftpproxy_enable="YES" #aliases used below to help shift clients during testing, and artifact of #testing other vendor card ifconfig_cxl0="inet 172.16.3.1 netmask 255.255.255.0 mtu 9000 -lro -tso up" ifconfig_cxl1="inet 172.16.4.1 netmask 255.255.255.0 mtu 9000 -lro -tso up" ifconfig_cxl2="inet 172.16.5.1 netmask 255.255.255.0 mtu 9000 -lro -tso up" ifconfig_cxl3="inet 172.16.6.1 netmask 255.255.255.0 mtu 9000 -lro -tso up" ifconfig_cxl0_alias0="inet 172.16.7.1 netmask 255.255.255.0" ifconfig_cxl1_alias0="inet 172.16.8.1 netmask 255.255.255.0" ifconfig_cxl2_alias0="inet 172.16.1.1 netmask 255.255.255.0" ifconfig_cxl3_alias0="inet 172.16.2.1 netmask 255.255.255.0" # ssh interface ifconfig_igb0="inet 172.30.60.60 netmask 255.255.0.0" On Tue, Jul 22, 2014 at 11:18 AM, John Jasen wrote: > > From owner-freebsd-net@FreeBSD.ORG Thu Jul 31 18:12:02 2014 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 ESMTPS id BCF02290; Thu, 31 Jul 2014 18:12:02 +0000 (UTC) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E660248B; Thu, 31 Jul 2014 18:12:02 +0000 (UTC) Received: by mail-qg0-f41.google.com with SMTP id q107so4369630qgd.0 for ; Thu, 31 Jul 2014 11:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=ul6w8cIWxKTnk6zaUXbdpEYlDiQI8C1RW3p6OxiCtPw=; b=jkUIkTl/PuGKhGYBK8v3YrF8yxXAah+VUTi4vKjYD/59VrQvNI2CV0uG+igkLjm9jl lB6TsCu1aH/ZAFWsUbCMQdb4L/p9M3rAeiTWRmXc4jLsC3KhvKEKgojowYcOfN35Bz+7 Nr3QIX9QLJ/OqdIRrQiSHkQH8RdZP2HnpMVRXkWM1VCzoz9S9pwsmtghcRuu0O06WUNj g1blphJpwFYUR/J1eJFkKo3SGByls3ZQui28jYzjOJ19/sHytP9JkEcqVd7yDjYVM5o6 Di3Hnh+UltnadoaMqwNEdYb0WMf6gvilCkSKboQ9o7oT+0J1PHme8DuOTtHqr5u71SIX IDYg== MIME-Version: 1.0 X-Received: by 10.140.26.110 with SMTP id 101mr19963710qgu.1.1406830320710; Thu, 31 Jul 2014 11:12:00 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.140.30.230 with HTTP; Thu, 31 Jul 2014 11:12:00 -0700 (PDT) Date: Thu, 31 Jul 2014 11:12:00 -0700 X-Google-Sender-Auth: C3ZRdrQ7vnT5j506Og4ixpxfEV0 Message-ID: Subject: [Video] Upcoming RSS enhancements to the FreeBSD Network Stack From: Craig Rodrigues To: freebsd-net@freebsd.org, freebsd-current Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 18:12:02 -0000 Hi, On July 10, at the Bay Area FreeBSD Users Group ( http://bafug.org ), Adrian Chadd gave a very nice talk: "Upcoming RSS enhancements to the FreeBSD Network Stack" https://www.youtube.com/watch?v=7CvIztTz-RQ Thanks to Adrian for doing the work and giving the talk! Thanks to Cao Pham for recording the video and posting it online! -- Craig From owner-freebsd-net@FreeBSD.ORG Fri Aug 1 14:19:02 2014 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 ESMTPS id 9664A1F0; Fri, 1 Aug 2014 14:19:02 +0000 (UTC) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E7515263B; Fri, 1 Aug 2014 14:19:01 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id bs8so1461566wib.3 for ; Fri, 01 Aug 2014 07:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:hackerspace:user-agent; bh=/Bpx52DghS9IO4yMA1g+4+Uh+5FASbiPYW8/7XTA93M=; b=bBY2CQ0t3hzadd6MHO3MdojqrHUcNMgTjUBK1rdzjwMlNMPVeJfZ/dyG3kdnqsAiQh 0/HomaBrOnC096jTQATDHyAn8COuNQn8QMqCdOtA4VyTHjFoL+lgQyyPa5vKJkkMpLhO OqGzy5zDlxVVgM7zbDF6wWph0rYqFPscGVBxpGwGcZFcT2mx/kWilL/LJzHU8sQp3EU4 zS3uM6fhEWkwb6Og5+V1D2DRObQK/DWf+fDJcrGKWqQbuW3s7HEwyzCyvpat/s5awYPG K/Y+mivQgQU70w0ROocEOHMDCjXrkdOnlkXY8hoJLwPokHsDRi6Dk/Xx5tv3H5BBI+C4 6CPQ== X-Received: by 10.180.102.98 with SMTP id fn2mr7269772wib.39.1406902738317; Fri, 01 Aug 2014 07:18:58 -0700 (PDT) Received: from gmail.com ([2001:630:241:204:d42:3911:638a:37e1]) by mx.google.com with ESMTPSA id fb8sm9123404wib.15.2014.08.01.07.18.57 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Aug 2014 07:18:57 -0700 (PDT) Sender: Tom Jones Date: Fri, 1 Aug 2014 15:19:21 +0100 From: Tom Jones To: Adrian Chadd Subject: Re: [PATCH] Implementation of draft-ietf-tcpm-newcwv-06 Message-ID: <20140801141920.GC75551@gmail.com> References: <20140630170453.GA21404@gmail.com> <20140630205359.GA2221@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline In-Reply-To: <20140630205359.GA2221@gmail.com> Hackerspace: 57North Hacklab User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 14:19:02 -0000 --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Jun 30, 2014 at 09:53:59PM +0100, Tom Jones wrote: > On Mon, Jun 30, 2014 at 12:29:44PM -0700, Adrian Chadd wrote: > > Hi! > > > > Cool! Would you mind throwing it into a bugzilla ticket so it's not > > lost and it can be assigned for some review? > > > > http://bugs.freebsd.org/submit/ > > Done. > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191520 > > > Is there any benefit in hanging this state off of it as a pointer to > > some other struct, rather than having it in the tcpcb? Is it always > > going to be used? > > The draft recommends newcwv be used as a default, so there is a chance it will > always be around. What would the impact to performance be by moving the state > out into a struct? I have updated the patch to move the new variable introduced with newcwv into a struct within the tcpcb. -- Tom | I don't see how we are going to build the dystopian megapoli @adventureloop | we were promised in 80s and early 90s cyberpunk fiction if adventurist.me | you guys keep complaining. :wq --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; filename="newcwv-01082014.patch" Index: sys/conf/files =================================================================== --- sys/conf/files (revision 269231) +++ sys/conf/files (working copy) @@ -3383,6 +3383,7 @@ netinet/tcp_sack.c optional inet | inet6 netinet/tcp_subr.c optional inet | inet6 netinet/tcp_syncache.c optional inet | inet6 +netinet/tcp_newcwv.c optional inet | inet6 netinet/tcp_timer.c optional inet | inet6 netinet/tcp_timewait.c optional inet | inet6 netinet/tcp_usrreq.c optional inet | inet6 Index: sys/netinet/tcp_input.c =================================================================== --- sys/netinet/tcp_input.c (revision 269231) +++ sys/netinet/tcp_input.c (working copy) @@ -105,6 +105,7 @@ #include #include #include +#include #ifdef TCPDEBUG #include #endif /* TCPDEBUG */ @@ -174,6 +175,11 @@ &VNET_NAME(tcp_abc_l_var), 2, "Cap the max cwnd increment during slow-start to this number of segments"); +VNET_DEFINE(int, tcp_do_newcwv) = 0; +SYSCTL_VNET_INT(_net_inet_tcp, OID_AUTO, newcwv, CTLFLAG_RW, + &VNET_NAME(tcp_do_newcwv), 0, + "Enable draft-ietf-tcpm-newcwv-06 (New Congestion Window Validation)"); + static SYSCTL_NODE(_net_inet_tcp, OID_AUTO, ecn, CTLFLAG_RW, 0, "TCP ECN"); VNET_DEFINE(int, tcp_do_ecn) = 0; @@ -285,9 +291,12 @@ INP_WLOCK_ASSERT(tp->t_inpcb); tp->ccv->bytes_this_ack = BYTES_THIS_ACK(tp, th); - if (tp->snd_cwnd <= tp->snd_wnd) + /* draft-ietf-tcpm-newcwv relaxes conditions for growing cwnd */ + if (tp->snd_cwnd <= tp->snd_wnd || + (V_tcp_do_newcwv && tp->newcwv.pipeack >= (tp->snd_cwnd >> 1)) ) { tp->ccv->flags |= CCF_CWND_LIMITED; - else + tp->newcwv.cwnd_valid_ts = ticks; + } else tp->ccv->flags &= ~CCF_CWND_LIMITED; if (type == CC_ACK) { @@ -309,6 +318,12 @@ tp->ccv->curack = th->th_ack; CC_ALGO(tp)->ack_received(tp->ccv, type); } + + /* + * update draft-ietf-newcwv-06 pipeack + */ + if(V_tcp_do_newcwv && !IN_FASTRECOVERY(tp->t_flags)) + tcp_newcwv_update_pipeack(tp); } static void inline @@ -378,6 +393,12 @@ tp->snd_cwnd = 4 * tp->t_maxseg; } + /* + * Initialise NewCWV state + */ + tp->newcwv.init_cwnd = tp->snd_cwnd; + tcp_newcwv_reset(tp); + if (CC_ALGO(tp)->conn_init != NULL) CC_ALGO(tp)->conn_init(tp->ccv); } @@ -426,6 +447,11 @@ tp->t_badrxtwin = 0; break; } + + if (V_tcp_do_newcwv && + (type == CC_NDUPACK || type == CC_ECN) && + tp->newcwv.pipeack <= (tp->snd_cwnd >> 1) ) + tcp_newcwv_enter_recovery(tp); if (CC_ALGO(tp)->cong_signal != NULL) { if (th != NULL) @@ -447,6 +473,13 @@ } /* XXXLAS: EXIT_RECOVERY ? */ tp->t_bytes_acked = 0; + + if(V_tcp_do_newcwv) { + if(tp->newcwv.loss_flight_size) + tcp_newcwv_end_recovery(tp); + tcp_newcwv_reset(tp); + } + tp->newcwv.loss_flight_size = 0; } #ifdef TCP_SIGNATURE Index: sys/netinet/tcp_output.c =================================================================== --- sys/netinet/tcp_output.c (revision 269231) +++ sys/netinet/tcp_output.c (working copy) @@ -74,6 +74,7 @@ #include #include #include +#include #ifdef TCPDEBUG #include #endif @@ -691,6 +692,10 @@ #endif hdrlen = sizeof (struct tcpiphdr); + /* Trigger the newcwv timer */ + if(V_tcp_do_newcwv) + tcp_newcwv_datalim_closedown(tp); + /* * Compute options for segment. * We only have to care about SYN and established connection Index: sys/netinet/tcp_subr.c =================================================================== --- sys/netinet/tcp_subr.c (revision 269231) +++ sys/netinet/tcp_subr.c (working copy) @@ -800,6 +800,7 @@ tp->t_flags = (TF_REQ_SCALE|TF_REQ_TSTMP); if (V_tcp_do_sack) tp->t_flags |= TF_SACK_PERMIT; + TAILQ_INIT(&tp->snd_holes); tp->t_inpcb = inp; /* XXX */ /* Index: sys/netinet/tcp_var.h =================================================================== --- sys/netinet/tcp_var.h (revision 269231) +++ sys/netinet/tcp_var.h (working copy) @@ -172,6 +172,22 @@ int t_sndzerowin; /* zero-window updates sent */ u_int t_badrxtwin; /* window for retransmit recovery */ u_char snd_limited; /* segments limited transmitted */ +/* NewCWV releated state */ + struct { + u_int32_t pipeack; + u_int32_t psp; /* pipeack sampling period */ + + u_int32_t head; + u_int32_t psample[4]; /* pipe ack samples */ + u_int32_t time_stamp[4]; /* time stamp samples */ + u_int32_t prev_snd_una; /* previous snd_una in this sampe */ + u_int32_t prev_snd_nxt; /* previous snd_nxt in this sampe */ + + u_int32_t loss_flight_size; /* flightsize at loss detection */ + u_int32_t prior_retrans; /* Retransmission before going into FR */ + u_int32_t cwnd_valid_ts; /*last time cwnd was found valid */ + u_int32_t init_cwnd; /* The inital cwnd */ + } newcwv; /* SACK related state */ int snd_numholes; /* number of holes seen by sender */ TAILQ_HEAD(sackhole_head, sackhole) snd_holes; @@ -605,6 +621,7 @@ VNET_DECLARE(int, path_mtu_discovery); VNET_DECLARE(int, tcp_do_rfc3465); VNET_DECLARE(int, tcp_abc_l_var); +VNET_DECLARE(int, tcp_do_newcwv); #define V_tcb VNET(tcb) #define V_tcbinfo VNET(tcbinfo) #define V_tcp_mssdflt VNET(tcp_mssdflt) @@ -617,6 +634,7 @@ #define V_path_mtu_discovery VNET(path_mtu_discovery) #define V_tcp_do_rfc3465 VNET(tcp_do_rfc3465) #define V_tcp_abc_l_var VNET(tcp_abc_l_var) +#define V_tcp_do_newcwv VNET(tcp_do_newcwv) VNET_DECLARE(int, tcp_do_sack); /* SACK enabled/disabled */ VNET_DECLARE(int, tcp_sc_rst_sock_fail); /* RST on sock alloc failure */ --M9NhX3UHpAaciwkO-- From owner-freebsd-net@FreeBSD.ORG Fri Aug 1 14:20:50 2014 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 ESMTPS id 3C38C2B3 for ; Fri, 1 Aug 2014 14:20:50 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2419D26D6 for ; Fri, 1 Aug 2014 14:20:50 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s71EKot0002276 for ; Fri, 1 Aug 2014 14:20:50 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 191520] [PATCH] Implementation of draft-ieft-tcpm-newcwv-06 Date: Fri, 01 Aug 2014 14:20:50 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jones@sdf.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 14:20:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191520 --- Comment #1 from Tom Jones --- Created attachment 145214 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=145214&action=edit Updated NewCWV patch -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Aug 1 14:21:25 2014 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 ESMTPS id 42BA034E for ; Fri, 1 Aug 2014 14:21:25 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2AEC426E6 for ; Fri, 1 Aug 2014 14:21:25 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s71ELPsX004239 for ; Fri, 1 Aug 2014 14:21:25 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 191520] [PATCH] Implementation of draft-ieft-tcpm-newcwv-06 Date: Fri, 01 Aug 2014 14:21:25 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jones@sdf.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 14:21:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191520 --- Comment #2 from Tom Jones --- Comment on attachment 145214 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=145214 Updated NewCWV patch Updated the patch to move the NewCWV into a struct within tcpcb -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Aug 1 15:37:26 2014 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 ESMTPS id 3A68B8D0; Fri, 1 Aug 2014 15:37:26 +0000 (UTC) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8EA3D201E; Fri, 1 Aug 2014 15:37:25 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id w62so4567141wes.29 for ; Fri, 01 Aug 2014 08:37:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:hackerspace:user-agent; bh=uEx/hl0/mguZdiW4u2+Qovfie8uhZJpJ9RwR9uuO4HM=; b=U2X1X2GAMbQ7P1lc6NQbRUbun6ykMUNAeHYO1UAqzXPEAywxm7BC+7aMQX0Q3LjF8n Xqa+ONrtPSJoi2bMCJrzJ/mSdpy9uQl5e4O/2tmzHWkh5Q66au4N5n6wk0M8zvYx3nhf dHAzuRFD3maliXMPcvziK4pqBU7jARsfl8AmnAJ7vz6r/PxcTJZbM3U/C98rFv45MemW ea08kmZCjIU3bpZR8HPslBAGJnMyzjN3V6TeYdPXFGKcgfQDAYe5vFToypj6pBlrwfoj 4WMIshVeOoCvUbjUpa92QDtf674tSxvtuEILBMGmXspn2px8yic3TUgdNLDqiA9xuQZu 0OLA== X-Received: by 10.194.62.5 with SMTP id u5mr8917301wjr.46.1406907442734; Fri, 01 Aug 2014 08:37:22 -0700 (PDT) Received: from gmail.com ([2001:630:241:204:d42:3911:638a:37e1]) by mx.google.com with ESMTPSA id f16sm9771889wic.7.2014.08.01.08.37.21 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Aug 2014 08:37:21 -0700 (PDT) Sender: Tom Jones Date: Fri, 1 Aug 2014 16:37:46 +0100 From: Tom Jones To: Adrian Chadd Subject: Re: [PATCH] Implementation of draft-ietf-tcpm-newcwv-06 Message-ID: <20140801153744.GA76021@gmail.com> References: <20140630170453.GA21404@gmail.com> <20140630205359.GA2221@gmail.com> <20140801141920.GC75551@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline In-Reply-To: <20140801141920.GC75551@gmail.com> Hackerspace: 57North Hacklab User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 15:37:26 -0000 --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Aug 01, 2014 at 03:19:20PM +0100, Tom Jones wrote: > > I have updated the patch to move the new variable introduced with newcwv into a > struct within the tcpcb. Forgot some files in the diff. -- Tom | I don't see how we are going to build the dystopian megapoli @adventureloop | we were promised in 80s and early 90s cyberpunk fiction if adventurist.me | you guys keep complaining. :wq --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; filename="newcwv-01082014.patch" Index: sys/conf/files =================================================================== --- sys/conf/files (revision 269231) +++ sys/conf/files (working copy) @@ -3383,6 +3383,7 @@ netinet/tcp_reass.c optional inet | inet6 netinet/tcp_sack.c optional inet | inet6 netinet/tcp_subr.c optional inet | inet6 netinet/tcp_syncache.c optional inet | inet6 +netinet/tcp_newcwv.c optional inet | inet6 netinet/tcp_timer.c optional inet | inet6 netinet/tcp_timewait.c optional inet | inet6 netinet/tcp_usrreq.c optional inet | inet6 Index: sys/netinet/tcp_input.c =================================================================== --- sys/netinet/tcp_input.c (revision 269231) +++ sys/netinet/tcp_input.c (working copy) @@ -105,6 +105,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #ifdef TCPDEBUG #include #endif /* TCPDEBUG */ @@ -174,6 +175,11 @@ SYSCTL_VNET_INT(_net_inet_tcp, OID_AUTO, abc_l_var &VNET_NAME(tcp_abc_l_var), 2, "Cap the max cwnd increment during slow-start to this number of segments"); +VNET_DEFINE(int, tcp_do_newcwv) = 0; +SYSCTL_VNET_INT(_net_inet_tcp, OID_AUTO, newcwv, CTLFLAG_RW, + &VNET_NAME(tcp_do_newcwv), 0, + "Enable draft-ietf-tcpm-newcwv-06 (New Congestion Window Validation)"); + static SYSCTL_NODE(_net_inet_tcp, OID_AUTO, ecn, CTLFLAG_RW, 0, "TCP ECN"); VNET_DEFINE(int, tcp_do_ecn) = 0; @@ -285,9 +291,12 @@ cc_ack_received(struct tcpcb *tp, struct tcphdr *t INP_WLOCK_ASSERT(tp->t_inpcb); tp->ccv->bytes_this_ack = BYTES_THIS_ACK(tp, th); - if (tp->snd_cwnd <= tp->snd_wnd) + /* draft-ietf-tcpm-newcwv relaxes conditions for growing cwnd */ + if (tp->snd_cwnd <= tp->snd_wnd || + (V_tcp_do_newcwv && tp->newcwv.pipeack >= (tp->snd_cwnd >> 1)) ) { tp->ccv->flags |= CCF_CWND_LIMITED; - else + tp->newcwv.cwnd_valid_ts = ticks; + } else tp->ccv->flags &= ~CCF_CWND_LIMITED; if (type == CC_ACK) { @@ -309,6 +318,12 @@ cc_ack_received(struct tcpcb *tp, struct tcphdr *t tp->ccv->curack = th->th_ack; CC_ALGO(tp)->ack_received(tp->ccv, type); } + + /* + * update draft-ietf-newcwv-06 pipeack + */ + if(V_tcp_do_newcwv && !IN_FASTRECOVERY(tp->t_flags)) + tcp_newcwv_update_pipeack(tp); } static void inline @@ -378,6 +393,12 @@ cc_conn_init(struct tcpcb *tp) tp->snd_cwnd = 4 * tp->t_maxseg; } + /* + * Initialise NewCWV state + */ + tp->newcwv.init_cwnd = tp->snd_cwnd; + tcp_newcwv_reset(tp); + if (CC_ALGO(tp)->conn_init != NULL) CC_ALGO(tp)->conn_init(tp->ccv); } @@ -426,6 +447,11 @@ cc_cong_signal(struct tcpcb *tp, struct tcphdr *th tp->t_badrxtwin = 0; break; } + + if (V_tcp_do_newcwv && + (type == CC_NDUPACK || type == CC_ECN) && + tp->newcwv.pipeack <= (tp->snd_cwnd >> 1) ) + tcp_newcwv_enter_recovery(tp); if (CC_ALGO(tp)->cong_signal != NULL) { if (th != NULL) @@ -447,6 +473,13 @@ cc_post_recovery(struct tcpcb *tp, struct tcphdr * } /* XXXLAS: EXIT_RECOVERY ? */ tp->t_bytes_acked = 0; + + if(V_tcp_do_newcwv) { + if(tp->newcwv.loss_flight_size) + tcp_newcwv_end_recovery(tp); + tcp_newcwv_reset(tp); + } + tp->newcwv.loss_flight_size = 0; } #ifdef TCP_SIGNATURE Index: sys/netinet/tcp_newcwv.c =================================================================== --- sys/netinet/tcp_newcwv.c (revision 0) +++ sys/netinet/tcp_newcwv.c (working copy) @@ -0,0 +1,175 @@ +/* + * Copyright (c) 2014 Tom Jones + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + */ + +#include + +#include +#include +#include +#include +#include + +#include +#include +#include + +/* + * An implementation of NewCWV (draft-ietf-tcpm-newcwv-06) for FreeBSD. + * Based on the Linux implementation by Raffaello Secchi and the an initial + * implementation of draft-ietf-tcpm-newcwv-00 by Aris Angelogiannopoulos. + */ + +#define nextbin(x) (((x)+1) & 0x03) +#define prevbin(x) (((x)-1) & 0x03) + +#define NCWV_UNDEF 0xFFFFFFFF +#define NCWV_FIVEMINS (300*hz) + +void add_element(struct tcpcb *,u_int32_t); +u_int32_t remove_expired_elements(struct tcpcb *); + +void +tcp_newcwv_update_pipeack(struct tcpcb *tp) +{ + u_int32_t tmp_pipeack; + tp->newcwv.psp = MAX(3 * tp->t_srtt,hz); + + if (tp->snd_una >= tp->newcwv.prev_snd_nxt) { + /* get the pipeack sample */ + tmp_pipeack = tp->snd_una - tp->newcwv.prev_snd_una; + + tp->newcwv.prev_snd_una = tp->snd_una; + tp->newcwv.prev_snd_nxt = tp->snd_nxt; + + /* create a new element at the end of current pmp */ + if(ticks > tp->newcwv.time_stamp[tp->newcwv.head] + + (tp->newcwv.psp >> 2)) + add_element(tp,tmp_pipeack); + else + tp->newcwv.psample[tp->newcwv.head] = tmp_pipeack; + } + + tp->newcwv.pipeack = remove_expired_elements(tp); + + /* check if cwnd is validated */ + if (tp->newcwv.pipeack == NCWV_UNDEF || + ((tp->newcwv.pipeack << 1) >= (tp->snd_cwnd * tp->t_maxseg))) { + tp->newcwv.cwnd_valid_ts = ticks; + } +} + +void +add_element(struct tcpcb *tp,u_int32_t value) +{ + tp->newcwv.head = nextbin(tp->newcwv.head); + tp->newcwv.psample[tp->newcwv.head] = value; + tp->newcwv.time_stamp[tp->newcwv.head] = ticks; +} + +u_int32_t +remove_expired_elements(struct tcpcb *tp) +{ + uint8_t head = tp->newcwv.head; + u_int32_t tmp = tp->newcwv.psample[head]; + + while(tp->newcwv.psample[head] != NCWV_UNDEF) { + /* remove the element if expired */ + if (tp->newcwv.time_stamp[head] < ticks - tp->newcwv.psp) { + tp->newcwv.psample[head] = NCWV_UNDEF; + return tmp; + } + + /* search for the max pipeack */ + if(tp->newcwv.psample[head] > tmp) + tmp = tp->newcwv.psample[head]; + + head = prevbin(head); + if(head == tp->newcwv.head) + return tmp; + } + + return tmp; +} + +/* Initialise NewCWV state */ +void +tcp_newcwv_reset(struct tcpcb *tp) +{ + tp->newcwv.prev_snd_una = tp->snd_una; + tp->newcwv.prev_snd_nxt = tp->snd_nxt; + tp->newcwv.cwnd_valid_ts = ticks; + tp->newcwv.loss_flight_size = 0; + + tp->newcwv.head = 0; + tp->newcwv.psample[0] = NCWV_UNDEF; + tp->newcwv.pipeack = NCWV_UNDEF; +} + +/* NewCWV actions at loss detection */ +void +tcp_newcwv_enter_recovery(struct tcpcb *tp) +{ + u_int32_t pipe; + + if(tp->newcwv.pipeack == NCWV_UNDEF) + return; + + tp->newcwv.prior_retrans = tp->t_sndrexmitpack; + + /* Calculate the flight size */ + u_int32_t awnd = (tp->snd_nxt - tp->snd_fack) + tp->sackhint.sack_bytes_rexmit; + tp->newcwv.loss_flight_size = awnd; + + pipe = MAX(tp->newcwv.pipeack,tp->newcwv.loss_flight_size); + tp->snd_cwnd = MAX(pipe >> 1,1); +} + +/* NewCWV actions at the end of recovery */ +void +tcp_newcwv_end_recovery(struct tcpcb *tp) +{ + u_int32_t retrans,pipe; + + retrans = (tp->t_sndrexmitpack - tp->newcwv.prior_retrans) * tp->t_maxseg; + pipe = MAX(tp->newcwv.pipeack,tp->newcwv.loss_flight_size) - retrans; + + /* Ensure that snd_ssthresh is non 0 */ + tp->snd_ssthresh = MAX(pipe >> 1,1); + tp->snd_cwnd = tp->snd_ssthresh; +} + +void +tcp_newcwv_datalim_closedown(struct tcpcb *tp) +{ + while ((ticks - tp->newcwv.cwnd_valid_ts) > NCWV_FIVEMINS && + tp->snd_cwnd > tp->newcwv.init_cwnd) { + + tp->newcwv.cwnd_valid_ts += NCWV_FIVEMINS; + tp->snd_ssthresh = MAX( (3 * tp->snd_cwnd ) >> 2,tp->snd_ssthresh); + tp->snd_cwnd = MAX(tp->snd_cwnd >> 1, tp->newcwv.init_cwnd); + } +} Property changes on: sys/netinet/tcp_newcwv.c ___________________________________________________________________ Added: svn:keywords ## -0,0 +1 ## +FreeBSD=%H \ No newline at end of property Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Index: sys/netinet/tcp_newcwv.c.orig =================================================================== Index: sys/netinet/tcp_newcwv.h =================================================================== --- sys/netinet/tcp_newcwv.h (revision 0) +++ sys/netinet/tcp_newcwv.h (working copy) @@ -0,0 +1,39 @@ +/* + * Copyright (c) 2014 Tom Jones + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + */ + +#ifndef _NETINET_TCP_NEWCWV_H_ +#define _NETINET_TCP_NEWCWV_H_ + +#include + +void tcp_newcwv_update_pipeack(struct tcpcb *); +void tcp_newcwv_reset(struct tcpcb *); +void tcp_newcwv_enter_recovery(struct tcpcb *); +void tcp_newcwv_end_recovery(struct tcpcb *); +void tcp_newcwv_datalim_closedown(struct tcpcb *); + +#endif /* _NETINET_TCP_NEWCWV_H_ */ Property changes on: sys/netinet/tcp_newcwv.h ___________________________________________________________________ Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=%H \ No newline at end of property Index: sys/netinet/tcp_newcwv.h.orig =================================================================== Index: sys/netinet/tcp_output.c =================================================================== --- sys/netinet/tcp_output.c (revision 269231) +++ sys/netinet/tcp_output.c (working copy) @@ -74,6 +74,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #ifdef TCPDEBUG #include #endif @@ -691,6 +692,10 @@ send: #endif hdrlen = sizeof (struct tcpiphdr); + /* Trigger the newcwv timer */ + if(V_tcp_do_newcwv) + tcp_newcwv_datalim_closedown(tp); + /* * Compute options for segment. * We only have to care about SYN and established connection Index: sys/netinet/tcp_subr.c =================================================================== --- sys/netinet/tcp_subr.c (revision 269231) +++ sys/netinet/tcp_subr.c (working copy) @@ -800,6 +800,7 @@ tcp_newtcpcb(struct inpcb *inp) tp->t_flags = (TF_REQ_SCALE|TF_REQ_TSTMP); if (V_tcp_do_sack) tp->t_flags |= TF_SACK_PERMIT; + TAILQ_INIT(&tp->snd_holes); tp->t_inpcb = inp; /* XXX */ /* Index: sys/netinet/tcp_var.h =================================================================== --- sys/netinet/tcp_var.h (revision 269231) +++ sys/netinet/tcp_var.h (working copy) @@ -172,6 +172,22 @@ struct tcpcb { int t_sndzerowin; /* zero-window updates sent */ u_int t_badrxtwin; /* window for retransmit recovery */ u_char snd_limited; /* segments limited transmitted */ +/* NewCWV releated state */ + struct { + u_int32_t pipeack; + u_int32_t psp; /* pipeack sampling period */ + + u_int32_t head; + u_int32_t psample[4]; /* pipe ack samples */ + u_int32_t time_stamp[4]; /* time stamp samples */ + u_int32_t prev_snd_una; /* previous snd_una in this sampe */ + u_int32_t prev_snd_nxt; /* previous snd_nxt in this sampe */ + + u_int32_t loss_flight_size; /* flightsize at loss detection */ + u_int32_t prior_retrans; /* Retransmission before going into FR */ + u_int32_t cwnd_valid_ts; /*last time cwnd was found valid */ + u_int32_t init_cwnd; /* The inital cwnd */ + } newcwv; /* SACK related state */ int snd_numholes; /* number of holes seen by sender */ TAILQ_HEAD(sackhole_head, sackhole) snd_holes; @@ -605,6 +621,7 @@ VNET_DECLARE(int, tcp_recvspace); VNET_DECLARE(int, path_mtu_discovery); VNET_DECLARE(int, tcp_do_rfc3465); VNET_DECLARE(int, tcp_abc_l_var); +VNET_DECLARE(int, tcp_do_newcwv); #define V_tcb VNET(tcb) #define V_tcbinfo VNET(tcbinfo) #define V_tcp_mssdflt VNET(tcp_mssdflt) @@ -617,6 +634,7 @@ VNET_DECLARE(int, tcp_abc_l_var); #define V_path_mtu_discovery VNET(path_mtu_discovery) #define V_tcp_do_rfc3465 VNET(tcp_do_rfc3465) #define V_tcp_abc_l_var VNET(tcp_abc_l_var) +#define V_tcp_do_newcwv VNET(tcp_do_newcwv) VNET_DECLARE(int, tcp_do_sack); /* SACK enabled/disabled */ VNET_DECLARE(int, tcp_sc_rst_sock_fail); /* RST on sock alloc failure */ --sdtB3X0nJg68CQEu-- From owner-freebsd-net@FreeBSD.ORG Fri Aug 1 15:38:58 2014 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 ESMTPS id 9F8BF976 for ; Fri, 1 Aug 2014 15:38:58 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 87E8E2037 for ; Fri, 1 Aug 2014 15:38:58 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s71Fcw08009866 for ; Fri, 1 Aug 2014 15:38:58 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 191520] [PATCH] Implementation of draft-ieft-tcpm-newcwv-06 Date: Fri, 01 Aug 2014 15:38:58 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jones@sdf.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 15:38:58 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191520 --- Comment #3 from Tom Jones --- Created attachment 145216 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=145216&action=edit Updated NewCWV patch Move NewCWV state into a struct within tcpcb -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Aug 1 18:18:27 2014 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 ESMTPS id C07FD176 for ; Fri, 1 Aug 2014 18:18:27 +0000 (UTC) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8097F2269 for ; Fri, 1 Aug 2014 18:18:27 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id j7so4390530qaq.28 for ; Fri, 01 Aug 2014 11:18:26 -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=NlFb9yjHK7ED2cfMyRsgOTReSpqiy+yJOKSuA6i6Lso=; b=IOpnU2wX3uyj/oWFvJGLzIa/r3rRp+u8XWedotmomzg1kRLp75y/l2pXZbBcbCNIJP NlpThiK9qfxLyxHS8uv3shoXFsa5cQjEu0LMDq9FnTROIjuU5EMe2tfqk/7WvRSJez6F 0odTLqG4+1xq7dGqh+HCWFeraZQiQmNyzRgBmiqknk8GQt1lnAQJ+3NB5dAzawkjS/14 kDpzTZDEk1zjFaHX095Q9qgd5EzGkfTheR2HgBUHrrjCea8pkmvqQOk4RQg37ajufN1j uXxGWaT1JvzWAgffYQQ3vJW9ASpa8//e0vTQI/PMEFqx04P+GNgL842R6OHxFoHd9Zr4 euGg== MIME-Version: 1.0 X-Received: by 10.224.55.131 with SMTP id u3mr11734857qag.98.1406917106397; Fri, 01 Aug 2014 11:18:26 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.1.6 with HTTP; Fri, 1 Aug 2014 11:18:26 -0700 (PDT) In-Reply-To: <20140801153744.GA76021@gmail.com> References: <20140630170453.GA21404@gmail.com> <20140630205359.GA2221@gmail.com> <20140801141920.GC75551@gmail.com> <20140801153744.GA76021@gmail.com> Date: Fri, 1 Aug 2014 11:18:26 -0700 X-Google-Sender-Auth: FP4LM9dvWGGIXe1M1dhzpxcN234 Message-ID: Subject: Re: [PATCH] Implementation of draft-ietf-tcpm-newcwv-06 From: Adrian Chadd To: Tom Jones Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 18:18:27 -0000 Hi! This is looking better! Structurally though, I'd look at all those places where you only update tp->newcv and instead of passing in the tp, pass in a pointer to tp->newcv. That way you're keeping a lid on the scope of the helper functions - they only get access to as much data as they need so you later won't be tempted to do things like go "oh, I just need to get access to this one tcpcb field!" and suddenly it's not so well contained. As for behavioural - I think you'll have to poke Robert or Lawrence a little more just to get some feedback from them. It's good that it's disabled-by-default for now - that lets it get into -HEAD with a lack of surprise. Thanks for doing this! -a From owner-freebsd-net@FreeBSD.ORG Fri Aug 1 21:09:33 2014 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 ESMTPS id 1D9FDCE8; Fri, 1 Aug 2014 21:09:33 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D627B2778; Fri, 1 Aug 2014 21:09:32 +0000 (UTC) Received: from v6.mpls.in ([2a02:978:2::5] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XDG7v-000MGI-Qa; Fri, 01 Aug 2014 20:56:19 +0400 Message-ID: <53DC01DE.3000000@FreeBSD.org> Date: Sat, 02 Aug 2014 01:08:46 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-ipfw , "freebsd-net@freebsd.org" Subject: ipfw named objejcts, table values and syntax change X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 21:09:33 -0000 Hello all. I'm currently working on to enhance ipfw in some areas. The most notable (and user-visible) change is named table support. The other one is support for different lookup algorithms for different key types. For example, new ipfw permits writing this: ipfw table tb1 create type cidr ipfw add allow ip from table(tl1) to any ipfw add allow ip from any lookup dst-ip tb1 ipfw table if1 create type iface ipfw add skipto tablearg ip from any to any via table(if1) or even this: ipfw table fl1 create type flow:src-ip,proto,dst-ip,dst-port ipfw table fl1 add 10.0.0.5,tcp,10.0.0.6,80 4444 ipfw add allow ip from any to any flow table(fl1) all these changes fully preserve backward compatibility. (actually tables needs now to be created before use and their type needs to match with opcode used, but new ipfw(8) performs auto-creation for cidr tables). There is another thing I'm going to change and I'm not sure I can keep the same compatibility level. Table values, from one point of view, can be classified to the following types: - skipto argument - fwd argument (*) - link to another object (nat, pipe, queue) - plain u32 (not bound to any object) (divert/tee,netgraph,tag/utag,limit) There are the following reasons why I think it is necessary to implement explicit table values typing (like tables): - Implementing fwd tablearg for IPv6 hosts requires indirection table - Converting nat/pipe instance ids to names renders values unusable - retiring old hack with storing saved pointer of found object/rule inside rule w/o proper locking - making faster skipto So, as the result, table will have lookup key type (already done), value type ('skipto', 'nexthop', 'nat', 'pipe', 'number', ..) and some additional restrictions (like inability to add non-existing nat instance id). This change will break (at least) scenarios where people are using one table for both nat/pipe instances (and keep nat ids in sync with pipe ones). For example: ipfw table 1 add 10.0.10.0/24 110 ipfw table 1 add 10.0.20.0/24 120 ipfw add 100 nat tablearg from table(1) to any via vlanX in .. ipfw add 500 pipe tablearg from table(1) to any via ix0 out It looks like it is not so easy to bind values for given table to different objects (or different tasks) (and lack of compatibility kills hope for MFC). Ideas? From owner-freebsd-net@FreeBSD.ORG Sat Aug 2 04:26:26 2014 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 ESMTPS id 30884E27; Sat, 2 Aug 2014 04:26:26 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EEC9A263E; Sat, 2 Aug 2014 04:26:25 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-253-202.lns20.per2.internode.on.net [121.45.253.202]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s724QKhE032342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 1 Aug 2014 21:26:22 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <53DC6866.2090205@freebsd.org> Date: Sat, 02 Aug 2014 12:26:14 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Alexander V. Chernikov" , freebsd-ipfw , "freebsd-net@freebsd.org" Subject: Re: ipfw named objejcts, table values and syntax change References: <53DC01DE.3000000@FreeBSD.org> In-Reply-To: <53DC01DE.3000000@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 02 Aug 2014 04:26:26 -0000 On 8/2/14, 5:08 AM, Alexander V. Chernikov wrote: > Hello all. > > I'm currently working on to enhance ipfw in some areas. > The most notable (and user-visible) change is named table support. > The other one is support for different lookup algorithms for different > key types. > > For example, new ipfw permits writing this: > > ipfw table tb1 create type cidr > ipfw add allow ip from table(tl1) to any > ipfw add allow ip from any lookup dst-ip tb1 > > ipfw table if1 create type iface > ipfw add skipto tablearg ip from any to any via table(if1) > > or even this: > ipfw table fl1 create type flow:src-ip,proto,dst-ip,dst-port > ipfw table fl1 add 10.0.0.5,tcp,10.0.0.6,80 4444 > ipfw add allow ip from any to any flow table(fl1) > > all these changes fully preserve backward compatibility. > (actually tables needs now to be created before use and their type needs > to match with opcode used, but new ipfw(8) performs auto-creation > for cidr tables). > > There is another thing I'm going to change and I'm not sure I can keep > the same compatibility level. > > Table values, from one point of view, can be classified to the following > types: > > - skipto argument > - fwd argument (*) > - link to another object (nat, pipe, queue) > - plain u32 (not bound to any object) (divert/tee,netgraph,tag/utag,limit) > > There are the following reasons why I think it is necessary to implement > explicit table values typing (like tables): > - Implementing fwd tablearg for IPv6 hosts requires indirection table > - Converting nat/pipe instance ids to names renders values unusable > - retiring old hack with storing saved pointer of found object/rule > inside rule w/o proper locking > - making faster skipto > > So, as the result, table will have lookup key type (already done), > value type ('skipto', 'nexthop', 'nat', 'pipe', 'number', ..) and some > additional restrictions (like inability to add non-existing nat instance > id). > > This change will break (at least) scenarios where people are > using one table for both nat/pipe instances (and keep nat ids in sync > with pipe ones). For example: > > ipfw table 1 add 10.0.10.0/24 110 > ipfw table 1 add 10.0.20.0/24 120 > > ipfw add 100 nat tablearg from table(1) to any via vlanX in > .. > ipfw add 500 pipe tablearg from table(1) to any via ix0 out > > It looks like it is not so easy to bind values for given table to > different objects (or different tasks) (and lack of compatibility kills > hope for MFC). I think this makes sense I have myself been responsible for adding 'odd' usages to tables e.g. fwd tablearg and have thought myself that "really we need to be able to specify tables more specifically" so don't expect me to argue against this :-) > > Ideas? > > > > > > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Sat Aug 2 06:33:05 2014 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 ESMTPS id 262B880E; Sat, 2 Aug 2014 06:33:05 +0000 (UTC) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1D5EC21D8; Sat, 2 Aug 2014 06:33:03 +0000 (UTC) Received: by mail-lb0-f181.google.com with SMTP id 10so3910485lbg.12 for ; Fri, 01 Aug 2014 23:33:02 -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=9AoiPl5h8zF57KbH4toC+mA857ISwLMk5fgq/yciFvk=; b=AZ+1EGkZBTCUAyjAR3LyenkQ56fHDz1uBjPceGfETDUi1f+F9VnVhheW61H1GZ1LKh qKvQf5U3QxO9nqbSHso9S0e4MwY6cS0vKDjhStrCmKR661Rtk6wgAfPGxkgn57mXR5qg Yy5ynXz9d9hQ55o5yNxouRXrJH2ARG3UNNks9NDW9C9OieBtL8fFDI3XOaKd85pRFwMp oHUTpdliy6xMivnu9af9H1AQnM45r9QzCkGWGeuotr6DtjWF59Vu5asXAaJQRd7Spg7s mlM8QRHHo6R79Spz4S2+9ZxY+fshAyiUe6TjZrQlNYkbLup6QxG7gt8uyFpQx717LTc4 m5+g== MIME-Version: 1.0 X-Received: by 10.152.245.9 with SMTP id xk9mr154107lac.80.1406961181905; Fri, 01 Aug 2014 23:33:01 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.177.234 with HTTP; Fri, 1 Aug 2014 23:33:01 -0700 (PDT) In-Reply-To: <53DC01DE.3000000@FreeBSD.org> References: <53DC01DE.3000000@FreeBSD.org> Date: Sat, 2 Aug 2014 08:33:01 +0200 X-Google-Sender-Auth: iscDiUoXhV8wSwUrZbHWN14NANg Message-ID: Subject: Re: ipfw named objejcts, table values and syntax change From: Luigi Rizzo To: "Alexander V. Chernikov" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-ipfw , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 02 Aug 2014 06:33:05 -0000 On Fri, Aug 1, 2014 at 11:08 PM, Alexander V. Chernikov < melifaro@freebsd.org> wrote: > Hello all. > > I'm currently working on to enhance ipfw in some areas. > The most notable (and user-visible) change is named table support. > The other one is support for different lookup algorithms for different > key types. > > For example, new ipfw permits writing this: > > ipfw table tb1 create type cidr > ipfw add allow ip from table(tl1) to any > ipfw add allow ip from any lookup dst-ip tb1 > > ipfw table if1 create type iface > ipfw add skipto tablearg ip from any to any via table(if1) > > or even this: > ipfw table fl1 create type flow:src-ip,proto,dst-ip,dst-port > ipfw table fl1 add 10.0.0.5,tcp,10.0.0.6,80 4444 > ipfw add allow ip from any to any flow table(fl1) > > all these changes fully preserve backward compatibility. > (actually tables needs now to be created before use and their type needs > to match with opcode used, but new ipfw(8) performs auto-creation > for cidr tables). > > There is another thing I'm going to change and I'm not sure I can keep > the same compatibility level. > > Table values, from one point of view, can be classified to the following > types: > > - skipto argument > - fwd argument (*) > - link to another object (nat, pipe, queue) > - plain u32 (not bound to any object) (divert/tee,netgraph,tag/utag,limit= ) > > There are the following reasons why I think it is necessary to implement > explicit table values typing (like tables): > - Implementing fwd tablearg for IPv6 hosts requires indirection table > - Converting nat/pipe instance ids to names renders values unusable > - retiring old hack with storing saved pointer of found object/rule > inside rule w/o proper locking > - making faster skipto > =E2=80=8B=E2=80=8Bi don't buy the idea that you need typed arguments for all the cases above. Maybe the case that may make sense is the fwd argument (and in the future something else). We already discussed, i think, the fact that now it is legal to have references to non existing things (skipto, pipes etc.) implemented as u32. Removing that would break configurations. Efficiency is not affected, even for skipto, and while i agree that unprotected writes to the pointers in rules should not happen, these pointers are changed infrequently so a global read-mostly lock should be sufficient to protect all changes to the rules. cheers luigi > So, as the result, table will have lookup key type (already done), > value type ('skipto', 'nexthop', 'nat', 'pipe', 'number', ..) and some > additional restrictions (like inability to add non-existing nat instance > id). > > This change will break (at least) scenarios where people are > using one table for both nat/pipe instances (and keep nat ids in sync > with pipe ones). For example: > > ipfw table 1 add 10.0.10.0/24 110 > ipfw table 1 add 10.0.20.0/24 120 > > ipfw add 100 nat tablearg from table(1) to any via vlanX in > .. > ipfw add 500 pipe tablearg from table(1) to any via ix0 out > > It looks like it is not so easy to bind values for given table to > different objects (or different tasks) (and lack of compatibility kills > hope for MFC). > > Ideas? > > > > > > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > --=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) -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Sat Aug 2 08:33:38 2014 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 ESMTPS id 703429A1; Sat, 2 Aug 2014 08:33:38 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0AD002221; Sat, 2 Aug 2014 08:33:38 +0000 (UTC) Received: from v6.mpls.in ([2a02:978:2::5] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XDQnv-00040n-Q2; Sat, 02 Aug 2014 08:20:23 +0400 Message-ID: <53DCA25C.1000108@FreeBSD.org> Date: Sat, 02 Aug 2014 12:33:32 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: ipfw named objejcts, table values and syntax change References: <53DC01DE.3000000@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-ipfw , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 02 Aug 2014 08:33:38 -0000 On 02.08.2014 10:33, Luigi Rizzo wrote: > > > > On Fri, Aug 1, 2014 at 11:08 PM, Alexander V. Chernikov > > wrote: > > Hello all. > > I'm currently working on to enhance ipfw in some areas. > The most notable (and user-visible) change is named table support. > The other one is support for different lookup algorithms for different > key types. > > For example, new ipfw permits writing this: > > ipfw table tb1 create type cidr > ipfw add allow ip from table(tl1) to any > ipfw add allow ip from any lookup dst-ip tb1 > > ipfw table if1 create type iface > ipfw add skipto tablearg ip from any to any via table(if1) > > or even this: > ipfw table fl1 create type flow:src-ip,proto,dst-ip,dst-port > ipfw table fl1 add 10.0.0.5,tcp,10.0.0.6,80 4444 > ipfw add allow ip from any to any flow table(fl1) > > all these changes fully preserve backward compatibility. > (actually tables needs now to be created before use and their type needs > to match with opcode used, but new ipfw(8) performs auto-creation > for cidr tables). > > There is another thing I'm going to change and I'm not sure I can keep > the same compatibility level. > > Table values, from one point of view, can be classified to the following > types: > > - skipto argument > - fwd argument (*) > - link to another object (nat, pipe, queue) > - plain u32 (not bound to any object) > (divert/tee,netgraph,tag/utag,limit) > > There are the following reasons why I think it is necessary to implement > explicit table values typing (like tables): > - Implementing fwd tablearg for IPv6 hosts requires indirection table > - Converting nat/pipe instance ids to names renders values unusable > - retiring old hack with storing saved pointer of found object/rule > inside rule w/o proper locking > - making faster skipto > > > ​​i don't buy the idea that you need typed arguments > for all the cases above. Maybe the case that > may make sense is the fwd argument (and in the future > something else). > We already discussed, i think, the fact that now it > is legal to have references to non existing things > (skipto, pipes etc.) implemented as u32. > Removing that would break configurations. It depends on actual implementation. This can be preserved by auto-creating necessary objects in kernel and/or in userspace, so we can (and should) avoid breaking in this particular way. > > Efficiency is not affected, even for skipto, It depends on workload. While binary search is fast in terms of cpu, it is may be not so fast in terms of memory (since each of the rule is allocated by separate malloc() (and that is another thing which is worth discussing)). > and while i agree that unprotected writes to the pointers > in rules should not happen, these pointers are changed > infrequently so a global read-mostly lock should be > sufficient to protect all changes to the rules. > > cheers > luigi > > > So, as the result, table will have lookup key type (already done), > value type ('skipto', 'nexthop', 'nat', 'pipe', 'number', ..) and some > additional restrictions (like inability to add non-existing nat instance > id). > > This change will break (at least) scenarios where people are > using one table for both nat/pipe instances (and keep nat ids in sync > with pipe ones). For example: > > ipfw table 1 add 10.0.10.0/24 110 > ipfw table 1 add 10.0.20.0/24 120 > > ipfw add 100 nat tablearg from table(1) to any via vlanX in > .. > ipfw add 500 pipe tablearg from table(1) to any via ix0 out > > It looks like it is not so easy to bind values for given table to > different objects (or different tasks) (and lack of compatibility kills > hope for MFC). > > Ideas? > > > > > > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to > "freebsd-ipfw-unsubscribe@freebsd.org > " > > > > > -- > -----------------------------------------+------------------------------- > 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) > -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Sat Aug 2 23:38:47 2014 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 ESMTPS id 4630616A for ; Sat, 2 Aug 2014 23:38:47 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2E0402C6B for ; Sat, 2 Aug 2014 23:38:47 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s72Ncl80054756 for ; Sat, 2 Aug 2014 23:38:47 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 154850] [netgraph] [patch] ng_ether fails to name nodes when the associated interface contains dots or colons Date: Sat, 02 Aug 2014 23:38:47 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ndenev@gmail.com X-Bugzilla-Status: Issue Resolved X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 02 Aug 2014 23:38:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=154850 ndenev@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Issue Resolved Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug.