From owner-freebsd-net@FreeBSD.ORG Mon Aug 20 07:39:58 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF63D106564A; Mon, 20 Aug 2012 07:39:57 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from mail.kirov.so-ups.ru (mail.kirov.so-ups.ru [178.74.170.1]) by mx1.freebsd.org (Postfix) with ESMTP id 95F518FC0A; Mon, 20 Aug 2012 07:39:57 +0000 (UTC) Received: from kas30pipe.localhost (localhost.kirov.so-ups.ru [127.0.0.1]) by mail.kirov.so-ups.ru (Postfix) with SMTP id 18935B8068; Mon, 20 Aug 2012 11:39:50 +0400 (MSK) Received: from kirov.so-ups.ru (unknown [172.21.81.1]) by mail.kirov.so-ups.ru (Postfix) with ESMTP id 13538B8024; Mon, 20 Aug 2012 11:39:50 +0400 (MSK) Received: by ns.kirov.so-ups.ru (Postfix, from userid 1010) id 0BFC5BA0AB; Mon, 20 Aug 2012 11:39:50 +0400 (MSK) Received: from [127.0.0.1] (elsukov.kirov.oduur.so [10.118.3.52]) by ns.kirov.so-ups.ru (Postfix) with ESMTP id C31AABA09D; Mon, 20 Aug 2012 11:39:49 +0400 (MSK) Message-ID: <5031E9C5.9070604@FreeBSD.org> Date: Mon, 20 Aug 2012 11:39:49 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: John Baldwin References: <201208070448.q774mVNm080900@freefall.freebsd.org> <201208070805.43687.jhb@freebsd.org> <502A0FEA.1020808@FreeBSD.org> <201208160816.59655.jhb@freebsd.org> In-Reply-To: <201208160816.59655.jhb@freebsd.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release X-SpamTest-Info: Not protected Cc: freebsd-net@freebsd.org Subject: Re: kern/168742: detaching of ethernet adapter with configured vlans leads to panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Aug 2012 07:39:58 -0000 On 16.08.2012 16:16, John Baldwin wrote: >> This fixes the problem, thanks. > > Can you actually try this patch instead? I think I'd rather fix it this way > (this reworks how I originally tried to fix this): > > Index: if_vlan.c > =================================================================== > --- if_vlan.c (revision 239294) Hi, John. This also works, thanks. -- WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Mon Aug 20 08:27:50 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 42AF9106566B for ; Mon, 20 Aug 2012 08:27:50 +0000 (UTC) (envelope-from freebsd-net@herveybayaustralia.com.au) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) by mx1.freebsd.org (Postfix) with ESMTP id E80EC8FC0C for ; Mon, 20 Aug 2012 08:27:49 +0000 (UTC) Received: from laptop3.herveybayaustralia.com.au (unknown [192.168.0.147]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id 103275C29 for ; Mon, 20 Aug 2012 18:43:08 +1000 (EST) Message-ID: <5031F4FE.50004@herveybayaustralia.com.au> Date: Mon, 20 Aug 2012 18:27:42 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120728 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <502DA0F6.5040305@herveybayaustralia.com.au> <502F80D1.6040901@herveybayaustralia.com.au> <201208181923.04151.bschmidt@techwires.net> In-Reply-To: <201208181923.04151.bschmidt@techwires.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: wpa_supplicant wpa peap gtc connection - gtc failing? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Aug 2012 08:27:50 -0000 On 08/19/12 03:23, Bernhard Schmidt wrote: > On Saturday 18 August 2012 13:47:29 Da Rock wrote: >> On 08/18/12 13:32, Adrian Chadd wrote: >>> Is there any reason we don't build with that option? >> You know, I was wondering that myself but I wasn't exactly sure whether >> to ask or not :) > Historical reasons I guess, our config matches the default > wpa_supplicant config. I don't see any technical reason not to > enable that and bunch of other exotic stuff. > > Though, as you've already noticed, one can count the number of > user who benefit from such a change on one hand.. ;) > Not sure it's worth the effort, though, if someone wants to do > the work, fine with me. > True on that one :) But then again, there are not many as tenacious as I am, and it is not clear that it has not been enabled anywhere. If the build is not worth it, perhaps some documentation to point a user to what can be added to the build? At least that way if someone is intent enough to find the info they can do something about it? Such as myself; if I had of known it needed the option it might have saved me several weeks of messing around. Just a note in the man pages might do, as well as a wiki, or the handbook. Cheers From owner-freebsd-net@FreeBSD.ORG Mon Aug 20 09:05:21 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7163A1065670 for ; Mon, 20 Aug 2012 09:05:21 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id DB8DA8FC0A for ; Mon, 20 Aug 2012 09:05:20 +0000 (UTC) Received: by lage12 with SMTP id e12so3978268lag.13 for ; Mon, 20 Aug 2012 02:05:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=/uIt6koxTbURaupJoRqGeEgTzL7BbYopTKO9tAH9eZE=; b=CUImFfFqCSpp+fVBBSvNX8SLmiz3MMMbAY8VCqGaKETZTQxq5Nb0tkA5tM+c4AX3Vz SPpSqI4NeFlbNAdREy0FVwWQdqdY/YikaT2VhKJzeVyUabR2BzXrqSw+QstDLySbUyoD szKqN+X+xcBEGvHCjGGndinnHJZyOpiFjcH57N7MoSCVSyRwF8jA62mkf9qufFOGQvu/ K2CGgVIhEg9QbMTu+QXwHRSSCdomjJu8NYtqNrahSOzAG3vN3t2ifEczvO1JJ2ZhRNuK zlEfJD9+YxZMNN8Pr7joSVmd9ESS0txdCdLG8AjmSJVVZRUNjvxio3xcxugKV9Dpj96V UgFg== MIME-Version: 1.0 Received: by 10.112.82.42 with SMTP id f10mr5858004lby.95.1345453519351; Mon, 20 Aug 2012 02:05:19 -0700 (PDT) Received: by 10.152.123.200 with HTTP; Mon, 20 Aug 2012 02:05:19 -0700 (PDT) X-Originating-IP: [79.140.39.245] In-Reply-To: <5031F4FE.50004@herveybayaustralia.com.au> References: <502DA0F6.5040305@herveybayaustralia.com.au> <502F80D1.6040901@herveybayaustralia.com.au> <201208181923.04151.bschmidt@techwires.net> <5031F4FE.50004@herveybayaustralia.com.au> Date: Mon, 20 Aug 2012 11:05:19 +0200 Message-ID: From: Bernhard Schmidt To: Da Rock Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmZQopnTYZBmJTenlkqQK9kosJo58qsl/yXm14h4RKIJ+ljXD3+L0sokYnZ9+QgvRxFxhnw Cc: freebsd-net@freebsd.org Subject: Re: wpa_supplicant wpa peap gtc connection - gtc failing? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Aug 2012 09:05:21 -0000 On Mon, Aug 20, 2012 at 10:27 AM, Da Rock wrote: > On 08/19/12 03:23, Bernhard Schmidt wrote: >> >> On Saturday 18 August 2012 13:47:29 Da Rock wrote: >>> >>> On 08/18/12 13:32, Adrian Chadd wrote: >>>> >>>> Is there any reason we don't build with that option? >>> >>> You know, I was wondering that myself but I wasn't exactly sure whether >>> to ask or not :) >> >> Historical reasons I guess, our config matches the default >> wpa_supplicant config. I don't see any technical reason not to >> enable that and bunch of other exotic stuff. >> >> Though, as you've already noticed, one can count the number of >> user who benefit from such a change on one hand.. ;) >> Not sure it's worth the effort, though, if someone wants to do >> the work, fine with me. >> > True on that one :) > > But then again, there are not many as tenacious as I am, and it is not clear > that it has not been enabled anywhere. If the build is not worth it, perhaps > some documentation to point a user to what can be added to the build? At > least that way if someone is intent enough to find the info they can do > something about it? Such as myself; if I had of known it needed the option > it might have saved me several weeks of messing around. > > Just a note in the man pages might do, as well as a wiki, or the handbook. Updating the man page is on my TODO list. It already mentions options which are enabled/disabled by default and also refers to make.conf, but some information is clearly outdated and/or no longer valid. -- Bernhard From owner-freebsd-net@FreeBSD.ORG Mon Aug 20 10:28:48 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7798E106564A; Mon, 20 Aug 2012 10:28:48 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4A1C28FC08; Mon, 20 Aug 2012 10:28:48 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q7KASmQB033543; Mon, 20 Aug 2012 10:28:48 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q7KASmB1033539; Mon, 20 Aug 2012 10:28:48 GMT (envelope-from linimon) Date: Mon, 20 Aug 2012 10:28:48 GMT Message-Id: <201208201028.q7KASmB1033539@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/170701: [ppp] killl ppp or reboot with active ppp connection cause panic when HISADDR set X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Aug 2012 10:28:48 -0000 Old Synopsis: killl ppp or reboot with active ppp connection cause panic when HISADDR set New Synopsis: [ppp] killl ppp or reboot with active ppp connection cause panic when HISADDR set Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Aug 20 10:28:17 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=170701 From owner-freebsd-net@FreeBSD.ORG Mon Aug 20 11:07:55 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C6D37106568D for ; Mon, 20 Aug 2012 11:07:55 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B01928FC17 for ; Mon, 20 Aug 2012 11:07:55 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q7KB7t2n047935 for ; Mon, 20 Aug 2012 11:07:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q7KB7se5047913 for freebsd-net@FreeBSD.org; Mon, 20 Aug 2012 11:07:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 20 Aug 2012 11:07:54 GMT Message-Id: <201208201107.q7KB7se5047913@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Aug 2012 11:07:55 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/170713 net [cxgb] Driver must be loaded after boot due to timing o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169664 net [bgp] Wrongful replacement of interface connected net o kern/169634 net [bge] Network unavailable when booting directly to Fre o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work o kern/169399 net [re] RealTek RTL8168/8111/8111c network interface not o kern/168742 net [vlan] [panic] detaching of ethernet adapter with conf p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/168152 net [xl] Periodically, the network card xl0 stops working o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/167059 net [tcp] [panic] System does panic in in_pcbbind() and ha o kern/166940 net [ipfilter] [panic] Double fault in kern 8.2 o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166372 net [patch] ipfilter drops UDP packets with zero checksum o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis o kern/165963 net [panic] [ipf] ipfilter/nat NULL pointer deference o kern/165903 net mbuf leak o kern/165643 net [net] [patch] Missing vnet restores in net/if_ethersub o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161381 net [re] RTL8169SC - re0: PHY write failed o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel p kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 415 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Aug 20 12:31:42 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1FFA10656F3 for ; Mon, 20 Aug 2012 12:31:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 079018FC22 for ; Mon, 20 Aug 2012 12:31:42 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 53D3CB945; Mon, 20 Aug 2012 08:31:41 -0400 (EDT) From: John Baldwin To: Peter Jeremy Date: Mon, 20 Aug 2012 08:28:48 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <4FFF3683.7020107@rawbw.com> <201208171148.17427.jhb@freebsd.org> <20120817225857.GA2377@server.rulingia.com> In-Reply-To: <20120817225857.GA2377@server.rulingia.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201208200828.48457.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 20 Aug 2012 08:31:41 -0400 (EDT) Cc: freebsd-net@freebsd.org, Yuri Subject: Re: System doesn't detect unplugged network cable and doesn't set interface up properly with DHCP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Aug 2012 12:31:43 -0000 On Friday, August 17, 2012 6:58:58 pm Peter Jeremy wrote: > On 2012-Aug-17 11:48:17 -0400, John Baldwin wrote: > >Hmm, I think I see the issue. It doesn't export the existing lease info to > >the script when running the FAIL action. I just tested this change and it > >removed the old IP on my laptop when I tested it just now. > > I did some investigating during the week and came to pretty much the > same patch. But the existing "don't remove an existing address" > behaviour looked like a design decision and I went digging to find > exactly what ip->client->active represented - and, in particular, > whether in could represent an address that dhclient hadn't added to > the interface. I did find that it could be read from the leases file > but didn't have time to fully work through the code. > > If you're happy that this patch can't incorrectly remove a pre-existing > IP address (I'm now reasonably confident that it can't), then I'm happy > that it otherwise works. I think it should be fine. It's a bit hard to infer exactly what the desired design is from OpenBSD's dhclient code now as it uses a different tack (they don't restart dhclient on link up, but leave the dhclient hanging around and it restarts its own state when the link goes up). -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Mon Aug 20 14:52:31 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9303C106566B; Mon, 20 Aug 2012 14:52:31 +0000 (UTC) (envelope-from mitya@cabletv.dp.ua) Received: from mail.cabletv.dp.ua (mail.cabletv.dp.ua [193.34.20.8]) by mx1.freebsd.org (Postfix) with ESMTP id 4E8468FC0A; Mon, 20 Aug 2012 14:52:31 +0000 (UTC) Received: from [193.34.20.2] (helo=m18.cabletv.dp.ua) by mail.cabletv.dp.ua with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1T3ToR-000JLs-0f; Mon, 20 Aug 2012 18:22:43 +0300 Message-ID: <50324DB4.6080905@cabletv.dp.ua> Date: Mon, 20 Aug 2012 17:46:12 +0300 From: Mitya User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:12.0) Gecko/20120425 Thunderbird/12.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Aug 2012 14:52:31 -0000 Hi. I found some overhead code in /src/sys/net/if_ethersubr.c and /src/sys/netgraph/ng_ether.c It contains strings, like bcopy(src, dst, ETHER_ADDR_LEN); When src and dst are "struct ether_addr*", and ETHER_ADDR_LEN equal 6. This code call every time, when we send Ethernet packet. On example, on my machine in invoked nearly 20K per second. Why we are use bcopy(), to copy only 6 bytes? Answer - in some architectures we are can not directly copy unaligned data. I propose this solution. In file /usr/src/include/net/ethernet.h add this lines: static inline void ether_addr_copy(ether_addr* src, ether_addr* dst) { #if defined(__i386__) || defined(__amd64__) *dst = *src; #else bcopy(src, dst, ETHER_ADDR_LEN); #endif } On platform i386 gcc produce like this code: leal -30(%ebp), %eax leal 6(%eax), %ecx leal -44(%ebp), %edx movl (%edx), %eax movl %eax, (%ecx) movzwl 4(%edx), %eax movw %ax, 4(%ecx) And clang produce this: movl -48(%ebp), %ecx movl %ecx, -26(%ebp) movw -44(%ebp), %si movw %si, -22(%ebp) All this variants are much faster, than bcopy() From owner-freebsd-net@FreeBSD.ORG Mon Aug 20 16:41:17 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CFCB51065673 for ; Mon, 20 Aug 2012 16:41:17 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9B9CC8FC16 for ; Mon, 20 Aug 2012 16:41:17 +0000 (UTC) Received: by dadr6 with SMTP id r6so2427082dad.13 for ; Mon, 20 Aug 2012 09:41:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=ATR+a737mE2XVMGayWXiEhZO8qe2Cf9Rroa14hntcsI=; b=YCYYkvsfNnvMnrhxIHmnhWD3mydy1LNDxCmIG28PwxktlUAZsdQ70jmcrjZ3qL1Dh/ ZbRmyFNfLQCTxfflHTWUcRJkPTU0//eQp+16AFIxkJlXWEzJ8FDGL0iBD2RuUx2TL8We 3493rvVS2xpwSnLQf39hRDp9V0LZLw2JVvOfhR7FlwIr1e7TfkdA0LgmmCLLtSUWJx97 9WcY8+hOmQr0r7uz7K1z/xmG9K8w+phC7/WyW8IP6q7iOPsxtSY8rjtn4hQmVrmMKXqW 9ljdYQ5fiIy32Lki8+RhWK5Rkz0f2tI0o7jQcmZNv9y87WvJrzXY+B3s/zEBi9dexBDd 4JYA== Received: by 10.66.74.100 with SMTP id s4mr30960611pav.27.1345480877170; Mon, 20 Aug 2012 09:41:17 -0700 (PDT) Received: from fusionlt2834a.int.fusionio.com ([216.51.42.66]) by mx.google.com with ESMTPS id kt2sm11392939pbc.73.2012.08.20.09.41.16 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Aug 2012 09:41:16 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <50324DB4.6080905@cabletv.dp.ua> Date: Mon, 20 Aug 2012 10:41:15 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <4C06696D-EF17-411D-A229-B738B9D47B8A@bsdimp.com> References: <50324DB4.6080905@cabletv.dp.ua> To: Mitya X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmXtRg5Rupgvl6j+HNifceKG1AVoGjzRLfyVzo5HxT7hhZhdAmMeyReRDbXdh7TMyfSNIOT Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Aug 2012 16:41:17 -0000 On Aug 20, 2012, at 8:46 AM, Mitya wrote: > Hi. > I found some overhead code in /src/sys/net/if_ethersubr.c and = /src/sys/netgraph/ng_ether.c >=20 > It contains strings, like bcopy(src, dst, ETHER_ADDR_LEN); > When src and dst are "struct ether_addr*", and ETHER_ADDR_LEN equal 6. > This code call every time, when we send Ethernet packet. > On example, on my machine in invoked nearly 20K per second. >=20 > Why we are use bcopy(), to copy only 6 bytes? > Answer - in some architectures we are can not directly copy unaligned = data. True for shorts, longs, etc. But why do we need it for ether_addr? It = is a struct that's just an array... That's always safe. > I propose this solution. >=20 > In file /usr/src/include/net/ethernet.h add this lines: >=20 > static inline void ether_addr_copy(ether_addr* src, ether_addr* dst) { > #if defined(__i386__) || defined(__amd64__) Bleck. that's uber ugly. We have a define for unaligned vs aligned = architectures. we should use that here. If we even need this ifdef at = all. Warner > *dst =3D *src; > #else > bcopy(src, dst, ETHER_ADDR_LEN); > #endif > } >=20 > On platform i386 gcc produce like this code: > leal -30(%ebp), %eax > leal 6(%eax), %ecx > leal -44(%ebp), %edx > movl (%edx), %eax > movl %eax, (%ecx) > movzwl 4(%edx), %eax > movw %ax, 4(%ecx) > And clang produce this: > movl -48(%ebp), %ecx > movl %ecx, -26(%ebp) > movw -44(%ebp), %si > movw %si, -22(%ebp) >=20 >=20 > All this variants are much faster, than bcopy() >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Aug 20 16:49:31 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0888910656D8; Mon, 20 Aug 2012 16:49:31 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id D53C68FC1E; Mon, 20 Aug 2012 16:49:24 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q7KGmitp035334; Mon, 20 Aug 2012 18:48:48 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q7KGmd0Y035331; Mon, 20 Aug 2012 18:48:43 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Mon, 20 Aug 2012 18:48:39 +0200 (CEST) From: Wojciech Puchar To: Mitya In-Reply-To: <50324DB4.6080905@cabletv.dp.ua> Message-ID: References: <50324DB4.6080905@cabletv.dp.ua> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Mon, 20 Aug 2012 18:48:49 +0200 (CEST) Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Aug 2012 16:49:31 -0000 > #if defined(__i386__) || defined(__amd64__) > *dst = *src; > #else > bcopy(src, dst, ETHER_ADDR_LEN); #else short *tmp1=((*short)src),*tmp2=((*short)dst); *tmp2=*tmp1; *(tmp2+1)=*(tmp1+1); *(tmp2+2)=*(tmp1+2); or use ++. i think it is always aligned to 2 bytes and this should produce usable code on any CPU? should be 6 instructions on MIPS and PPC IMHO. From owner-freebsd-net@FreeBSD.ORG Mon Aug 20 19:06:01 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0F1241065672 for ; Mon, 20 Aug 2012 19:06:01 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id C50DC8FC0C for ; Mon, 20 Aug 2012 19:06:00 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so7790364pbb.13 for ; Mon, 20 Aug 2012 12:05:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=FV6OYrlPxmmTMb7e2jr7yrc99awCVz+KDCbQ4Fh3tu8=; b=JNCHTshHTQbKmMBsGSs6UehqU5EQ9pKdx6GrkuWcxnGKCXIepPH0HXCL34sDUB5vCJ IU/oWSPIIOHzfy7ib04kK6AKIel+MG3WrHNsJFB2M/yGnc5Zv0hdLit4SlXRaHbjb/TE qKN7GSBxDmsvDqReK4Dx+5qO+lC0R+p0X7Lz7OmUrvpq8Yq+oszllfEYfhKdMdkRSF9A 3czVJ6cIqta40p+dOhhUE0wmNl/UC2483UmgLr4kJLAZOqJzcMZPffD2b1XBgUqp8XPe WAd2vjuZUCsz0fxd0ezDS8o7ZzQBx9Mz4dlMh1MwwQR0HdAtSoh4PSSfpEwG/yVrnB21 5fEg== Received: by 10.68.234.169 with SMTP id uf9mr29989923pbc.105.1345489554129; Mon, 20 Aug 2012 12:05:54 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([216.51.42.66]) by mx.google.com with ESMTPS id ka4sm6249974pbc.61.2012.08.20.12.05.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Aug 2012 12:05:53 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Mon, 20 Aug 2012 13:05:51 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50324DB4.6080905@cabletv.dp.ua> To: Wojciech Puchar X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQlexYRmCnhM7NaM8exhZRtyNWmdp3FeTy0Ie1z95bHcBU6klq/EttI60kO5bEQhh1IZJ4EO Cc: freebsd-hackers@freebsd.org, Mitya , freebsd-net@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Aug 2012 19:06:01 -0000 On Aug 20, 2012, at 10:48 AM, Wojciech Puchar wrote: >> #if defined(__i386__) || defined(__amd64__) >> *dst =3D *src; >> #else >> bcopy(src, dst, ETHER_ADDR_LEN); > #else > short *tmp1=3D((*short)src),*tmp2=3D((*short)dst); > *tmp2=3D*tmp1; *(tmp2+1)=3D*(tmp1+1); *(tmp2+2)=3D*(tmp1+2); >=20 > or use ++. >=20 > i think it is always aligned to 2 bytes and this should produce usable = code on any CPU? should be 6 instructions on MIPS and PPC IMHO. We should tag it as __aligned(2) then, no? If so, then the compiler = should generate the code you posted. Warner From owner-freebsd-net@FreeBSD.ORG Mon Aug 20 19:19:10 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40C0F10656A4; Mon, 20 Aug 2012 19:19:10 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 4F0C78FC1A; Mon, 20 Aug 2012 19:19:04 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q7KJI5f1019376; Mon, 20 Aug 2012 21:18:07 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q7KJHwPa019373; Mon, 20 Aug 2012 21:18:01 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Mon, 20 Aug 2012 21:17:58 +0200 (CEST) From: Wojciech Puchar To: Warner Losh In-Reply-To: Message-ID: References: <50324DB4.6080905@cabletv.dp.ua> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Mon, 20 Aug 2012 21:18:10 +0200 (CEST) Cc: freebsd-hackers@freebsd.org, Mitya , freebsd-net@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Aug 2012 19:19:10 -0000 >> or use ++. >> >> i think it is always aligned to 2 bytes and this should produce usable code on any CPU? should be 6 instructions on MIPS and PPC IMHO. > > We should tag it as __aligned(2) then, no? If so, then the compiler should generate the code you posted. should is the most important word in Your post. what it actually do - i don't know. From owner-freebsd-net@FreeBSD.ORG Mon Aug 20 19:20:33 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F03D7106566C for ; Mon, 20 Aug 2012 19:20:32 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id B871F8FC12 for ; Mon, 20 Aug 2012 19:20:32 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so7809388pbb.13 for ; Mon, 20 Aug 2012 12:20:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=KCxyECDI8FnX8CSLsoeicy0Z5QcbV3tJPV8iRNrzmKs=; b=JDuWWemgez7yci3JPWTfC7Z7kCMI4uVHu4L/Pf/KWlmRlfshuj+GcKIjYMHv0B737w Hl794s+R+u7JKnQIZZW5FngRw7OMuBRIzGkkNeswRG6ihOWx+LmVHyKWEndy398lpWkv WJuF5MA1VPqrBWnNq8Dg1vA1h41B2AOP/Pg4l/8y7VwVjKWzK8QhNAWXFtHAkOkprgxq eeMUXU3VqAY1LIw7W60lMNXi2RGy2DlvDNOR787hr7i9AaII59pjt8udQ775izvxTidr kPgomZ8/dO8+5pfIcVdpOfs+SHl8Bg0z9suTR8Uw7Jn9fbBrO/wovEiFFI58rmOXfjXi jGPA== Received: by 10.68.130.65 with SMTP id oc1mr36887796pbb.29.1345490432225; Mon, 20 Aug 2012 12:20:32 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([216.51.42.66]) by mx.google.com with ESMTPS id ty1sm8562932pbc.76.2012.08.20.12.20.31 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Aug 2012 12:20:31 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Mon, 20 Aug 2012 13:20:29 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <5452BF37-3658-4C1F-B965-CE3EA28B6EA5@bsdimp.com> References: <50324DB4.6080905@cabletv.dp.ua> To: Wojciech Puchar X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnreGF9F4i+OdHnj+ME0Z86Crff2r6bYNyphhParEl5NW32Ly1hoLa9A9rJ6hrw5GgYOYmu Cc: freebsd-hackers@freebsd.org, Mitya , freebsd-net@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Aug 2012 19:20:33 -0000 On Aug 20, 2012, at 1:17 PM, Wojciech Puchar wrote: >>> or use ++. >>>=20 >>> i think it is always aligned to 2 bytes and this should produce = usable code on any CPU? should be 6 instructions on MIPS and PPC IMHO. >>=20 >> We should tag it as __aligned(2) then, no? If so, then the compiler = should generate the code you posted. > should is the most important word in Your post. what it actually do - = i don't know. If we are requiring this to be __aligned(2), we should tag it as such to = enforce this. Even without this tagging, the code to do a structure level copy of 6 = bytes is going to be tiny... Warner From owner-freebsd-net@FreeBSD.ORG Mon Aug 20 19:26:00 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C43DD106564A; Mon, 20 Aug 2012 19:26:00 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by mx1.freebsd.org (Postfix) with ESMTP id A5EC68FC12; Mon, 20 Aug 2012 19:26:00 +0000 (UTC) Received: from bitblocks.com (localhost [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id C8F24B827; Mon, 20 Aug 2012 12:20:32 -0700 (PDT) To: Warner Losh In-reply-to: Your message of "Mon, 20 Aug 2012 13:05:51 MDT." References: <50324DB4.6080905@cabletv.dp.ua> Comments: In-reply-to Warner Losh message dated "Mon, 20 Aug 2012 13:05:51 -0600." Date: Mon, 20 Aug 2012 12:20:32 -0700 From: Bakul Shah Message-Id: <20120820192032.C8F24B827@mail.bitblocks.com> Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Aug 2012 19:26:00 -0000 On Mon, 20 Aug 2012 13:05:51 MDT Warner Losh wrote: > > On Aug 20, 2012, at 10:48 AM, Wojciech Puchar wrote: > > >> #if defined(__i386__) || defined(__amd64__) > >> *dst =3D *src; > >> #else > >> bcopy(src, dst, ETHER_ADDR_LEN); > > #else > > short *tmp1=3D((*short)src),*tmp2=3D((*short)dst); > > *tmp2=3D*tmp1; *(tmp2+1)=3D*(tmp1+1); *(tmp2+2)=3D*(tmp1+2); > > > > or use ++. > > > > i think it is always aligned to 2 bytes and this should produce usable > code on any CPU? should be 6 instructions on MIPS and PPC IMHO. > > We should tag it as __aligned(2) then, no? If so, then the compiler > should generate the code you posted. Doesn't gcc inline memcpy these days? From owner-freebsd-net@FreeBSD.ORG Tue Aug 21 06:35:57 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CC53A106566B; Tue, 21 Aug 2012 06:35:57 +0000 (UTC) (envelope-from mitya@cabletv.dp.ua) Received: from mail.cabletv.dp.ua (mail.cabletv.dp.ua [193.34.20.8]) by mx1.freebsd.org (Postfix) with ESMTP id 831A58FC19; Tue, 21 Aug 2012 06:35:57 +0000 (UTC) Received: from [193.34.20.2] (helo=m18.cabletv.dp.ua) by mail.cabletv.dp.ua with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1T3iXa-000FDf-N9; Tue, 21 Aug 2012 10:06:18 +0300 Message-ID: <50332AD8.6020800@cabletv.dp.ua> Date: Tue, 21 Aug 2012 09:29:44 +0300 From: Mitya User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:12.0) Gecko/20120425 Thunderbird/12.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org References: <50324DB4.6080905@cabletv.dp.ua> <5452BF37-3658-4C1F-B965-CE3EA28B6EA5@bsdimp.com> In-Reply-To: <5452BF37-3658-4C1F-B965-CE3EA28B6EA5@bsdimp.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Aug 2012 06:35:57 -0000 20.08.2012 22:20, Warner Losh напиÑал: > On Aug 20, 2012, at 1:17 PM, Wojciech Puchar wrote: > >>>> or use ++. >>>> >>>> i think it is always aligned to 2 bytes and this should produce usable code on any CPU? should be 6 instructions on MIPS and PPC IMHO. >>> We should tag it as __aligned(2) then, no? If so, then the compiler should generate the code you posted. >> should is the most important word in Your post. what it actually do - i don't know. > If we are requiring this to be __aligned(2), we should tag it as such to enforce this. > > Even without this tagging, the code to do a structure level copy of 6 bytes is going to be tiny... > > Warner > I try some times different algorithms. This is one of thees: *(u_int32_t *)(dst) = *(u_int32_t *)(src); *(u_int16_t *)&(dst->octet[4]) = *(u_int16_t *)&(src->octet[4]); But, internal gcc and clang optimisations are much better, than my attempt. For aligned platforms (2 bytes aligned) best choice is *dst = *src; From owner-freebsd-net@FreeBSD.ORG Tue Aug 21 07:44:49 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E2D77106564A; Tue, 21 Aug 2012 07:44:49 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 186B48FC08; Tue, 21 Aug 2012 07:44:43 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q7L7hAjc033858; Tue, 21 Aug 2012 09:43:16 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q7L7gxEW033855; Tue, 21 Aug 2012 09:43:06 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Tue, 21 Aug 2012 09:42:59 +0200 (CEST) From: Wojciech Puchar To: Warner Losh In-Reply-To: <5452BF37-3658-4C1F-B965-CE3EA28B6EA5@bsdimp.com> Message-ID: References: <50324DB4.6080905@cabletv.dp.ua> <5452BF37-3658-4C1F-B965-CE3EA28B6EA5@bsdimp.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Tue, 21 Aug 2012 09:43:20 +0200 (CEST) Cc: freebsd-hackers@freebsd.org, Mitya , freebsd-net@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Aug 2012 07:44:50 -0000 > > Even without this tagging, the code to do a structure level copy of 6 bytes is going to be tiny... true. just to make sure it will be absolutely portable how about bcopymacaddress(dst,src) and then define it whatever you find it fastest on any architecture? From owner-freebsd-net@FreeBSD.ORG Tue Aug 21 10:26:34 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E6C7D1065674; Tue, 21 Aug 2012 10:26:34 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 7E2B48FC0A; Tue, 21 Aug 2012 10:26:34 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q7LAQVup089793; Tue, 21 Aug 2012 12:26:31 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q7LAQVVM089792; Tue, 21 Aug 2012 12:26:31 +0200 (CEST) (envelope-from marius) Date: Tue, 21 Aug 2012 12:26:30 +0200 From: Marius Strobl To: Mitya Message-ID: <20120821102630.GA89551@alchemy.franken.de> References: <50324DB4.6080905@cabletv.dp.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50324DB4.6080905@cabletv.dp.ua> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Aug 2012 10:26:35 -0000 On Mon, Aug 20, 2012 at 05:46:12PM +0300, Mitya wrote: > Hi. > I found some overhead code in /src/sys/net/if_ethersubr.c and > /src/sys/netgraph/ng_ether.c > > It contains strings, like bcopy(src, dst, ETHER_ADDR_LEN); > When src and dst are "struct ether_addr*", and ETHER_ADDR_LEN equal 6. > This code call every time, when we send Ethernet packet. > On example, on my machine in invoked nearly 20K per second. > > Why we are use bcopy(), to copy only 6 bytes? > Answer - in some architectures we are can not directly copy unaligned data. > > I propose this solution. > > In file /usr/src/include/net/ethernet.h add this lines: > > static inline void ether_addr_copy(ether_addr* src, ether_addr* dst) { > #if defined(__i386__) || defined(__amd64__) > *dst = *src; > #else > bcopy(src, dst, ETHER_ADDR_LEN); > #endif > } > > On platform i386 gcc produce like this code: > leal -30(%ebp), %eax > leal 6(%eax), %ecx > leal -44(%ebp), %edx > movl (%edx), %eax > movl %eax, (%ecx) > movzwl 4(%edx), %eax > movw %ax, 4(%ecx) > And clang produce this: > movl -48(%ebp), %ecx > movl %ecx, -26(%ebp) > movw -44(%ebp), %si > movw %si, -22(%ebp) > > > All this variants are much faster, than bcopy() > A bit orthogonal to this but also related to the performance impact of these bcopy() calls, for !__NO_STRICT_ALIGNMENT architectures these places probably should use memcpy() instead as bcopy() additionally has to check for overlap while the former does not. Overlaps unlikely are an issue in these cases and at least NetBSD apparently has done the switch to memcpy() 5.5 years ago. Marius From owner-freebsd-net@FreeBSD.ORG Tue Aug 21 11:12:51 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A736106564A; Tue, 21 Aug 2012 11:12:50 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id E885E8FC17; Tue, 21 Aug 2012 11:12:48 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 3DF647300A; Tue, 21 Aug 2012 13:24:15 +0200 (CEST) Date: Tue, 21 Aug 2012 13:24:15 +0200 From: Luigi Rizzo To: Marius Strobl Message-ID: <20120821112415.GA50078@onelab2.iet.unipi.it> References: <50324DB4.6080905@cabletv.dp.ua> <20120821102630.GA89551@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120821102630.GA89551@alchemy.franken.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org, Mitya , freebsd-net@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Aug 2012 11:12:51 -0000 On Tue, Aug 21, 2012 at 12:26:30PM +0200, Marius Strobl wrote: ... > > Why we are use bcopy(), to copy only 6 bytes? > > Answer - in some architectures we are can not directly copy unaligned data. > > > > I propose this solution. > > > > In file /usr/src/include/net/ethernet.h add this lines: > > > > static inline void ether_addr_copy(ether_addr* src, ether_addr* dst) { > > #if defined(__i386__) || defined(__amd64__) > > *dst = *src; > > #else > > bcopy(src, dst, ETHER_ADDR_LEN); > > #endif > > } ... > > All this variants are much faster, than bcopy() > > > > A bit orthogonal to this but also related to the performance > impact of these bcopy() calls, for !__NO_STRICT_ALIGNMENT > architectures these places probably should use memcpy() > instead as bcopy() additionally has to check for overlap > while the former does not. Overlaps unlikely are an issue > in these cases and at least NetBSD apparently has done the > switch to memcpy() 5.5 years ago. even more orthogonal: I found that copying 8n + (5, 6 or 7) bytes was much much slower than copying a multiple of 8 bytes. For n=0, 1,2,4,8 bytes are efficient, other cases are slow (turned into 2 or 3 different writes). The netmap code uses a pkt_copy routine that does exactly this rounding, gaining some 10-20ns per packet for small sizes. cheers luigi From owner-freebsd-net@FreeBSD.ORG Tue Aug 21 11:27:00 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0CFF51065672; Tue, 21 Aug 2012 11:27:00 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 92C848FC08; Tue, 21 Aug 2012 11:26:59 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q7LBQtKZ090094; Tue, 21 Aug 2012 13:26:55 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q7LBQtv0090093; Tue, 21 Aug 2012 13:26:55 +0200 (CEST) (envelope-from marius) Date: Tue, 21 Aug 2012 13:26:55 +0200 From: Marius Strobl To: Warner Losh Message-ID: <20120821112655.GA90066@alchemy.franken.de> References: <50324DB4.6080905@cabletv.dp.ua> <5452BF37-3658-4C1F-B965-CE3EA28B6EA5@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5452BF37-3658-4C1F-B965-CE3EA28B6EA5@bsdimp.com> User-Agent: Mutt/1.4.2.3i Cc: Wojciech Puchar , freebsd-net@freebsd.org, Mitya , freebsd-hackers@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Aug 2012 11:27:00 -0000 On Mon, Aug 20, 2012 at 01:20:29PM -0600, Warner Losh wrote: > > On Aug 20, 2012, at 1:17 PM, Wojciech Puchar wrote: > > >>> or use ++. > >>> > >>> i think it is always aligned to 2 bytes and this should produce usable code on any CPU? should be 6 instructions on MIPS and PPC IMHO. > >> > >> We should tag it as __aligned(2) then, no? If so, then the compiler should generate the code you posted. > > should is the most important word in Your post. what it actually do - i don't know. > > If we are requiring this to be __aligned(2), we should tag it as such to enforce this. > > Even without this tagging, the code to do a structure level copy of 6 bytes is going to be tiny... > While the __aligned(2) approach certainly works, I've actually rather mixed experiences on x86 with it as the compiler doesn't necessarily produce the small and efficient one would expect from code it. Such a change certainly shouldn't be done just on the assumption that the compiler has all hints required to produce good code from it but the resulting asm should be verified across all affected architectures. Marius From owner-freebsd-net@FreeBSD.ORG Tue Aug 21 11:52:50 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A28EB106566C; Tue, 21 Aug 2012 11:52:50 +0000 (UTC) (envelope-from mitya@cabletv.dp.ua) Received: from mail.cabletv.dp.ua (mail.cabletv.dp.ua [193.34.20.8]) by mx1.freebsd.org (Postfix) with ESMTP id 586228FC08; Tue, 21 Aug 2012 11:52:49 +0000 (UTC) Received: from [193.34.20.2] (helo=m18.cabletv.dp.ua) by mail.cabletv.dp.ua with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1T3nUG-000C1A-Uv; Tue, 21 Aug 2012 15:23:12 +0300 Message-ID: <5033751C.1050405@cabletv.dp.ua> Date: Tue, 21 Aug 2012 14:46:36 +0300 From: Mitya User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:12.0) Gecko/20120425 Thunderbird/12.0 MIME-Version: 1.0 To: Marius Strobl , freebsd-hackers@freebsd.org, freebsd-net@freebsd.org References: <50324DB4.6080905@cabletv.dp.ua> <5452BF37-3658-4C1F-B965-CE3EA28B6EA5@bsdimp.com> <20120821112655.GA90066@alchemy.franken.de> In-Reply-To: <20120821112655.GA90066@alchemy.franken.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Aug 2012 11:52:50 -0000 21.08.2012 14:26, Marius Strobl напиÑал: > On Mon, Aug 20, 2012 at 01:20:29PM -0600, Warner Losh wrote: >> On Aug 20, 2012, at 1:17 PM, Wojciech Puchar wrote: >> >>>>> or use ++. >>>>> >>>>> i think it is always aligned to 2 bytes and this should produce usable code on any CPU? should be 6 instructions on MIPS and PPC IMHO. >>>> We should tag it as __aligned(2) then, no? If so, then the compiler should generate the code you posted. >>> should is the most important word in Your post. what it actually do - i don't know. >> If we are requiring this to be __aligned(2), we should tag it as such to enforce this. >> >> Even without this tagging, the code to do a structure level copy of 6 bytes is going to be tiny... >> > While the __aligned(2) approach certainly works, I've actually rather > mixed experiences on x86 with it as the compiler doesn't necessarily > produce the small and efficient one would expect from code it. Such > a change certainly shouldn't be done just on the assumption that the > compiler has all hints required to produce good code from it but the > resulting asm should be verified across all affected architectures. > > Marius > Yes. I totally agree. That is why I have limited use of this feature only i386 and amd64 architectures. From owner-freebsd-net@FreeBSD.ORG Tue Aug 21 14:31:07 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9AD24106566C for ; Tue, 21 Aug 2012 14:31:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 475CF8FC12 for ; Tue, 21 Aug 2012 14:31:06 +0000 (UTC) Received: by ghrr13 with SMTP id r13so7106642ghr.13 for ; Tue, 21 Aug 2012 07:31:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Z8zhGvHY93h9EY1pX0YkjsVQ0qYTIAiQ0DLQIrqs7y8=; b=muGXctDNQ//uAdSYQC11Q6W3um+iElodjqh1yBdcYcdnDue3BaHsiLEG3UhIbV5yS8 dabWwNRJbT2MByNAtawB4ecC7FLcvQSoZ4zTLGarZOebHaq8mdbhOJ8hAgfCUVGlhyqj v76cUntcHjl1Xfcy2j/Bw6gR/4S9Aaoisn6fS0Nw6+izk/1z9Fa+quuT5nt2hsHW7nm3 jzoBWk+weA4kI0+ov03HnckWUq8sD2bAuiyrwoTiKjyyX6fkXSaB0pjHdaJkhqlZnDge xEX5vMIhQ5LZgkhJKmsULblw1/AtVcOdmKtlbBhcqMIbh2/QRbKYlyzH1Nm56un9Xu+0 iMfA== Received: by 10.60.3.202 with SMTP id e10mr12977176oee.52.1345559465531; Tue, 21 Aug 2012 07:31:05 -0700 (PDT) Received: from [192.168.100.235] (70-90-212-28-saltlake.hfc.comcastbusiness.net. [70.90.212.28]) by mx.google.com with ESMTPS id th3sm1375715obb.6.2012.08.21.07.31.02 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Aug 2012 07:31:04 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20120821112655.GA90066@alchemy.franken.de> Date: Tue, 21 Aug 2012 08:31:00 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <92186FE4-F83A-43A2-B1C9-85A1C42513AC@bsdimp.com> References: <50324DB4.6080905@cabletv.dp.ua> <5452BF37-3658-4C1F-B965-CE3EA28B6EA5@bsdimp.com> <20120821112655.GA90066@alchemy.franken.de> To: Marius Strobl X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmEHGx5J1BHJZVkIbGbILWrKem4v5T+cxmjRnnjqRdPa4ejsjsrprjR2Xj/ecLaNaRnHwla Cc: Wojciech Puchar , freebsd-net@freebsd.org, Mitya , freebsd-hackers@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Aug 2012 14:31:07 -0000 On Aug 21, 2012, at 5:26 AM, Marius Strobl wrote: > On Mon, Aug 20, 2012 at 01:20:29PM -0600, Warner Losh wrote: >>=20 >> On Aug 20, 2012, at 1:17 PM, Wojciech Puchar wrote: >>=20 >>>>> or use ++. >>>>>=20 >>>>> i think it is always aligned to 2 bytes and this should produce = usable code on any CPU? should be 6 instructions on MIPS and PPC IMHO. >>>>=20 >>>> We should tag it as __aligned(2) then, no? If so, then the = compiler should generate the code you posted. >>> should is the most important word in Your post. what it actually do = - i don't know. >>=20 >> If we are requiring this to be __aligned(2), we should tag it as such = to enforce this. >>=20 >> Even without this tagging, the code to do a structure level copy of 6 = bytes is going to be tiny... >>=20 >=20 > While the __aligned(2) approach certainly works, I've actually rather > mixed experiences on x86 with it as the compiler doesn't necessarily > produce the small and efficient one would expect from code it. Such > a change certainly shouldn't be done just on the assumption that the > compiler has all hints required to produce good code from it but the > resulting asm should be verified across all affected architectures. Very true... I would have thought that went without saying... Warner= From owner-freebsd-net@FreeBSD.ORG Tue Aug 21 14:52:56 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9DEB1065676; Tue, 21 Aug 2012 14:52:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id C00D58FC0A; Tue, 21 Aug 2012 14:52:56 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3D4B9B96C; Tue, 21 Aug 2012 10:52:56 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 21 Aug 2012 09:43:08 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <50324DB4.6080905@cabletv.dp.ua> In-Reply-To: <50324DB4.6080905@cabletv.dp.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201208210943.08341.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 21 Aug 2012 10:52:56 -0400 (EDT) Cc: freebsd-net@freebsd.org, Mitya Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Aug 2012 14:52:57 -0000 On Monday, August 20, 2012 10:46:12 am Mitya wrote: > Hi. > I found some overhead code in /src/sys/net/if_ethersubr.c and > /src/sys/netgraph/ng_ether.c > > It contains strings, like bcopy(src, dst, ETHER_ADDR_LEN); > When src and dst are "struct ether_addr*", and ETHER_ADDR_LEN equal 6. > This code call every time, when we send Ethernet packet. > On example, on my machine in invoked nearly 20K per second. > > Why we are use bcopy(), to copy only 6 bytes? > Answer - in some architectures we are can not directly copy unaligned data. > > I propose this solution. > > In file /usr/src/include/net/ethernet.h add this lines: > > static inline void ether_addr_copy(ether_addr* src, ether_addr* dst) { > #if defined(__i386__) || defined(__amd64__) > *dst = *src; > #else > bcopy(src, dst, ETHER_ADDR_LEN); > #endif > } Doesn't '*dst = *src' just work on all platforms? -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Aug 21 15:20:42 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35036106564A for ; Tue, 21 Aug 2012 15:20:42 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id D611E8FC16 for ; Tue, 21 Aug 2012 15:20:41 +0000 (UTC) Received: by ghrr13 with SMTP id r13so7176041ghr.13 for ; Tue, 21 Aug 2012 08:20:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=cacyrk3J+IwdSKDlz7T2ePwBidhF7kPNpUh4nz7UdIA=; b=PtHRcwS5AE6c3OVZ44KSTsPsLQ3hUxB6cuvYT1KrPW+aGAKwHljgWBOJbLDaC2epEF MnKrEFHgJKlwDoONI71DYrbZEqdUAuiDGmIvcqymzehmjDZr5QrxfYsnqHL2KxE9hMXz GzgWnmFVJgNFDGRErHbe8yzmzsxsX50Q0/n2PQueYlsnqd7tOrnASRVpHIpcDFObvMqg LqC1l96k8ZPNzXv/jztx3/L4ds2BVJAXAeiNJ+u4Kez9H31dYgehlCfhiWEg4YfrZJA2 OBAI5dy3I636X8UhDVy4Ek4GrJbaIX+rBdREKJ4aN6P2sk1T0I6FEKQE5gwT/WZ1sY5W aSpA== Received: by 10.68.232.138 with SMTP id to10mr7286064pbc.77.1345562440844; Tue, 21 Aug 2012 08:20:40 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([216.51.42.66]) by mx.google.com with ESMTPS id sr3sm1634505pbc.44.2012.08.21.08.20.39 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Aug 2012 08:20:40 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Tue, 21 Aug 2012 09:20:38 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <420BA06C-C776-47DB-B3BB-F1414C115F99@bsdimp.com> References: <50324DB4.6080905@cabletv.dp.ua> <5452BF37-3658-4C1F-B965-CE3EA28B6EA5@bsdimp.com> To: Wojciech Puchar X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQlCamnODPW6QwVFzTQDCYg7tFKh2MWZ2/8yRObtUuZKrWK0TuRI2yuDDmC9+roJC8QF7Fn2 Cc: freebsd-hackers@freebsd.org, Mitya , freebsd-net@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Aug 2012 15:20:42 -0000 On Aug 21, 2012, at 1:42 AM, Wojciech Puchar wrote: >>=20 >> Even without this tagging, the code to do a structure level copy of 6 = bytes is going to be tiny... >=20 > true. >=20 > just to make sure it will be absolutely portable how about >=20 > bcopymacaddress(dst,src) >=20 > and then define it whatever you find it fastest on any architecture? How about just changing it to the *dst =3D *src, compiling it on all = architectures and then deciding if the improvement of the code from a = hand-tweaked thing is worth that uglification? Warner From owner-freebsd-net@FreeBSD.ORG Tue Aug 21 16:34:43 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF9B91065672; Tue, 21 Aug 2012 16:34:43 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 770548FC0A; Tue, 21 Aug 2012 16:34:43 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so189613pbb.13 for ; Tue, 21 Aug 2012 09:34:43 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=8b6dj4QLnpKsuRXtWfPCdrNkT7HS90hq7Qkk5biz7bM=; b=QQSjN2u6i4xaoqlTwxOgJzEoxbmg/99TIBP5YwYbrfilkLB/j0Xtb6mmk85NGieBLt mvQZ7brxZiA0LHlVBYj9fjt7ZR74BNrBMxBGC8chm3LTLK3eB0DVVMA28gA9Ex8sfcv2 A2yrsaYkUS+AUi7G0z4MVbNsl46GDF6WZ0hwkbMVfgAD/kzItKM1PIwYdDePDlY/zuUS dryejfQ+QbdzTx/Vr8067su3W0CbmbZrjsYdZCNLVjShyfbBh5Eh9sRDHyXen4NEcT8t abNW0o+7BlG/wD7GrrXs7IRwmFVytO5ZYHtUQTQi6MGvzAkfF9+QZfkKCFQKquf0rGXN zP2g== MIME-Version: 1.0 Received: by 10.68.129.131 with SMTP id nw3mr45314162pbb.43.1345566882982; Tue, 21 Aug 2012 09:34:42 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.43.169 with HTTP; Tue, 21 Aug 2012 09:34:42 -0700 (PDT) In-Reply-To: <420BA06C-C776-47DB-B3BB-F1414C115F99@bsdimp.com> References: <50324DB4.6080905@cabletv.dp.ua> <5452BF37-3658-4C1F-B965-CE3EA28B6EA5@bsdimp.com> <420BA06C-C776-47DB-B3BB-F1414C115F99@bsdimp.com> Date: Tue, 21 Aug 2012 09:34:42 -0700 X-Google-Sender-Auth: YEx0_ajkug3Y5gCsY8HfBAF0JqU Message-ID: From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: Wojciech Puchar , freebsd-net@freebsd.org, Mitya , freebsd-hackers@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Aug 2012 16:34:43 -0000 Hi, What about just creating an ETHER_ADDR_COPY(dst, src) and putting that in a relevant include file, then hide the ugliness there? The same benefits will likely appear when copying wifi MAC addresses to/from headers. Thanks, I'm glad someone noticed this. Adrian From owner-freebsd-net@FreeBSD.ORG Tue Aug 21 21:26:02 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 03C01106566B; Tue, 21 Aug 2012 21:26:02 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from mx1.giulioferro.ch (mx1.giulioferro.ch [217.150.252.208]) by mx1.freebsd.org (Postfix) with ESMTP id A37E08FC0A; Tue, 21 Aug 2012 21:26:01 +0000 (UTC) Received: from mailscan.giulioferro.ch (unknown [192.168.115.2]) by mx1.giulioferro.ch (Postfix) with ESMTP id 54E677275F; Tue, 21 Aug 2012 23:18:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at example.com Received: from mx1.giulioferro.ch ([192.168.114.4]) by mailscan.giulioferro.ch (mailscan.giulioferro.ch [192.168.115.2]) (amavisd-new, port 10024) with ESMTP id hJaUIQEpCN1N; Tue, 21 Aug 2012 23:18:16 +0200 (CEST) Received: from mail.zirakzigil.org (net-93-70-48-129.cust.dsl.vodafone.it [93.70.48.129]) by mx1.giulioferro.ch (Postfix) with ESMTP id 9540772755; Tue, 21 Aug 2012 23:18:16 +0200 (CEST) Received: from ext.zirakzigil.org (unknown [192.168.1.2]) by mail.zirakzigil.org (Postfix) with ESMTP id A44BC19BA6C; Tue, 21 Aug 2012 23:14:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at zirakzigil.org Received: from mail.zirakzigil.org ([192.168.1.2]) by ext.zirakzigil.org (ext.zirakzigil.org [192.168.1.2]) (amavisd-new, port 10024) with ESMTP id KrGAokyX3FBc; Tue, 21 Aug 2012 23:14:05 +0200 (CEST) Received: from [192.168.231.11] (ext [192.168.1.2]) (Authenticated sender: auryn@zirakzigil.org) by mail.zirakzigil.org (Postfix) with ESMTPA id 06B5419BA66; Tue, 21 Aug 2012 23:14:04 +0200 (CEST) Message-ID: <5033FB17.7020600@zirakzigil.org> Date: Tue, 21 Aug 2012 23:18:15 +0200 From: Giulio Ferro User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" , freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Problem with link aggregation + sshd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Aug 2012 21:26:02 -0000 Scenario : freebsd 9 stable (yesterday) amd64 on HP server with 4 nic (igb) 1 nic is connected standalone to the management switch, the 3 other nics are connected to a switch configured for aggregation. If I configure the first nic (igb0) there is no problem, I can operate as I normally do and sshd functions normally. The problems start when I configure the 3 other nics for aggregation: in /etc/rc.conf ... ifconfig_igb1="up" ifconfig_igb2="up" ifconfig_igb3="up" cloned_interfaces=lagg0 ifconfig_lagg0="laggproto lacp laggport igb1 laggport igb2 laggport igb3 192.168.12.7/24" ... I restart the server and the aggregation seems to work correctly, in fact ifconfig returns the correct lagg0 interface with the aggregated links, the correct protocol (lacp) and the correct ip address and the status is active. I can ping other IPs on the aggregated link. Also the other (standalone) link seems to work correctly. I can ping that address from other machines, and I can ping other IPs from that server. DNS lookups work ok too I can also use telnet to connect to pop3 servers so there seems to be no problem on the network stack. But if I try to connect to the sshd service on that server, it hangs indefinitely. On the server I find two sshd processes: /usr/sbin/sshd /usr/sbin/sshd -R There is no message in the logs. If I try to kill sshd (/etc/rc.d/sshd stop) I can't. it just stays there forever waiting for the pid to die (it never does) Even ssh client doesn't seem to work. In fact, if I try to connect to another server, the ssh client may start to work correctly, then soon or later it just hangs there forever, and I can't kill it with ctrl-c. No firewall is configured, there is nothing else working on this server. Thanks for any suggestions... From owner-freebsd-net@FreeBSD.ORG Tue Aug 21 23:02:32 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4ABEF1065670; Tue, 21 Aug 2012 23:02:32 +0000 (UTC) (envelope-from nitroboost@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7C3328FC0A; Tue, 21 Aug 2012 23:02:31 +0000 (UTC) Received: by eeke52 with SMTP id e52so125177eek.13 for ; Tue, 21 Aug 2012 16:02:30 -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=F9LtYPf+l75JYxwfAYhRGSY3yXIPw2ogeKaHr4Ftum8=; b=wsYUjxSI1/fcxcLA9QPct4lm0t01/cNvsl7jl+gZFDQ8g+56d7FVJrAmfUY/hgi84m vuL+wpEoumveln0kT906bxQ1ov+CDvmOdFrIlqVb6ruTLNqhfOhOywA1iw/fdd17fdE/ HxP3AvNWRorKRb+45gdSmKNKiGZlpqydSCcoBDZ5/T1t4cSK+a8/BHuv31MwKSkvoTM1 oDc4NDW3Hig6LI8bVr1EbfzyhwoT7msVX6NO5S8zuSxsjG26ccxOv83g7JJqsQ4G62YY GKBVg6codxNOcQnP1fD/atZAwMWlAtT1WQI0uzGkhGZRO34dO2RVwPQFOqbyiJoxd+Ek UKsw== MIME-Version: 1.0 Received: by 10.14.203.70 with SMTP id e46mr15944544eeo.2.1345590150636; Tue, 21 Aug 2012 16:02:30 -0700 (PDT) Received: by 10.14.183.132 with HTTP; Tue, 21 Aug 2012 16:02:30 -0700 (PDT) In-Reply-To: <1345213426.53058.YahooMailClassic@web121603.mail.ne1.yahoo.com> References: <1345213426.53058.YahooMailClassic@web121603.mail.ne1.yahoo.com> Date: Tue, 21 Aug 2012 16:02:30 -0700 Message-ID: From: Jason Wolfe To: Barney Cordoba Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , jfv@freebsd.org, Jack Vogel , John Baldwin , net@freebsd.org Subject: Re: 82574L hangs (with r233708 e1000 driver). X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Aug 2012 23:02:32 -0000 On Fri, Aug 17, 2012 at 7:23 AM, Barney Cordoba wrote: > > --- On Thu, 8/9/12, Jason Wolfe wrote: >> >> Ever since r235553 the 82574L has been stable for me, >> collectively >> passing ~1.2Tb/s for the past 4 months without issue. >> We did have >> some issues with switches not liking the fallout of what >> r236162 fixed >> that we updated to, but the cards themselves were >> fine. If you pull >> the current e1000 from 8-STABLE you'll get up to r236162. >> >> Jason > > Do you get occasional watchdog reset messages? I'm trying to see if > the buffer jumping problem has been fixed or if they just put a condition > watch in to keep it from remaining hung. > > Is Jack confident that something substantive has been corrected? If so, > what was the culprit? I have to patch it into a 7.x driver. > > Barney Barney, I've not seen any watchdog errors, and they have been performing pretty flawlessly even with the NIC pegged. I believe r235553 was the revision that fixed most of the issues on my end. Jason From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 02:07:54 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8BE0106564A; Wed, 22 Aug 2012 02:07:54 +0000 (UTC) (envelope-from bde@FreeBSD.org) Received: from ref10-i386.freebsd.org (unknown [IPv6:2001:4f8:fff6::5e]) by mx1.freebsd.org (Postfix) with ESMTP id A1A468FC15; Wed, 22 Aug 2012 02:07:54 +0000 (UTC) Received: from ref10-i386.freebsd.org (localhost [127.0.0.1]) by ref10-i386.freebsd.org (8.14.5/8.14.5) with ESMTP id q7M27svc020139; Wed, 22 Aug 2012 02:07:54 GMT (envelope-from bde@ref10-i386.freebsd.org) Received: (from bde@localhost) by ref10-i386.freebsd.org (8.14.5/8.14.5/Submit) id q7M27r3A020138; Wed, 22 Aug 2012 02:07:53 GMT (envelope-from bde) Date: Wed, 22 Aug 2012 02:07:53 GMT From: Bruce Evans Message-Id: <201208220207.q7M27r3A020138@ref10-i386.freebsd.org> To: marius@alchemy.franken.de, mitya@cabletv.dp.ua In-Reply-To: <20120821102630.GA89551@alchemy.franken.de> Cc: freebsd-hackers@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2012 02:07:54 -0000 > On Mon, Aug 20, 2012 at 05:46:12PM +0300, Mitya wrote: > > Hi. > > I found some overhead code in /src/sys/net/if_ethersubr.c and > > /src/sys/netgraph/ng_ether.c > > > > It contains strings, like bcopy(src, dst, ETHER_ADDR_LEN); > > When src and dst are "struct ether_addr*", and ETHER_ADDR_LEN equal 6. Only ng_ether.c contains such strings. if_ethersubr.c doesn't exist. if_ether.c exists, but was converted to use memcpy() 17.25 years ago. > > This code call every time, when we send Ethernet packet. > > On example, on my machine in invoked nearly 20K per second. > > > > Why we are use bcopy(), to copy only 6 bytes? > > Answer - in some architectures we are can not directly copy unaligned data. > > > > I propose this solution. > > > > In file /usr/src/include/net/ethernet.h add this lines: > > > > static inline void ether_addr_copy(ether_addr* src, ether_addr* dst) { > > #if defined(__i386__) || defined(__amd64__) > > *dst = *src; > > #else > > bcopy(src, dst, ETHER_ADDR_LEN); > > #endif > > } > > > > On platform i386 gcc produce like this code: > > leal -30(%ebp), %eax > > leal 6(%eax), %ecx > > leal -44(%ebp), %edx > > movl (%edx), %eax > > movl %eax, (%ecx) > > movzwl 4(%edx), %eax > > movw %ax, 4(%ecx) > > And clang produce this: > > movl -48(%ebp), %ecx > > movl %ecx, -26(%ebp) > > movw -44(%ebp), %si > > movw %si, -22(%ebp) > > > > All this variants are much faster, than bcopy() You mean "as much as 5 nanoseconds faster". Possibly even 10 nanoseconds faster. > A bit orthogonal to this but also related to the performance > impact of these bcopy() calls, for !__NO_STRICT_ALIGNMENT > architectures these places probably should use memcpy() > instead as bcopy() additionally has to check for overlap > while the former does not. Overlaps unlikely are an issue > in these cases and at least NetBSD apparently has done the > switch to memcpy() 5.5 years ago. This is essentially just a style bug. FreeBSD switched to memcpy() 17.25 years ago for selected networking copying. memcpy() is supposed to be used if and only if compilers can optimize it. This means that the size must be fixed and small, and of course that the copies don't overlap. Otherwise, compilers can't do any better than call an extern copying routine, which is memcpy() in practice. memcpy() was interntionally left out in FreeBSD until it was added 17.25 years ago to satisfy the changes to use memcpy() in networking code (since with -O0, memcpy() won't be inlined and the extern memcpy() gets used). Other uses are style bugs, but there are many now :-(. bcopy() is still the primary interface, and might be faster than memcpy(), especially for misaligned cases, but in practice it isn't, except in the kernel on Pentium1 in 1996-1998 where I only optimized (large) bcopy()s. Since it has to support overlapping copies it is inherently slower. Although compilers can't do better for large copying than call an extern routine, some compilers bogusly inline it to something like "rep movsd" on i386, (or worse, to a very large number of loads and stores). gcc used to have a very large threshold for inlining moderately-sized copies and/or for switching between "rep movsd" and load/store. It now understands better than ut doesn't understand memory, and has more reasonable thresholds. Or rather the thresholds are more MD. gcc still makes a mess with some CFLAGS: % struct foo % { % short x; % struct bar { % short yy[31]; % } y; % } s, t; % % foo() % { % s.y = t.y; % } With just -O, gcc-4.2.1 -O on i386 handles this very badly, by generating 15 misaligned 32-bit load/stores followed by 1 aligned 16-bit load/store. With -march=, it generates 1 16-bit aligned load-store followed by an aligned "rep movsd" with a count of 15. The latter is not too bad. Similarly for yy[32]. But for yy[33] it switches to a call to memcpy() even with plain -O. However, improvements in memory systems and branch prediction since Pentium1 in 1996-98 mean that optimimizing copying mostly gets nowhere. Copying is either from the cache[s], in which case it is fast (~1 nanosecond per 128 bits for L1), or it is not from the caches in which case it is slow (~50-200 nanseconds per cache miss). With 6-byte ethernet addresses, using bcopy() does slow the copying to considerably below 1 nanosecond per 128 bits (a sloppy estimate gives 5-10 ns/call), but it's hard for a single call to be made often enough to make a significant difference. Someone mentioned 20000 calls. That's the same as 0 calls: 20000 * 10 nsec = 200 usec = 0.05% of 1 CPU. If anyone cared about this, then they would use __builtin_memcpy() instead of memcpy(). (Note that the point of the 17.25-year old optimization has been defeated for ~10 years by turning off _all_ builtins, which was initially done mainly to kill builtin putc(). (-ffreestanding should have done that.) So gcc inlines struct copying for small structs, but never inlines memcpy(), or strlen(), or other unimportant things.) I once used the following to partially fix this, but stopped using it because it made no observable difference: % diff -c2 ./sys/systm.h~ ./sys/systm.h % *** ./sys/systm.h~ Sat Oct 13 12:43:54 2007 % --- ./sys/systm.h Sat Oct 13 12:43:56 2007 % *************** % *** 188,193 **** % --- 188,204 ---- % void bcopy(const void *from, void *to, size_t len) __nonnull(1) __nonnull(2); % void bzero(void *buf, size_t len) __nonnull(1); % + #if 1 % + #define bzero(p, n) ({ \ % + if (__builtin_constant_p(n) && (n) <= 64) \ % + __builtin_memset((p), 0, (n)); \ % + else \ % + (bzero)((p), (n)); \ % + }) % + #endif % % void *memcpy(void *to, const void *from, size_t len) __nonnull(1) __nonnull(2); % + #if 1 % + #define memcpy(to, from, n) __builtin_memcpy((to), (from), (n)) % + #endif % % int copystr(const void * __restrict kfaddr, void * __restrict kdaddr, In another set of dead patches, I changed lots of memcpy()s in networking code to __builtin_memcpy()'s. There is another set of style bugs and micro-pessimizations involving other mem* functions starting with bzero(). The above avoids the micro-pessimizations for the usual case of memset() to 0, at a cost of rewarding the style bug. Summary: use builtin memcpy() for small copies, and don't try hard to otherwise optimize this. Bruce From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 02:32:21 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC9871065672; Wed, 22 Aug 2012 02:32:21 +0000 (UTC) (envelope-from bde@FreeBSD.org) Received: from ref10-i386.freebsd.org (unknown [IPv6:2001:4f8:fff6::5e]) by mx1.freebsd.org (Postfix) with ESMTP id C7E948FC0A; Wed, 22 Aug 2012 02:32:21 +0000 (UTC) Received: from ref10-i386.freebsd.org (localhost [127.0.0.1]) by ref10-i386.freebsd.org (8.14.5/8.14.5) with ESMTP id q7M2WLmY020205; Wed, 22 Aug 2012 02:32:21 GMT (envelope-from bde@ref10-i386.freebsd.org) Received: (from bde@localhost) by ref10-i386.freebsd.org (8.14.5/8.14.5/Submit) id q7M2WLCL020204; Wed, 22 Aug 2012 02:32:21 GMT (envelope-from bde) Date: Wed, 22 Aug 2012 02:32:21 GMT From: Bruce Evans Message-Id: <201208220232.q7M2WLCL020204@ref10-i386.freebsd.org> To: marius@alchemy.franken.de, rizzo@iet.unipi.it In-Reply-To: <20120821112415.GA50078@onelab2.iet.unipi.it> Cc: freebsd-hackers@FreeBSD.org, mitya@cabletv.dp.ua, freebsd-net@FreeBSD.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2012 02:32:22 -0000 luigi wrote: > even more orthogonal: > > I found that copying 8n + (5, 6 or 7) bytes was much much slower than > copying a multiple of 8 bytes. For n=0, 1,2,4,8 bytes are efficient, > other cases are slow (turned into 2 or 3 different writes). > > The netmap code uses a pkt_copy routine that does exactly this > rounding, gaining some 10-20ns per packet for small sizes. I don't believe 10-20ns for just the extra bytes. memcpy() ends up with a movsb to copy the extra bytes. This can be slow, but I don't believe 10-20ns (except on machines running at i486 speeds of course). % ENTRY(memcpy) % pushl %edi % pushl %esi % movl 12(%esp),%edi % movl 16(%esp),%esi % movl 20(%esp),%ecx % movl %edi,%eax % shrl $2,%ecx /* copy by 32-bit words */ % cld /* nope, copy forwards */ % rep % movsl % movl 20(%esp),%ecx % andl $3,%ecx /* any bytes left? */ This avoids a branch. Some optimization manuals say that the branch is actually better for some machines, The above 2 instructions have a throughput of 1 per cycle each on modern x86. Latency might be 6 cycles. % rep Maybe 5-15 cycles throughput. % movsb Now hopefully at most 1 cycle/byte. Some hardware might combine the bytes as much as possible, so the whole function should use 1 single "rep movsb" and let the hardware do it all. % popl %esi % popl %edi % ret Well, it's easy to get a latency of 20 cycles 5-10 ns) and maybe even a throughput of that. But all of thus is out of order on modern x86. The extra cycles for the movsb might not cost at all if nothing accesses the part of the target that they were written to soon. With builtin memcpy, 6 bytes would be done using load/store of 4+2 bytes and thus take the same time as 8 bytes on i386, but on amd64 8 bytes would be faster. Bruce From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 02:55:55 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 05D571065674; Wed, 22 Aug 2012 02:55:55 +0000 (UTC) (envelope-from bde@FreeBSD.org) Received: from ref10-i386.freebsd.org (unknown [IPv6:2001:4f8:fff6::5e]) by mx1.freebsd.org (Postfix) with ESMTP id 9879C8FC0C; Wed, 22 Aug 2012 02:55:54 +0000 (UTC) Received: from ref10-i386.freebsd.org (localhost [127.0.0.1]) by ref10-i386.freebsd.org (8.14.5/8.14.5) with ESMTP id q7M2tsAZ020281; Wed, 22 Aug 2012 02:55:54 GMT (envelope-from bde@ref10-i386.freebsd.org) Received: (from bde@localhost) by ref10-i386.freebsd.org (8.14.5/8.14.5/Submit) id q7M2tsxa020280; Wed, 22 Aug 2012 02:55:54 GMT (envelope-from bde) Date: Wed, 22 Aug 2012 02:55:54 GMT From: Bruce Evans Message-Id: <201208220255.q7M2tsxa020280@ref10-i386.freebsd.org> To: freebsd-hackers@FreeBSD.org, jhb@FreeBSD.org In-Reply-To: <201208210943.08341.jhb@freebsd.org> Cc: freebsd-net@FreeBSD.org, mitya@cabletv.dp.ua Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2012 02:55:55 -0000 jhb wrote: > On Monday, August 20, 2012 10:46:12 am Mitya wrote: > > ... > > I propose this solution. > > > > In file /usr/src/include/net/ethernet.h add this lines: > > > > static inline void ether_addr_copy(ether_addr* src, ether_addr* dst) { > > #if defined(__i386__) || defined(__amd64__) > > *dst = *src; > > #else > > bcopy(src, dst, ETHER_ADDR_LEN); > > #endif > > } > > Doesn't '*dst = *src' just work on all platforms? It does when you have an actual struct, but often in networking code you only have an array of bytes, and then casting the pointers from uint8_t * to full object pointers fails iff there is an alignment problem. Even on i386, it may be pessimal to use struct copying for 6 bytes, The bytes should be copied as 4+2 or 2+4 depending on alignment of the first bytes. Oops, not even that -- this reminds me of a problem with penalties for mismatched loads and stores which affects at least AthlonXP and Athlon64 significantly (10-20 cycle penalty = enough to copy 80-160 bytes unpenalized). The 6 should probably be copied as 2+2+2 or even as 1+1+1+1+1+1 to match previous stores and later loads, also as 2+2+2, etc. But if the 6 are part of another struct, they might be accessed as 8+0 or 4+4 as part of copying the full struct. gcc is not smart about this. Bruce From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 04:02:10 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52E43106564A for ; Wed, 22 Aug 2012 04:02:10 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id B17088FC0A for ; Wed, 22 Aug 2012 04:02:08 +0000 (UTC) Received: from server.rulingia.com (c220-239-249-137.belrs5.nsw.optusnet.com.au [220.239.249.137]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q7M4265G085999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 22 Aug 2012 14:02:06 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q7M421bn097997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Aug 2012 14:02:01 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q7M421Od097996 for freebsd-net@freebsd.org; Wed, 22 Aug 2012 14:02:01 +1000 (EST) (envelope-from peter) Date: Wed, 22 Aug 2012 14:02:01 +1000 From: Peter Jeremy To: freebsd-net@freebsd.org Message-ID: <20120822040201.GA96087@server.rulingia.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Incorrect ARP table entries X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2012 04:02:10 -0000 --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I've run into a problem where the ARP table on several of my hosts is apparently spontaneously replacing correct entries with incorrect MAC addresses. I've done some digging with tcpdump and can't identify the cause. I've tried to look in the code but lost my way since ARP and IP routing seem to be closely intermingled. I'm hoping someone might be able to shed some light on why it is behaving the way it is. A rough diagram of the relevant part of the network is: +---------+ +---------+ | | [1] | | | local |============| | | | | | [3] +---------+ +----+----+ | |------------| | H [2] | switch | | remot | +----+----+ | |============| | | | | | [4] +---------+ | peer |============| | | | | | +---------+ +---------+ The hosts seeing the problem are running 8.2p2/amd64 ("local") and 8.3p3/i386 ("peer") using pf/carp for failover. The remote host ("remot") is a HP DL380 running FreeBSD (various between 7 and 10). My problem is that the entry for the DL380 iLO ([3], in vlan 157) is randomly having the correct MAC address replaced with the MAC address of the main interface ([4]). Note that the iLO is a physically separate NIC. '=' are all dual GigE links bonded using lagg/lacp with about 73 vlans inside them. [1] MAC "local-nic", IP addresses "local-157" in the iLO vlan (157) and "local-ip" in vlan 91. [2] cross-over cables joining dual FastE NICs bonded using lagg/lacp carrying pfsync traffic only. [3] DL380 iLO connected to a non-trunked switch port in vlan 157. MAC "remot-ilo", IP "remo-mgmt". [4] DL380 bge interfaces. MAC "remot-nic" and "remot-ip" in vlan 91. vlan 157 in configured at the switch end but not used at the host end (no interface in vlan 157 is created). Wheen I run: tcpdump -e -i lagg0 'ether host remot-nic or arp or (vlan and arp)' on "local", the only references to remot-nic or remot-ilo are (starting following an "arp -d remo-mgmt"): 12:15:41.481523 local-nic > broadcast, vlan 157, ARP, Request who-has remo-mgmt tell local-157 12:15:41.481853 remot-ilo > local-nic, vlan 157, ARP, Reply remo-mgmt is-at remot-ilo 12:15:43.337303 remot-nic > local-nic, vlan 91, IPv4, remot-ip.123 > local-ip.123: NTPv4 12:15:43.337854 local-nic > remot-nic, vlan 91, IPv4, local-ip.123 > remot-ip.123: NTPv4 12:16:46.338434 remot-nic > local-nic, vlan 91, IPv4, remot-ip.123 > local-ip.123: NTPv4 12:16:46.338968 local-nic > remot-nic, vlan 91, IPv4, local-ip.123 > remot-ip.123: NTPv4 12:17:50.338196 remot-nic > local-nic, vlan 91, IPv4, remot-ip.123 > local-ip.123: NTPv4 12:17:50.339027 local-nic > broadcast, vlan 91, ARP, Request who-has remot-ip tell local-ip 12:17:50.339253 remot-nic > local-nic, vlan 91, ARP, Reply remot-ip is-at remot-nic 12:17:50.339272 local-nic > remot-nic, vlan 91, IPv4, local-ip.123 > remot-ip.123: NTPv4 12:17:52.338532 remot-nic > broadcast, vlan 91, ARP, Request who-has other1 tell remot-ip 12:18:01.338517 remot-nic > broadcast, vlan 91, ARP, Request who-has other2 tell remot-ip 12:18:53.337620 remot-nic > local-nic, vlan 91, IPv4, remot-ip.123 > local-ip.123: NTPv4 12:18:53.338145 local-nic > remot-nic, vlan 91, IPv4, local-ip.123 > remot-ip.123: NTPv4 12:19:12.499330 remot-ilo > broadcast, vlan 157, ARP, Request who-has local-157 (local-nic) tell remo-mgmt 12:19:12.499353 local-nic > remot-nic, vlan 157, ARP, Reply local-157 is-at local-nic And I find in /var/log/messages: Aug 22 12:19:12 local kernel: arp: remo-mgmt moved from remot-ilo to remot-nic on vlan157 The ARP mapping for remo-mgmt to remot-ilo was correct following the ARP exchange at 12:15:41 but at 12:19:12, "local" responds to the wrong MAC address when replying to an ARP request. In the intervening period, there are no references to "remot-nic" in vlan 157 or any ARP requests mentioning remo-mgmt. -- Peter Jeremy --45Z9DzgjV8m4Oswq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlA0WbkACgkQ/opHv/APuIcuqgCgnUFkkH89vMxlIybM8qixCj/z PIQAmgNlp91qxcNPjtNKwRI78VwcEjNx =XseC -----END PGP SIGNATURE----- --45Z9DzgjV8m4Oswq-- From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 06:37:26 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B57E81065675; Wed, 22 Aug 2012 06:37:26 +0000 (UTC) (envelope-from mitya@cabletv.dp.ua) Received: from mail.cabletv.dp.ua (mail.cabletv.dp.ua [193.34.20.8]) by mx1.freebsd.org (Postfix) with ESMTP id 48F1B8FC12; Wed, 22 Aug 2012 06:37:26 +0000 (UTC) Received: from [193.34.20.2] (helo=m18.cabletv.dp.ua) by mail.cabletv.dp.ua with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1T452b-000HmX-W9; Wed, 22 Aug 2012 10:07:50 +0300 Message-ID: <50347CAB.30309@cabletv.dp.ua> Date: Wed, 22 Aug 2012 09:31:07 +0300 From: Mitya User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:12.0) Gecko/20120425 Thunderbird/12.0 MIME-Version: 1.0 To: Bruce Evans , freebsd-net@freebsd.org, freebsd-hackers@freebsd.org References: <201208220207.q7M27r3A020138@ref10-i386.freebsd.org> In-Reply-To: <201208220207.q7M27r3A020138@ref10-i386.freebsd.org> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2012 06:37:26 -0000 22.08.2012 05:07, Bruce Evans íàïèñàë: >> On Mon, Aug 20, 2012 at 05:46:12PM +0300, Mitya wrote: >>> Hi. >>> I found some overhead code in /src/sys/net/if_ethersubr.c and >>> /src/sys/netgraph/ng_ether.c >>> >>> It contains strings, like bcopy(src, dst, ETHER_ADDR_LEN); >>> When src and dst are "struct ether_addr*", and ETHER_ADDR_LEN equal 6. > Only ng_ether.c contains such strings. if_ethersubr.c doesn't exist. > if_ether.c exists, but was converted to use memcpy() 17.25 years ago. > >>> This code call every time, when we send Ethernet packet. >>> On example, on my machine in invoked nearly 20K per second. >>> >>> Why we are use bcopy(), to copy only 6 bytes? >>> Answer - in some architectures we are can not directly copy unaligned data. >>> >>> I propose this solution. >>> >>> In file /usr/src/include/net/ethernet.h add this lines: >>> >>> static inline void ether_addr_copy(ether_addr* src, ether_addr* dst) { >>> #if defined(__i386__) || defined(__amd64__) >>> *dst = *src; >>> #else >>> bcopy(src, dst, ETHER_ADDR_LEN); >>> #endif >>> } >>> >>> On platform i386 gcc produce like this code: >>> leal -30(%ebp), %eax >>> leal 6(%eax), %ecx >>> leal -44(%ebp), %edx >>> movl (%edx), %eax >>> movl %eax, (%ecx) >>> movzwl 4(%edx), %eax >>> movw %ax, 4(%ecx) >>> And clang produce this: >>> movl -48(%ebp), %ecx >>> movl %ecx, -26(%ebp) >>> movw -44(%ebp), %si >>> movw %si, -22(%ebp) >>> >>> All this variants are much faster, than bcopy() > You mean "as much as 5 nanoseconds faster". Possibly even 10 nanoseconds > faster. > >> A bit orthogonal to this but also related to the performance >> impact of these bcopy() calls, for !__NO_STRICT_ALIGNMENT >> architectures these places probably should use memcpy() >> instead as bcopy() additionally has to check for overlap >> while the former does not. Overlaps unlikely are an issue >> in these cases and at least NetBSD apparently has done the >> switch to memcpy() 5.5 years ago. > This is essentially just a style bug. FreeBSD switched to memcpy() > 17.25 years ago for selected networking copying. memcpy() is supposed > to be used if and only if compilers can optimize it. This means that > the size must be fixed and small, and of course that the copies don't > overlap. Otherwise, compilers can't do any better than call an extern > copying routine, which is memcpy() in practice. memcpy() was > interntionally left out in FreeBSD until it was added 17.25 years > ago to satisfy the changes to use memcpy() in networking code (since > with -O0, memcpy() won't be inlined and the extern memcpy() gets > used). Other uses are style bugs, but there are many now :-(. > > bcopy() is still the primary interface, and might be faster than > memcpy(), especially for misaligned cases, but in practice it isn't, > except in the kernel on Pentium1 in 1996-1998 where I only optimized > (large) bcopy()s. Since it has to support overlapping copies it is > inherently slower. > > Although compilers can't do better for large copying than call an > extern routine, some compilers bogusly inline it to something like > "rep movsd" on i386, (or worse, to a very large number of loads and > stores). gcc used to have a very large threshold for inlining > moderately-sized copies and/or for switching between "rep movsd" and > load/store. It now understands better than ut doesn't understand > memory, and has more reasonable thresholds. Or rather the thresholds > are more MD. gcc still makes a mess with some CFLAGS: > > % struct foo > % { > % short x; > % struct bar { > % short yy[31]; > % } y; > % } s, t; > % > % foo() > % { > % s.y = t.y; > % } > > With just -O, gcc-4.2.1 -O on i386 handles this very badly, by > generating 15 misaligned 32-bit load/stores followed by 1 aligned > 16-bit load/store. With -march=, it generates 1 > 16-bit aligned load-store followed by an aligned "rep movsd" with a > count of 15. The latter is not too bad. Similarly for yy[32]. But > for yy[33] it switches to a call to memcpy() even with plain -O. > > However, improvements in memory systems and branch prediction since > Pentium1 in 1996-98 mean that optimimizing copying mostly gets > nowhere. Copying is either from the cache[s], in which case it is > fast (~1 nanosecond per 128 bits for L1), or it is not from the > caches in which case it is slow (~50-200 nanseconds per cache miss). > With 6-byte ethernet addresses, using bcopy() does slow the copying > to considerably below 1 nanosecond per 128 bits (a sloppy estimate > gives 5-10 ns/call), but it's hard for a single call to be made often > enough to make a significant difference. Someone mentioned 20000 > calls. That's the same as 0 calls: 20000 * 10 nsec = 200 usec = > 0.05% of 1 CPU. > > If anyone cared about this, then they would use __builtin_memcpy() > instead of memcpy(). (Note that the point of the 17.25-year old > optimization has been defeated for ~10 years by turning off _all_ > builtins, which was initially done mainly to kill builtin putc(). > (-ffreestanding should have done that.) So gcc inlines struct > copying for small structs, but never inlines memcpy(), or strlen(), > or other unimportant things.) I once used the following to > partially fix this, but stopped using it because it made no > observable difference: > > % diff -c2 ./sys/systm.h~ ./sys/systm.h > % *** ./sys/systm.h~ Sat Oct 13 12:43:54 2007 > % --- ./sys/systm.h Sat Oct 13 12:43:56 2007 > % *************** > % *** 188,193 **** > % --- 188,204 ---- > % void bcopy(const void *from, void *to, size_t len) __nonnull(1) __nonnull(2); > % void bzero(void *buf, size_t len) __nonnull(1); > % + #if 1 > % + #define bzero(p, n) ({ \ > % + if (__builtin_constant_p(n)&& (n)<= 64) \ > % + __builtin_memset((p), 0, (n)); \ > % + else \ > % + (bzero)((p), (n)); \ > % + }) > % + #endif > % > % void *memcpy(void *to, const void *from, size_t len) __nonnull(1) __nonnull(2); > % + #if 1 > % + #define memcpy(to, from, n) __builtin_memcpy((to), (from), (n)) > % + #endif > % > % int copystr(const void * __restrict kfaddr, void * __restrict kdaddr, > > In another set of dead patches, I changed lots of memcpy()s in networking > code to __builtin_memcpy()'s. > > There is another set of style bugs and micro-pessimizations involving > other mem* functions starting with bzero(). The above avoids the > micro-pessimizations for the usual case of memset() to 0, at a cost > of rewarding the style bug. > > Summary: use builtin memcpy() for small copies, and don't try hard to > otherwise optimize this. You are very surprised to learn that bcopy() and memcpy() are used for copy "struct in_addr", whose length is equal to 4 bytes ? I found this in sys/netinet/if_ether.c. And I think, there is a chance to find them in other files. And I found bzero(mtod(m, void *), sizeof(struct in_addr)); in ip_options.c > Bruce From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 08:00:49 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 75BE0106564A; Wed, 22 Aug 2012 08:00:49 +0000 (UTC) (envelope-from bde@FreeBSD.org) Received: from ref10-i386.freebsd.org (unknown [IPv6:2001:4f8:fff6::5e]) by mx1.freebsd.org (Postfix) with ESMTP id 5FE388FC08; Wed, 22 Aug 2012 08:00:49 +0000 (UTC) Received: from ref10-i386.freebsd.org (localhost [127.0.0.1]) by ref10-i386.freebsd.org (8.14.5/8.14.5) with ESMTP id q7M80n3q021456; Wed, 22 Aug 2012 08:00:49 GMT (envelope-from bde@ref10-i386.freebsd.org) Received: (from bde@localhost) by ref10-i386.freebsd.org (8.14.5/8.14.5/Submit) id q7M80m08021455; Wed, 22 Aug 2012 08:00:48 GMT (envelope-from bde) Date: Wed, 22 Aug 2012 08:00:48 GMT From: Bruce Evans Message-Id: <201208220800.q7M80m08021455@ref10-i386.freebsd.org> To: bde@freebsd.org, freebsd-hackers@freebsd.org, freebsd-net@freebsd.org, mitya@cabletv.dp.ua In-Reply-To: <50347CAB.30309@cabletv.dp.ua> Cc: Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2012 08:00:49 -0000 mitya wrote: > 22.08.2012 05:07, Bruce Evans íàïèñàë: > >> On Mon, Aug 20, 2012 at 05:46:12PM +0300, Mitya wrote: > >>> Hi. > >>> I found some overhead code in /src/sys/net/if_ethersubr.c and > >>> /src/sys/netgraph/ng_ether.c > >>> > >>> It contains strings, like bcopy(src, dst, ETHER_ADDR_LEN); > >>> When src and dst are "struct ether_addr*", and ETHER_ADDR_LEN equal 6. > > Only ng_ether.c contains such strings. if_ethersubr.c doesn't exist. > > if_ether.c exists, but was converted to use memcpy() 17.25 years ago. Oops, if_ethersubr.c does exist (in net/. if_ether.c is a misnamed file in netinet/). > > Summary: use builtin memcpy() for small copies, and don't try hard to > > otherwise optimize this. > You are very surprised to learn that bcopy() and memcpy() are used for > copy "struct in_addr", whose length is equal to 4 bytes ? > I found this in sys/netinet/if_ether.c. And I think, there is a chance > to find them in other files. Since memcpy() is the correct method, us of it is only slightly surprising. Use of bcopy() is a regression. Bugs are never surprising :-). > And I found bzero(mtod(m, void *), sizeof(struct in_addr)); in ip_options.c Speed of options processing isn't important. Anyway, I dug out some of my old unimportant fixes for some of the copying pessimizations: % diff -c2 ./net/if_ethersubr.c~ ./net/if_ethersubr.c % *** ./net/if_ethersubr.c~ Wed Dec 27 10:49:51 2006 % --- ./net/if_ethersubr.c Wed Dec 27 10:49:52 2006 % *************** % *** 253,257 **** % hdrcmplt = 1; % eh = (struct ether_header *)dst->sa_data; % ! (void)memcpy(esrc, eh->ether_shost, sizeof (esrc)); % /* FALLTHROUGH */ % % --- 253,257 ---- % hdrcmplt = 1; % eh = (struct ether_header *)dst->sa_data; % ! __builtin_memcpy(esrc, eh->ether_shost, sizeof(esrc)); % /* FALLTHROUGH */ % Not the right fix (except to fix the style bug (cast to void)). memcpy() should be used, and then if the builtin is good then it shoukd be used. % *************** % *** 259,263 **** % loop_copy = 0; /* if this is for us, don't do it */ % eh = (struct ether_header *)dst->sa_data; % ! (void)memcpy(edst, eh->ether_dhost, sizeof (edst)); % type = eh->ether_type; % break; % --- 259,263 ---- % loop_copy = 0; /* if this is for us, don't do it */ % eh = (struct ether_header *)dst->sa_data; % ! __builtin_memcpy(edst, eh->ether_dhost, sizeof(edst)); % type = eh->ether_type; % break; % *************** % *** 276,288 **** % senderr(ENOBUFS); % eh = mtod(m, struct ether_header *); % ! (void)memcpy(&eh->ether_type, &type, % ! sizeof(eh->ether_type)); % ! (void)memcpy(eh->ether_dhost, edst, sizeof (edst)); % if (hdrcmplt) % ! (void)memcpy(eh->ether_shost, esrc, % ! sizeof(eh->ether_shost)); % else % ! (void)memcpy(eh->ether_shost, IF_LLADDR(ifp), % ! sizeof(eh->ether_shost)); % % /* % --- 276,287 ---- % senderr(ENOBUFS); % eh = mtod(m, struct ether_header *); % ! __builtin_memcpy(&eh->ether_type, &type, sizeof(eh->ether_type)); % ! __builtin_memcpy(eh->ether_dhost, edst, sizeof(edst)); % if (hdrcmplt) % ! __builtin_memcpy(eh->ether_shost, esrc, % ! sizeof(eh->ether_shost)); % else % ! __builtin_memcpy(eh->ether_shost, IF_LLADDR(ifp), % ! sizeof(eh->ether_shost)); % % /* Larger style fixes. Non-style fixes/breakages are in the z subdir: % diff -c2 ./net/z/if_ethersubr.c~ ./net/z/if_ethersubr.c % *** ./net/z/if_ethersubr.c~ Wed Dec 27 10:49:51 2006 % --- ./net/z/if_ethersubr.c Wed Dec 27 20:28:06 2006 % *************** % *** 191,197 **** % % if (m->m_flags & M_BCAST) % ! bcopy(ifp->if_broadcastaddr, edst, ETHER_ADDR_LEN); % else % ! bcopy(ar_tha(ah), edst, ETHER_ADDR_LEN); % % } % --- 191,198 ---- % % if (m->m_flags & M_BCAST) % ! __builtin_memcpy(edst, ifp->if_broadcastaddr, % ! sizeof(edst)); % else % ! __builtin_memcpy(edst, ar_tha(ah), sizeof(edst)); % % } bcopy() can't be replaced by a builtin since it is required to handle overlapping copies, which I think can't happen here (but I didn't check this). The builtin shouldn't be hard-coded like this, as above. % *************** % *** 214,219 **** % } else % type = htons(ETHERTYPE_IPX); % ! bcopy((caddr_t)&(((struct sockaddr_ipx *)dst)->sipx_addr.x_host), % ! (caddr_t)edst, sizeof (edst)); % break; % #endif % --- 215,221 ---- % } else % type = htons(ETHERTYPE_IPX); % ! __buitin_memcpy(edst, % ! &(((struct sockaddr_ipx *)dst)->sipx_addr.x_host), % ! sizeof(edst)); % break; % #endif As above, plus fix grosser style bugs (use of caddr_t. bcopy() hasn't take args of type caddr_t for more than 20 years). % *************** % *** 238,244 **** % llc.llc_dsap = llc.llc_ssap = LLC_SNAP_LSAP; % llc.llc_control = LLC_UI; % ! bcopy(at_org_code, llc.llc_snap_org_code, sizeof(at_org_code)); % llc.llc_snap_ether_type = htons( ETHERTYPE_AT ); % ! bcopy(&llc, mtod(m, caddr_t), LLC_SNAPFRAMELEN); % type = htons(m->m_pkthdr.len); % hlen = LLC_SNAPFRAMELEN + ETHER_HDR_LEN; % --- 240,247 ---- % llc.llc_dsap = llc.llc_ssap = LLC_SNAP_LSAP; % llc.llc_control = LLC_UI; % ! __builtin_memcpy(llc.llc_snap_org_code, at_org_code, % ! sizeof(at_org_code)); % llc.llc_snap_ether_type = htons( ETHERTYPE_AT ); % ! __builtin_memcpy(mtod(m, caddr_t), &llc, LLC_SNAPFRAMELEN); % type = htons(m->m_pkthdr.len); % hlen = LLC_SNAPFRAMELEN + ETHER_HDR_LEN; % *************** % *** 253,257 **** % hdrcmplt = 1; % eh = (struct ether_header *)dst->sa_data; % ! (void)memcpy(esrc, eh->ether_shost, sizeof (esrc)); % /* FALLTHROUGH */ % % --- 256,260 ---- % hdrcmplt = 1; % eh = (struct ether_header *)dst->sa_data; % ! __builtin_memcpy(esrc, eh->ether_shost, sizeof(esrc)); % /* FALLTHROUGH */ % % *************** % *** 259,263 **** % loop_copy = 0; /* if this is for us, don't do it */ % eh = (struct ether_header *)dst->sa_data; % ! (void)memcpy(edst, eh->ether_dhost, sizeof (edst)); % type = eh->ether_type; % break; % --- 262,266 ---- % loop_copy = 0; /* if this is for us, don't do it */ % eh = (struct ether_header *)dst->sa_data; % ! __builtin_memcpy(edst, eh->ether_dhost, sizeof(edst)); % type = eh->ether_type; % break; % *************** % *** 276,288 **** % senderr(ENOBUFS); % eh = mtod(m, struct ether_header *); % ! (void)memcpy(&eh->ether_type, &type, % ! sizeof(eh->ether_type)); % ! (void)memcpy(eh->ether_dhost, edst, sizeof (edst)); % if (hdrcmplt) % ! (void)memcpy(eh->ether_shost, esrc, % ! sizeof(eh->ether_shost)); % else % ! (void)memcpy(eh->ether_shost, IF_LLADDR(ifp), % ! sizeof(eh->ether_shost)); % % /* % --- 279,290 ---- % senderr(ENOBUFS); % eh = mtod(m, struct ether_header *); % ! __builtin_memcpy(&eh->ether_type, &type, sizeof(eh->ether_type)); % ! __builtin_memcpy(eh->ether_dhost, edst, sizeof(edst)); % if (hdrcmplt) % ! __builtin_memcpy(eh->ether_shost, esrc, % ! sizeof(eh->ether_shost)); % else % ! __builtin_memcpy(eh->ether_shost, IF_LLADDR(ifp), % ! sizeof(eh->ether_shost)); % % /* % *************** % *** 454,459 **** % } % if (eh != mtod(m, struct ether_header *)) % ! bcopy(&save_eh, mtod(m, struct ether_header *), % ! ETHER_HDR_LEN); % } % *m0 = m; % --- 456,461 ---- % } % if (eh != mtod(m, struct ether_header *)) % ! __builtin_memcpy(mtod(m, struct ether_header *), % ! &save_eh, sizeof(struct ether_header)); % } % *m0 = m; % *************** % *** 1028,1034 **** % IF_LLADDR(ifp); % else { % ! bcopy((caddr_t) ina->x_host.c_host, % ! (caddr_t) IF_LLADDR(ifp), % ! ETHER_ADDR_LEN); % } % % --- 1030,1035 ---- % IF_LLADDR(ifp); % else { % ! __builtin_memcpy(IF_LLADDR(ifp), % ! ina->x_host.c_host, ETHER_ADDR_LEN); % } % % *************** % *** 1050,1056 **** % struct sockaddr *sa; % % ! sa = (struct sockaddr *) & ifr->ifr_data; % ! bcopy(IF_LLADDR(ifp), % ! (caddr_t) sa->sa_data, ETHER_ADDR_LEN); % } % break; % --- 1051,1057 ---- % struct sockaddr *sa; % % ! sa = (struct sockaddr *)&ifr->ifr_data; % ! __builtin_memcpy(sa->sa_data, IF_LLADDR(ifp), % ! ETHER_ADDR_LEN); % } % break; % *************** % *** 1208,1212 **** % KASSERT(m->m_len >= sizeof(struct ether_header), % ("%s: mbuf not large enough for header", __func__)); % ! bcopy(mtod(m, char *), &vlan, sizeof(struct ether_header)); % vlan.evl_proto = vlan.evl_encap_proto; % vlan.evl_encap_proto = htons(ETHERTYPE_VLAN); % --- 1209,1213 ---- % KASSERT(m->m_len >= sizeof(struct ether_header), % ("%s: mbuf not large enough for header", __func__)); % ! __builtin_memcpy(&vlan, mtod(m, char *), sizeof(&vlan)); % vlan.evl_proto = vlan.evl_encap_proto; % vlan.evl_encap_proto = htons(ETHERTYPE_VLAN); This is supposed to fix all the bcopy()'s and (mis)rename all the memcpy()'s use by a UDP throughput benchmark, and any nearby that were easy to change. Bruce From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 12:46:18 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8F20B106566C; Wed, 22 Aug 2012 12:46:18 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5F9DF8FC15; Wed, 22 Aug 2012 12:46:18 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 683ADB95D; Wed, 22 Aug 2012 08:46:17 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 22 Aug 2012 08:02:14 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <50324DB4.6080905@cabletv.dp.ua> <420BA06C-C776-47DB-B3BB-F1414C115F99@bsdimp.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201208220802.14588.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 22 Aug 2012 08:46:17 -0400 (EDT) Cc: Wojciech Puchar , Adrian Chadd , Mitya , Warner Losh , freebsd-net@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2012 12:46:18 -0000 On Tuesday, August 21, 2012 12:34:42 pm Adrian Chadd wrote: > Hi, > > What about just creating an ETHER_ADDR_COPY(dst, src) and putting that > in a relevant include file, then hide the ugliness there? > > The same benefits will likely appear when copying wifi MAC addresses > to/from headers. > > Thanks, I'm glad someone noticed this. I doubt we even _need_ the ugliness. We should just use *dst = *src unless there is a compelling reason not to. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 13:26:41 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 786EB1065672 for ; Wed, 22 Aug 2012 13:26:41 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 414EE8FC1D for ; Wed, 22 Aug 2012 13:26:41 +0000 (UTC) Received: by dadr6 with SMTP id r6so785847dad.13 for ; Wed, 22 Aug 2012 06:26:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=cNzWHgU9ZibzOlCTJUGq2Bl4M+lRChyXB/vpy0ofcTg=; b=erqSESqYQbVHEVBEsg54VYsVtxSMf56wO8A3yq/Q7XhDZLZXHyA8VWSlLWxvDQ3ZV+ zirfMPTz03wKX0DJ/BsH3v1kGUiB0Q9EJLoLb45g1N5RRl5F3hk9kTwa3QyRADqaw333 YGjpKwJNSh8jncGXc5in6ZJnjPFGxDOQMdOxoJ+uVZffmO77FPz4gCIyPZ+OkFn4q/og ++2w9CVUIjVIJmdoVqycCXsqUUrlBF5fRNL/J8HMBsLv9C9bLL0vePNViGjbcNFSG7gz bkaaJVVVcy1NzMJZyKhZ7dpVWp2q43aUwJNj4ryL7jnmSkX8ix7/qTmLWYDlNRgAhwzS iZ+g== Received: by 10.66.86.166 with SMTP id q6mr45967443paz.83.1345642000454; Wed, 22 Aug 2012 06:26:40 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id hx9sm3710761pbc.68.2012.08.22.06.26.36 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Aug 2012 06:26:37 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <201208220802.14588.jhb@freebsd.org> Date: Wed, 22 Aug 2012 07:26:34 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2DB48390-4FB8-49ED-A176-CF593ED57502@bsdimp.com> References: <50324DB4.6080905@cabletv.dp.ua> <420BA06C-C776-47DB-B3BB-F1414C115F99@bsdimp.com> <201208220802.14588.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmSYwZ91Cu9zWtGQDUXrrUqXPVJAH7tHYDmZ0UmPmT+QL0EA3D0vVX4Qa9Mmszgp6fdeUAK Cc: freebsd-hackers@freebsd.org, Adrian Chadd , freebsd-net@freebsd.org, Mitya , Wojciech Puchar Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2012 13:26:41 -0000 On Aug 22, 2012, at 6:02 AM, John Baldwin wrote: > On Tuesday, August 21, 2012 12:34:42 pm Adrian Chadd wrote: >> Hi, >>=20 >> What about just creating an ETHER_ADDR_COPY(dst, src) and putting = that >> in a relevant include file, then hide the ugliness there? >>=20 >> The same benefits will likely appear when copying wifi MAC addresses >> to/from headers. >>=20 >> Thanks, I'm glad someone noticed this. >=20 > I doubt we even _need_ the ugliness. We should just use *dst =3D *src > unless there is a compelling reason not to. Agreed. We should do that, and then check the generated code to be sure = there isn't a compelling reason there :) Warner From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 14:17:26 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8BFA31065676; Wed, 22 Aug 2012 14:17:26 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id B2CD68FC17; Wed, 22 Aug 2012 14:17:25 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 5D42E7300A; Wed, 22 Aug 2012 16:36:32 +0200 (CEST) Date: Wed, 22 Aug 2012 16:36:32 +0200 From: Luigi Rizzo To: Bruce Evans Message-ID: <20120822143632.GA64686@onelab2.iet.unipi.it> References: <20120821112415.GA50078@onelab2.iet.unipi.it> <201208220232.q7M2WLCL020204@ref10-i386.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201208220232.q7M2WLCL020204@ref10-i386.freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@FreeBSD.org, freebsd-net@FreeBSD.org, mitya@cabletv.dp.ua, marius@alchemy.franken.de Subject: speed tests (Re: Replace bcopy() to update ether_addr) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2012 14:17:26 -0000 On Wed, Aug 22, 2012 at 02:32:21AM +0000, Bruce Evans wrote: > luigi wrote: > > > even more orthogonal: > > > > I found that copying 8n + (5, 6 or 7) bytes was much much slower than > > copying a multiple of 8 bytes. For n=0, 1,2,4,8 bytes are efficient, > > other cases are slow (turned into 2 or 3 different writes). > > > > The netmap code uses a pkt_copy routine that does exactly this > > rounding, gaining some 10-20ns per packet for small sizes. > > I don't believe 10-20ns for just the extra bytes. memcpy() ends up > with a movsb to copy the extra bytes. This can be slow, but I don't > believe 10-20ns (except on machines running at i486 speeds of course). I am adding at the end a test program so people can try things on their hw. Build it with cc -O2 -Werror -Wall -Wextra -lpthread -lrt testlock.c -o testlock and on my i7 i get these results: ./testlock -m memcpy -l 7 -> ~23 Mops/s 43 ns/cycle ./testlock -m bcopy -l 7 -> ~10 Mops/sA 100 ns/cycle ./testlock -m fastcopy -l 7 -> ~64 Mops/s 16 ns/cycle (fastcopy rounds to the next multiple of 8) Changing the length (-l ...) changes the speed, of course. For some reason my machine is fast for 8n+(0,1,2,3) and slow for 8n+(4,5,6,7). cheers luigi -------------------- /* * Copyright (C) 2012 Luigi Rizzo. 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. */ /* * $Id: testlock.c 11731 2012-08-22 14:19:50Z luigi $ * * Test program to study various ops and concurrency issues. * Create multiple threads, possibly bind to cpus, and run a workload. * * cc -O2 -Werror -Wall testlock.c -o testlock -lpthread * you might need -lrt */ #include #include #include /* pthread_* */ #if defined(__APPLE__) #include #define atomic_add_int(p, n) OSAtomicAdd32(n, (int *)p) #define atomic_cmpset_32(p, o, n) OSAtomicCompareAndSwap32(o, n, (int *)p) #elif defined(linux) int atomic_cmpset_32(volatile uint32_t *p, uint32_t old, uint32_t new) { int ret = *p == old; *p = new; return ret; } #if defined(HAVE_GCC_ATOMICS) int atomic_add_int(volatile int *p, int v) { return __sync_fetch_and_add(p, v); } #else inline uint32_t atomic_add_int(uint32_t *p, int v) { __asm __volatile ( " lock xaddl %0, %1 ; " : "+r" (v), /* 0 (result) */ "=m" (*p) /* 1 */ : "m" (*p)); /* 2 */ return (v); } #endif #else /* FreeBSD */ #include #include #include /* pthread w/ affinity */ #if __FreeBSD_version > 500000 #include /* cpu_set */ #if __FreeBSD_version > 800000 #define HAVE_AFFINITY #endif inline void prefetch (const void *x) { __asm volatile("prefetcht0 %0" :: "m" (*(const unsigned long *)x)); } #else /* FreeBSD 4.x */ int atomic_cmpset_32(volatile uint32_t *p, uint32_t old, uint32_t new) { int ret = *p == old; *p = new; return ret; } #define PRIu64 "llu" #endif /* FreeBSD 4.x */ #endif /* FreeBSD */ #include /* signal */ #include #include #include #include /* PRI* macros */ #include /* strcmp */ #include /* open */ #include /* getopt */ #include /* sysctl */ #include /* timersub */ static inline int min(int a, int b) { return a < b ? a : b; } #define ONE_MILLION 1000000 /* debug support */ #define ND(format, ...) #define D(format, ...) \ fprintf(stderr, "%s [%d] " format "\n", \ __FUNCTION__, __LINE__, ##__VA_ARGS__) int verbose = 0; #if 1//def MY_RDTSC /* Wrapper around `rdtsc' to take reliable timestamps flushing the pipeline */ #define my_rdtsc(t) \ do { \ u_int __regs[4]; \ \ do_cpuid(0, __regs); \ (t) = rdtsc(); \ } while (0) static __inline void do_cpuid(u_int ax, u_int *p) { __asm __volatile("cpuid" : "=a" (p[0]), "=b" (p[1]), "=c" (p[2]), "=d" (p[3]) : "0" (ax) ); } static __inline uint64_t rdtsc(void) { uint64_t rv; // XXX does not work on linux-64 bit __asm __volatile("rdtscp" : "=A" (rv) : : "%rax"); return (rv); } #endif /* 1 */ struct targ; /*** global arguments for all threads ***/ struct glob_arg { struct { uint32_t ctr[1024]; } v __attribute__ ((aligned(256) )); int m_cycles; /* million cycles */ int nthreads; int cpus; int privs; // 1 if has IO privileges int arg; // microseconds in usleep char *test_name; void (*fn)(struct targ *); uint64_t scale; // scaling factor char *scale_name; // scaling factor }; /* * Arguments for a new thread. */ struct targ { struct glob_arg *g; int completed; u_int *glob_ctr; uint64_t volatile count; struct timeval tic, toc; int me; pthread_t thread; int affinity; }; static struct targ *ta; static int global_nthreads; /* control-C handler */ static void sigint_h(int sig) { int i; (void)sig; /* UNUSED */ for (i = 0; i < global_nthreads; i++) { /* cancel active threads. */ if (ta[i].completed) continue; D("Cancelling thread #%d\n", i); pthread_cancel(ta[i].thread); ta[i].completed = 0; } signal(SIGINT, SIG_DFL); } /* sysctl wrapper to return the number of active CPUs */ static int system_ncpus(void) { #ifdef linux return 1; #else int mib[2] = { CTL_HW, HW_NCPU}, ncpus; size_t len = sizeof(mib); sysctl(mib, len / sizeof(mib[0]), &ncpus, &len, NULL, 0); D("system had %d cpus", ncpus); return (ncpus); #endif } /* * try to get I/O privileges so we can execute cli/sti etc. */ int getprivs(void) { int fd = open("/dev/io", O_RDWR); if (fd < 0) { D("cannot open /dev/io, fd %d", fd); return 0; } return 1; } /* set the thread affinity. */ /* ARGSUSED */ #ifdef HAVE_AFFINITY static int setaffinity(pthread_t me, int i) { cpuset_t cpumask; if (i == -1) return 0; /* Set thread affinity affinity.*/ CPU_ZERO(&cpumask); CPU_SET(i, &cpumask); if (pthread_setaffinity_np(me, sizeof(cpuset_t), &cpumask) != 0) { D("Unable to set affinity"); return 1; } return 0; } #endif static void * td_body(void *data) { struct targ *t = (struct targ *) data; #ifdef HAVE_AFFINITY if (0 == setaffinity(t->thread, t->affinity)) #endif { /* main loop.*/ D("testing %d cycles", t->g->m_cycles); gettimeofday(&t->tic, NULL); t->g->fn(t); gettimeofday(&t->toc, NULL); } t->completed = 1; return (NULL); } void test_sel(struct targ *t) { int m; for (m = 0; m < t->g->m_cycles; m++) { fd_set r; struct timeval to = { 0, t->g->arg}; FD_ZERO(&r); FD_SET(0,&r); // FD_SET(1,&r); select(1, &r, NULL, NULL, &to); t->count++; } } void test_poll(struct targ *t) { int m, ms = t->g->arg/1000; for (m = 0; m < t->g->m_cycles; m++) { struct pollfd x; x.fd = 0; x.events = POLLIN; poll(&x, 1, ms); t->count++; } } void test_usleep(struct targ *t) { int m; for (m = 0; m < t->g->m_cycles; m++) { usleep(t->g->arg); t->count++; } } void test_cli(struct targ *t) { int m, i; if (!t->g->privs) { D("%s", "privileged instructions not available"); return; } for (m = 0; m < t->g->m_cycles; m++) { for (i = 0; i < ONE_MILLION; i++) { __asm __volatile("cli;"); __asm __volatile("and %eax, %eax;"); __asm __volatile("sti;"); t->count++; } } } void test_nop(struct targ *t) { int m, i; for (m = 0; m < t->g->m_cycles; m++) { for (i = 0; i < ONE_MILLION; i++) { __asm __volatile("nop;"); __asm __volatile("nop; nop; nop; nop; nop;"); //__asm __volatile("nop; nop; nop; nop; nop;"); t->count++; } } } void test_rdtsc1(struct targ *t) { int m, i; uint64_t v; (void)v; for (m = 0; m < t->g->m_cycles; m++) { for (i = 0; i < ONE_MILLION; i++) { my_rdtsc(v); t->count++; } } } void test_rdtsc(struct targ *t) { int m, i; volatile uint64_t v; (void)v; for (m = 0; m < t->g->m_cycles; m++) { for (i = 0; i < ONE_MILLION; i++) { v = rdtsc(); t->count++; } } } void test_add(struct targ *t) { int m, i; for (m = 0; m < t->g->m_cycles; m++) { for (i = 0; i < ONE_MILLION; i++) { t->glob_ctr[0] ++; t->count++; } } } void test_atomic_add(struct targ *t) { int m, i; for (m = 0; m < t->g->m_cycles; m++) { for (i = 0; i < ONE_MILLION; i++) { atomic_add_int(t->glob_ctr, 1); t->count++; } } } void test_atomic_cmpset(struct targ *t) { int m, i; for (m = 0; m < t->g->m_cycles; m++) { for (i = 0; i < ONE_MILLION; i++) { atomic_cmpset_32(t->glob_ctr, m, i); t->count++; } } } void test_time(struct targ *t) { int m; for (m = 0; m < t->g->m_cycles; m++) { #ifndef __APPLE__ struct timespec ts; clock_gettime(t->g->arg, &ts); #endif t->count++; } } void test_gettimeofday(struct targ *t) { int m; struct timeval ts; for (m = 0; m < t->g->m_cycles; m++) { gettimeofday(&ts, NULL); t->count++; } } #define likely(x) __builtin_expect(!!(x), 1) #define unlikely(x) __builtin_expect(!!(x), 0) static void fast_bcopy(void *_src, void *_dst, int l) { uint64_t *src = _src; uint64_t *dst = _dst; if (unlikely(l >= 1024)) { bcopy(src, dst, l); return; } for (; likely(l > 0); l-=64) { *dst++ = *src++; *dst++ = *src++; *dst++ = *src++; *dst++ = *src++; *dst++ = *src++; *dst++ = *src++; *dst++ = *src++; *dst++ = *src++; } } // XXX if you want to make sure there is no inlining... // static void (*fp)(void *_src, void *_dst, int l) = fast_bcopy; #define HU 0x3ffff static struct glob_arg huge[HU+1]; void test_fastcopy(struct targ *t) { int m, len; len = t->g->arg; if (len > (int)sizeof(struct glob_arg)) len = sizeof(struct glob_arg); D("fast copying %d bytes", len); for (m = 0; m < t->g->m_cycles; m++) { fast_bcopy(t->g, (void *)&huge[m & HU], len); t->count+=1; } } void test_bcopy(struct targ *t) { int m, len; len = t->g->arg; if (len > (int)sizeof(struct glob_arg)) len = sizeof(struct glob_arg); D("bcopying %d bytes", len); for (m = 0; m < t->g->m_cycles; m++) { __builtin_memcpy(t->g, (void *)&huge[m & HU], len); t->count+=1; } } void test_memcpy(struct targ *t) { int m, len; len = t->g->arg; if (len > (int)sizeof(struct glob_arg)) len = sizeof(struct glob_arg); D("memcopying %d bytes", len); for (m = 0; m < t->g->m_cycles; m++) { memcpy((void *)&huge[m & HU], t->g, len); t->count+=1; } } struct entry { void (*fn)(struct targ *); char *name; uint64_t scale; uint64_t m_cycles; }; struct entry tests[] = { { test_sel, "select", 1, 1000 }, { test_poll, "poll", 1, 1000 }, { test_usleep, "usleep", 1, 1000 }, { test_time, "time", 1, 1000 }, { test_gettimeofday, "gettimeofday", 1, 1000000 }, { test_bcopy, "bcopy", 1, 100000000 }, { test_memcpy, "memcpy", 1, 100000000 }, { test_fastcopy, "fastcopy", 1, 100000000 }, { test_add, "add", ONE_MILLION, 100000000 }, { test_nop, "nop", ONE_MILLION, 100000000 }, { test_atomic_add, "atomic-add", ONE_MILLION, 100000000 }, { test_cli, "cli", ONE_MILLION, 100000000 }, { test_rdtsc, "rdtsc", ONE_MILLION, 100000000 }, // unserialized { test_rdtsc1, "rdtsc1", ONE_MILLION, 100000000 }, // serialized { test_atomic_cmpset, "cmpset", ONE_MILLION, 100000000 }, { NULL, NULL, 0, 0 } }; static void usage(void) { const char *cmd = "test"; int i; fprintf(stderr, "Usage:\n" "%s arguments\n" "\t-m name test name\n" "\t-n cycles (millions) of cycles\n" "\t-l arg bytes, usec, ... \n" "\t-t threads total threads\n" "\t-c cores cores to use\n" "\t-a n force affinity every n cores\n" "\t-A n cache contention every n bytes\n" "\t-w report_ms milliseconds between reports\n" "", cmd); fprintf(stderr, "Available tests:\n"); for (i = 0; tests[i].name; i++) { fprintf(stderr, "%12s\n", tests[i].name); } exit(0); } struct glob_arg g; int main(int argc, char **argv) { int i, ch, report_interval, affinity, align; ND("g has size %d", (int)sizeof(g)); report_interval = 250; /* ms */ affinity = 0; /* no affinity */ align = 0; /* global variable */ bzero(&g, sizeof(g)); g.privs = getprivs(); g.nthreads = 1; g.cpus = 1; g.m_cycles = 0; while ( (ch = getopt(argc, argv, "A:a:m:n:w:c:t:vl:")) != -1) { switch(ch) { default: D("bad option %c %s", ch, optarg); usage(); break; case 'A': /* align */ align = atoi(optarg); break; case 'a': /* force affinity */ affinity = atoi(optarg); break; case 'n': /* cycles */ g.m_cycles = atoi(optarg); break; case 'w': /* report interval */ report_interval = atoi(optarg); break; case 'c': g.cpus = atoi(optarg); break; case 't': g.nthreads = atoi(optarg); break; case 'm': g.test_name = optarg; break; case 'l': g.arg = atoi(optarg); break; case 'v': verbose++; break; } } argc -= optind; argv += optind; if (!g.test_name && argc > 0) g.test_name = argv[0]; if (g.test_name) { for (i = 0; tests[i].name; i++) { if (!strcmp(g.test_name, tests[i].name)) { g.fn = tests[i].fn; g.scale = tests[i].scale; if (g.m_cycles == 0) g.m_cycles = tests[i].m_cycles; if (g.scale == ONE_MILLION) g.scale_name = "M"; else if (g.scale == 1000) g.scale_name = "M"; else { g.scale = 1; g.scale_name = ""; } break; } } } if (!g.fn) { D("%s", "missing/unknown test name"); usage(); } i = system_ncpus(); if (g.cpus < 0 || g.cpus > i) { D("%d cpus is too high, have only %d cpus", g.cpus, i); usage(); } if (g.cpus == 0) g.cpus = i; if (g.nthreads < 1) { D("bad nthreads %d, using 1", g.nthreads); g.nthreads = 1; } i = sizeof(g.v.ctr) / g.nthreads*sizeof(g.v.ctr[0]); if (align < 0 || align > i) { D("bad align %d, max is %d", align, i); align = i; } /* Install ^C handler. */ global_nthreads = g.nthreads; signal(SIGINT, sigint_h); ta = calloc(g.nthreads, sizeof(*ta)); /* * Now create the desired number of threads, each one * using a single descriptor. */ D("start %d threads on %d cores", g.nthreads, g.cpus); for (i = 0; i < g.nthreads; i++) { struct targ *t = &ta[i]; bzero(t, sizeof(*t)); t->g = &g; t->me = i; t->glob_ctr = &g.v.ctr[(i*align)/sizeof(g.v.ctr[0])]; D("thread %d ptr %p", i, t->glob_ctr); t->affinity = affinity ? (affinity*i) % g.cpus : -1; if (pthread_create(&t->thread, NULL, td_body, t) == -1) { D("Unable to create thread %d", i); t->completed = 1; } } /* the main loop */ { uint64_t my_count = 0, prev = 0; uint64_t count = 0; double delta_t; struct timeval tic, toc; gettimeofday(&toc, NULL); for (;;) { struct timeval now, delta; uint64_t pps; int done = 0; delta.tv_sec = report_interval/1000; delta.tv_usec = (report_interval%1000)*1000; select(0, NULL, NULL, NULL, &delta); gettimeofday(&now, NULL); timersub(&now, &toc, &toc); my_count = 0; for (i = 0; i < g.nthreads; i++) { my_count += ta[i].count; if (ta[i].completed) done++; } pps = toc.tv_sec* ONE_MILLION + toc.tv_usec; if (pps < 10000) continue; pps = (my_count - prev)*ONE_MILLION / pps; D("%" PRIu64 " %scycles/s scale %" PRIu64 " in %dus", pps/g.scale, g.scale_name, g.scale, (int)(toc.tv_sec* ONE_MILLION + toc.tv_usec)); prev = my_count; toc = now; if (done == g.nthreads) break; } D("total %" PRIu64 " cycles", prev); timerclear(&tic); timerclear(&toc); for (i = 0; i < g.nthreads; i++) { pthread_join(ta[i].thread, NULL); if (ta[i].completed == 0) continue; /* * Collect threads o1utput and extract information about * how log it took to send all the packets. */ count += ta[i].count; if (!timerisset(&tic) || timercmp(&ta[i].tic, &tic, <)) tic = ta[i].tic; if (!timerisset(&toc) || timercmp(&ta[i].toc, &toc, >)) toc = ta[i].toc; } /* print output. */ timersub(&toc, &tic, &toc); delta_t = toc.tv_sec + 1e-6* toc.tv_usec; D("total %8.6f seconds", delta_t); } return (0); } /* end of file */ From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 14:33:02 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AE87106564A; Wed, 22 Aug 2012 14:33:02 +0000 (UTC) (envelope-from mitya@cabletv.dp.ua) Received: from mail.cabletv.dp.ua (mail.cabletv.dp.ua [193.34.20.8]) by mx1.freebsd.org (Postfix) with ESMTP id F2B988FC14; Wed, 22 Aug 2012 14:33:01 +0000 (UTC) Received: from [193.34.20.2] (helo=m18.cabletv.dp.ua) by mail.cabletv.dp.ua with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1T4CSz-000KVR-3d; Wed, 22 Aug 2012 18:03:33 +0300 Message-ID: <5034EC27.1070203@cabletv.dp.ua> Date: Wed, 22 Aug 2012 17:26:47 +0300 From: Mitya User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:12.0) Gecko/20120425 Thunderbird/12.0 MIME-Version: 1.0 To: Luigi Rizzo , freebsd-net@freebsd.org, freebsd-hackers@freebsd.org References: <20120821112415.GA50078@onelab2.iet.unipi.it> <201208220232.q7M2WLCL020204@ref10-i386.freebsd.org> <20120822143632.GA64686@onelab2.iet.unipi.it> In-Reply-To: <20120822143632.GA64686@onelab2.iet.unipi.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: Re: speed tests (Re: Replace bcopy() to update ether_addr) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2012 14:33:02 -0000 22.08.2012 17:36, Luigi Rizzo напиÑал: > On Wed, Aug 22, 2012 at 02:32:21AM +0000, Bruce Evans wrote: >> luigi wrote: >> >>> even more orthogonal: >>> >>> I found that copying 8n + (5, 6 or 7) bytes was much much slower than >>> copying a multiple of 8 bytes. For n=0, 1,2,4,8 bytes are efficient, >>> other cases are slow (turned into 2 or 3 different writes). >>> >>> The netmap code uses a pkt_copy routine that does exactly this >>> rounding, gaining some 10-20ns per packet for small sizes. >> I don't believe 10-20ns for just the extra bytes. memcpy() ends up >> with a movsb to copy the extra bytes. This can be slow, but I don't >> believe 10-20ns (except on machines running at i486 speeds of course). > I am adding at the end a test program so people can try things on their hw. > > Build it with > > cc -O2 -Werror -Wall -Wextra -lpthread -lrt testlock.c -o testlock > > # uname -a FreeBSD m18.cabletv.dp.ua 9.0-STABLE FreeBSD 9.0-STABLE #1: Tue Apr 24 13:23:05 EEST 2012 root@m18.cabletv.dp.ua:/usr/src/sys/i386/compile/m18 i386 cc -O2 -Werror -Wall -Wextra -lpthread -lrt testlock.c -o testlock testlock.c: In function 'test_rdtsc': testlock.c:151: error: can't find a register in class 'AD_REGS' while reloading 'asm' testlock.c:151: error: 'asm' operand has impossible constraints From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 14:35:22 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D71CD106564A; Wed, 22 Aug 2012 14:35:22 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 94B468FC18; Wed, 22 Aug 2012 14:35:22 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id A75E57300A; Wed, 22 Aug 2012 16:54:29 +0200 (CEST) Date: Wed, 22 Aug 2012 16:54:29 +0200 From: Luigi Rizzo To: Mitya Message-ID: <20120822145429.GB64686@onelab2.iet.unipi.it> References: <20120821112415.GA50078@onelab2.iet.unipi.it> <201208220232.q7M2WLCL020204@ref10-i386.freebsd.org> <20120822143632.GA64686@onelab2.iet.unipi.it> <5034EC27.1070203@cabletv.dp.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5034EC27.1070203@cabletv.dp.ua> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: speed tests (Re: Replace bcopy() to update ether_addr) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2012 14:35:23 -0000 On Wed, Aug 22, 2012 at 05:26:47PM +0300, Mitya wrote: > 22.08.2012 17:36, Luigi Rizzo ??????????????: > >On Wed, Aug 22, 2012 at 02:32:21AM +0000, Bruce Evans wrote: > >>luigi wrote: > >> > >>>even more orthogonal: > >>> > >>>I found that copying 8n + (5, 6 or 7) bytes was much much slower than > >>>copying a multiple of 8 bytes. For n=0, 1,2,4,8 bytes are efficient, > >>>other cases are slow (turned into 2 or 3 different writes). > >>> > >>>The netmap code uses a pkt_copy routine that does exactly this > >>>rounding, gaining some 10-20ns per packet for small sizes. > >>I don't believe 10-20ns for just the extra bytes. memcpy() ends up > >>with a movsb to copy the extra bytes. This can be slow, but I don't > >>believe 10-20ns (except on machines running at i486 speeds of course). > >I am adding at the end a test program so people can try things on their hw. > > > >Build it with > > > > cc -O2 -Werror -Wall -Wextra -lpthread -lrt testlock.c -o testlock > > > > > > # uname -a > FreeBSD m18.cabletv.dp.ua 9.0-STABLE FreeBSD 9.0-STABLE #1: Tue Apr 24 > 13:23:05 EEST 2012 root@m18.cabletv.dp.ua:/usr/src/sys/i386/compile/m18 i386 > > cc -O2 -Werror -Wall -Wextra -lpthread -lrt testlock.c -o testlock > > testlock.c: In function 'test_rdtsc': > testlock.c:151: error: can't find a register in class 'AD_REGS' while > reloading 'asm' > testlock.c:151: error: 'asm' operand has impossible constraints i forgot to mention that i tried this only on amd64, my ASM is horrible. Just comment out the offending lines and do not run those tests. Or, if you have a portable fix, let me know and everybody will appreciate it. cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 18:54:07 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BCE5F106564A; Wed, 22 Aug 2012 18:54:07 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 817AF8FC12; Wed, 22 Aug 2012 18:54:07 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so1953318pbb.13 for ; Wed, 22 Aug 2012 11:54:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=rZfpz1tHNTTbKu38ojel5PANQA/rJ6lxn/hzSdvoPfU=; b=i43JnjXohwftbPVV7ETFoNBPqMNitbFlA4cf6Fcx+ACbV3tfRv6wL2q8tjCIICbK2S fOKAwsUc9dHNCVnh8kQMaZFbt1Ha+SFsm8vR7aCUQGACKYmTWHhvxOieijY5sLTkYtrv yQoW19LSj8y4j9GgCvwyQZ6wUqce5cFEtkpAvw5KPqE/bXnxQCjPvhnugP31bL7Gyx7t rhIW+3sjbMCGyiclGld/mhCKycGJjO5X2KiDBpngFuLRAlh4gicnqjijIYlE5hwhH7YS WdExxnlGFKTWvS2wrcQqj6nF8xO0H59MlbemSezxKTt0ASq16s+XomJpXqZaRX5DZRQQ V4yw== MIME-Version: 1.0 Received: by 10.68.129.131 with SMTP id nw3mr55048357pbb.43.1345661647286; Wed, 22 Aug 2012 11:54:07 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.36.106 with HTTP; Wed, 22 Aug 2012 11:54:07 -0700 (PDT) In-Reply-To: <201208220802.14588.jhb@freebsd.org> References: <50324DB4.6080905@cabletv.dp.ua> <420BA06C-C776-47DB-B3BB-F1414C115F99@bsdimp.com> <201208220802.14588.jhb@freebsd.org> Date: Wed, 22 Aug 2012 11:54:07 -0700 X-Google-Sender-Auth: x8ry_dNw4_u3xMxdchT3PDLjlps Message-ID: From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org, Mitya , Warner Losh , Wojciech Puchar Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2012 18:54:07 -0000 On 22 August 2012 05:02, John Baldwin wrote: > On Tuesday, August 21, 2012 12:34:42 pm Adrian Chadd wrote: >> Hi, >> >> What about just creating an ETHER_ADDR_COPY(dst, src) and putting that >> in a relevant include file, then hide the ugliness there? >> >> The same benefits will likely appear when copying wifi MAC addresses >> to/from headers. >> >> Thanks, I'm glad someone noticed this. > > I doubt we even _need_ the ugliness. We should just use *dst = *src > unless there is a compelling reason not to. Because it's not very clear? :-) I'd much prefer my array-of-things copies to be explicit. Also, the optimisation and compiler silliness may not be THAT obvious on intel (except when you're luigi and using netmap) but I can't help but wonder whether the same does hold for MIPS/ARM. Getting it wrong there will lead to some very very poor performing code. Adrian From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 19:50:09 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 03CB31065688 for ; Wed, 22 Aug 2012 19:50:09 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id A704A8FC29 for ; Wed, 22 Aug 2012 19:50:08 +0000 (UTC) Received: by yhfs35 with SMTP id s35so1231740yhf.13 for ; Wed, 22 Aug 2012 12:50:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=2nr5oaNJ/Yw6eN8tJNsoJaGPzKQjz8Q5DxvSC/Dz7I8=; b=aKPqKSHU5k/1VXzdEKjieTwSZu4ytXkWQwISMs/Fh77lfaIN6Lt3KdExZ9f9XWXrUZ YFZcuat1WZiN7Fvumlaj9wzUKhcwIGHSpOSCet5iSuPUdVhnOKuuwqPxKnfK7MQhDrM6 Xnk0ZH68SrYuU056y2grThQispiMPjPlJ8I3069Lmej+OdRSfNwx2Y0XGdtUSLAoxc/5 bm6N4BJWpkEl1GU7DuvQI32bImn2aARaIg7n7hUUIP5SHFBWHGs4YQxlSn80aIaqVRw7 juq01c7P/2MbyDSWvThE0KGcuOH0/UfFpdqWP9VJ/ErlXbJ2i50lj0l/eNgyaZgaJ7fT vFTQ== Received: by 10.60.29.169 with SMTP id l9mr16384557oeh.14.1345665007575; Wed, 22 Aug 2012 12:50:07 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id k3sm4706410obw.4.2012.08.22.12.50.05 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Aug 2012 12:50:06 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Wed, 22 Aug 2012 13:50:04 -0600 Content-Transfer-Encoding: 7bit Message-Id: <3952D2BB-2181-430C-86BC-F9F90706C7A0@bsdimp.com> References: <50324DB4.6080905@cabletv.dp.ua> <420BA06C-C776-47DB-B3BB-F1414C115F99@bsdimp.com> <201208220802.14588.jhb@freebsd.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmIOhfPGT6XBROu5PxDgFNQEqn+4nvk8cRlTOufh4V0gfTVEq4KbqNWKXf++4E535ZY/yMD Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org, Mitya , John Baldwin , Wojciech Puchar Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2012 19:50:09 -0000 On Aug 22, 2012, at 12:54 PM, Adrian Chadd wrote: > On 22 August 2012 05:02, John Baldwin wrote: >> On Tuesday, August 21, 2012 12:34:42 pm Adrian Chadd wrote: >>> Hi, >>> >>> What about just creating an ETHER_ADDR_COPY(dst, src) and putting that >>> in a relevant include file, then hide the ugliness there? >>> >>> The same benefits will likely appear when copying wifi MAC addresses >>> to/from headers. >>> >>> Thanks, I'm glad someone noticed this. >> >> I doubt we even _need_ the ugliness. We should just use *dst = *src >> unless there is a compelling reason not to. > > Because it's not very clear? :-) I'd much prefer my array-of-things > copies to be explicit. But it isn't an array of things. It is a structure.a > Also, the optimisation and compiler silliness may not be THAT obvious > on intel (except when you're luigi and using netmap) but I can't help > but wonder whether the same does hold for MIPS/ARM. Getting it wrong > there will lead to some very very poor performing code. Which is why we need to check that output to make sure it isn't too horrible. Warner From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 20:06:31 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 637A41065675; Wed, 22 Aug 2012 20:06:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 35F1E8FC21; Wed, 22 Aug 2012 20:06:31 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 87355B97E; Wed, 22 Aug 2012 16:06:30 -0400 (EDT) From: John Baldwin To: Adrian Chadd Date: Wed, 22 Aug 2012 15:21:06 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <50324DB4.6080905@cabletv.dp.ua> <201208220802.14588.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201208221521.06954.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 22 Aug 2012 16:06:30 -0400 (EDT) Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org, Mitya , Warner Losh , Wojciech Puchar Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2012 20:06:31 -0000 On Wednesday, August 22, 2012 2:54:07 pm Adrian Chadd wrote: > On 22 August 2012 05:02, John Baldwin wrote: > > On Tuesday, August 21, 2012 12:34:42 pm Adrian Chadd wrote: > >> Hi, > >> > >> What about just creating an ETHER_ADDR_COPY(dst, src) and putting that > >> in a relevant include file, then hide the ugliness there? > >> > >> The same benefits will likely appear when copying wifi MAC addresses > >> to/from headers. > >> > >> Thanks, I'm glad someone noticed this. > > > > I doubt we even _need_ the ugliness. We should just use *dst = *src > > unless there is a compelling reason not to. > > Because it's not very clear? :-) I'd much prefer my array-of-things > copies to be explicit. Eh? 'struct foo *src, *dst; *dst = *src' is pretty bog-standard C. That isn't really all that obtuse. > Also, the optimisation and compiler silliness may not be THAT obvious > on intel (except when you're luigi and using netmap) but I can't help > but wonder whether the same does hold for MIPS/ARM. Getting it wrong > there will lead to some very very poor performing code. Don't you think there's a really good chance the compiler knows how to copy a structure appropriately for each architecture already? -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 20:28:48 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 693D1106566B; Wed, 22 Aug 2012 20:28:48 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 0B77E8FC1B; Wed, 22 Aug 2012 20:28:37 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q7MJsdZ0061881; Wed, 22 Aug 2012 21:54:40 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q7MJsWkq061878; Wed, 22 Aug 2012 21:54:36 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Wed, 22 Aug 2012 21:54:32 +0200 (CEST) From: Wojciech Puchar To: Adrian Chadd In-Reply-To: Message-ID: References: <50324DB4.6080905@cabletv.dp.ua> <420BA06C-C776-47DB-B3BB-F1414C115F99@bsdimp.com> <201208220802.14588.jhb@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Wed, 22 Aug 2012 21:54:42 +0200 (CEST) Cc: freebsd-hackers@freebsd.org, Mitya , Warner Losh , John Baldwin , freebsd-net@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2012 20:28:48 -0000 > but wonder whether the same does hold for MIPS/ARM. Getting it wrong > there will lead to some very very poor performing code. > 1) do - as already pointed out - standard copy of structure in C. 2) if compiler is found to generate bad code on some archs put assembly. 1 even if compiler is not smart is already far better than calling a function to copy 6 bytes that is plain stupid. From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 21:33:37 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 751AC106566B; Wed, 22 Aug 2012 21:33:37 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 2CCBC8FC12; Wed, 22 Aug 2012 21:33:36 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 695477300A; Wed, 22 Aug 2012 23:52:44 +0200 (CEST) Date: Wed, 22 Aug 2012 23:52:44 +0200 From: Luigi Rizzo To: John Baldwin Message-ID: <20120822215244.GC67796@onelab2.iet.unipi.it> References: <50324DB4.6080905@cabletv.dp.ua> <201208220802.14588.jhb@freebsd.org> <201208221521.06954.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201208221521.06954.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org, Adrian Chadd , Mitya , Wojciech Puchar , freebsd-net@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2012 21:33:37 -0000 On Wed, Aug 22, 2012 at 03:21:06PM -0400, John Baldwin wrote: > On Wednesday, August 22, 2012 2:54:07 pm Adrian Chadd wrote: > > On 22 August 2012 05:02, John Baldwin wrote: > > > On Tuesday, August 21, 2012 12:34:42 pm Adrian Chadd wrote: > > >> Hi, > > >> > > >> What about just creating an ETHER_ADDR_COPY(dst, src) and putting that > > >> in a relevant include file, then hide the ugliness there? > > >> > > >> The same benefits will likely appear when copying wifi MAC addresses > > >> to/from headers. > > >> > > >> Thanks, I'm glad someone noticed this. > > > > > > I doubt we even _need_ the ugliness. We should just use *dst = *src > > > unless there is a compelling reason not to. > > > > Because it's not very clear? :-) I'd much prefer my array-of-things > > copies to be explicit. > > Eh? 'struct foo *src, *dst; *dst = *src' is pretty bog-standard C. That > isn't really all that obtuse. the thread has probably forked causing people to miss the explanation that Bruce gave: quite often the function is called by casting arbitrary pointers into 'struct foo *', so the compiler's expectations about alignment do not necessarily match the user's lies. Unfortunately we are building kernels with many compiler checks disabled, so there is a fair chance that the compiler will not detect such invalid casts. Probably addresses are aligned to 2-byte boundaries, but certainly not on a 4-byte, which means that a safe copy might require 3 instructions, even though a compiler could otherwise decide to align all non-packed 'struct foo' to a 4- or 8-byte boundary and possibly do the copy with 2 or even 1 instruction. I would also suggest to try the code i posted in response to bruce so you can check how good or bad are the various solutions on different architectures or CPUs, and see if there is a reasonable compromise. cheers luigi > > Also, the optimisation and compiler silliness may not be THAT obvious > > on intel (except when you're luigi and using netmap) but I can't help > > but wonder whether the same does hold for MIPS/ARM. Getting it wrong > > there will lead to some very very poor performing code. > > Don't you think there's a really good chance the compiler knows how to copy a > structure appropriately for each architecture already? > > -- > John Baldwin > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Aug 23 01:00:19 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E7E7106566B for ; Thu, 23 Aug 2012 01:00:19 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3B13F8FC08 for ; Thu, 23 Aug 2012 01:00:19 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q7N10JiA000373 for ; Thu, 23 Aug 2012 01:00:19 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q7N10J9C000372; Thu, 23 Aug 2012 01:00:19 GMT (envelope-from gnats) Date: Thu, 23 Aug 2012 01:00:19 GMT Message-Id: <201208230100.q7N10J9C000372@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Navdeep Parhar Cc: Subject: Re: kern/170713: [cxgb] Driver must be loaded after boot due to timing issues checking for kern.ipc.nmb* values set via /boot/loader.conf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Navdeep Parhar List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 01:00:19 -0000 The following reply was made to PR kern/170713; it has been noted by GNATS. From: Navdeep Parhar To: bug-followup@FreeBSD.org, yanegomi@gmail.com Cc: Subject: Re: kern/170713: [cxgb] Driver must be loaded after boot due to timing issues checking for kern.ipc.nmb* values set via /boot/loader.conf Date: Wed, 22 Aug 2012 17:56:34 -0700 First, note that only kern.ipc.nmbclusters is a valid tunable. The rest of the nmbXXX settings in your loader.conf have no effect. There are sysctls but no tunables for the rest. Take a look at tunable_mbinit in kern_mbuf.c -- on recent FreeBSD versions it starts with nmbclusters and sizes others based on this. You can set nmbclusters really high and influence the values of the other parameters. In my opinion we should have a TUNABLE_INT_FETCH for all of the nmbXXX and autocalculate the ones that are not set, just like what we do for nmbclusters today. static void tunable_mbinit(void *dummy) { TUNABLE_INT_FETCH("kern.ipc.nmbclusters", &nmbclusters); /* This has to be done before VM init. */ if (nmbclusters == 0) nmbclusters = 1024 + maxusers * 64; nmbjumbop = nmbclusters / 2; nmbjumbo9 = nmbjumbop / 2; nmbjumbo16 = nmbjumbo9 / 2; } Compare this to the tunable_mbinit in 7 and you can see why the nmbclusters tunable does not affect the others -- it is updated after the other values have already been calculated. static void tunable_mbinit(void *dummy) { /* This has to be done before VM init. */ nmbclusters = 1024 + maxusers * 64; nmbjumbop = nmbclusters / 2; nmbjumbo9 = nmbjumbop / 2; nmbjumbo16 = nmbjumbo9 / 2; TUNABLE_INT_FETCH("kern.ipc.nmbclusters", &nmbclusters); } Regards, Navdeep From owner-freebsd-net@FreeBSD.ORG Thu Aug 23 02:28:36 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9EC01106564A for ; Thu, 23 Aug 2012 02:28:36 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 15FEA8FC08 for ; Thu, 23 Aug 2012 02:28:35 +0000 (UTC) Received: from server.rulingia.com (c220-239-249-137.belrs5.nsw.optusnet.com.au [220.239.249.137]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q7N2SYKk091533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 23 Aug 2012 12:28:34 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q7N2SSWl032996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 23 Aug 2012 12:28:28 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q7N2SS20032995 for freebsd-net@freebsd.org; Thu, 23 Aug 2012 12:28:28 +1000 (EST) (envelope-from peter) Date: Thu, 23 Aug 2012 12:28:28 +1000 From: Peter Jeremy To: freebsd-net@freebsd.org Message-ID: <20120823022828.GA32766@server.rulingia.com> References: <20120822040201.GA96087@server.rulingia.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline In-Reply-To: <20120822040201.GA96087@server.rulingia.com> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: Incorrect ARP table entries X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Aug 2012 02:28:36 -0000 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Aug-22 14:02:01 +1000, Peter Jeremy wro= te: >I've run into a problem where the ARP table on several of my hosts is >apparently spontaneously replacing correct entries with incorrect MAC >addresses. I've done some digging with tcpdump and can't identify the >cause. I've tried to look in the code but lost my way since ARP and >IP routing seem to be closely intermingled. I'm hoping someone might >be able to shed some light on why it is behaving the way it is. I've done some more detailed trawling through tcpdump captures and found that this is another entry in the "never buy HP" collection. It turns out the iLO is sending ARP requests with the correct link- layer source MAC address in the Ethernet frame but the "sender hardware address" in the ARP request is wrong - and (as required by RFC826) FreeBSD is using the latter MAC address to update its ARP table. Note that this iLO has a physically separate NIC and doesn't have provision for shared NIC so there's no excuse for it's behaviour. RFC826 is fairly clear that FreeBSD is behaving correctly in using the "sender hardware address" in the ARP request (though it doesn't specifically address the case where that is different to the link-layer source address). My work-around is to use arp(8) to permanently wire the correct MAC address into the local ARP table. --=20 Peter Jeremy --AqsLC8rIMeq19msA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlA1lUwACgkQ/opHv/APuIfYWQCeKOC5PMELctc2eOYiGTPdLqdY qgwAoKmQeoRZTdZ8O1vKepo2Zo9KrfMD =gxFG -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- From owner-freebsd-net@FreeBSD.ORG Thu Aug 23 03:40:16 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84657106564A; Thu, 23 Aug 2012 03:40:16 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 57FE38FC0A; Thu, 23 Aug 2012 03:40:16 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q7N3eG3J021971; Thu, 23 Aug 2012 03:40:16 GMT (envelope-from gjb@freefall.freebsd.org) Received: (from gjb@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q7N3eGtP021967; Thu, 23 Aug 2012 03:40:16 GMT (envelope-from gjb) Date: Thu, 23 Aug 2012 03:40:16 GMT Message-Id: <201208230340.q7N3eGtP021967@freefall.freebsd.org> To: gjb@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: gjb@FreeBSD.org Cc: Subject: Re: kern/170904: [ath] ath driver: configure related parameters when radar detection (DFS) is enabled X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Aug 2012 03:40:16 -0000 Old Synopsis: ath driver: configure related parameters when radar detection (DFS) is enabled New Synopsis: [ath] ath driver: configure related parameters when radar detection (DFS) is enabled Class-Changed-From-To: change-request->sw-bug Class-Changed-By: gjb Class-Changed-When: Thu Aug 23 03:38:20 UTC 2012 Class-Changed-Why: Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gjb Responsible-Changed-When: Thu Aug 23 03:38:20 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=170904 From owner-freebsd-net@FreeBSD.ORG Thu Aug 23 03:40:41 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4F651106564A; Thu, 23 Aug 2012 03:40:41 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 229698FC14; Thu, 23 Aug 2012 03:40:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q7N3efhS022023; Thu, 23 Aug 2012 03:40:41 GMT (envelope-from gjb@freefall.freebsd.org) Received: (from gjb@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q7N3efdo022019; Thu, 23 Aug 2012 03:40:41 GMT (envelope-from gjb) Date: Thu, 23 Aug 2012 03:40:41 GMT Message-Id: <201208230340.q7N3efdo022019@freefall.freebsd.org> To: gjb@FreeBSD.org, freebsd-net@FreeBSD.org, freebsd-net@FreeBSD.org From: gjb@FreeBSD.org Cc: Subject: Re: kern/170904: [ath] ath driver: configure related parameters when radar detection (DFS) is enabled X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Aug 2012 03:40:41 -0000 Synopsis: [ath] ath driver: configure related parameters when radar detection (DFS) is enabled Class-Changed-From-To: sw-bug->change-request Class-Changed-By: gjb Class-Changed-When: Thu Aug 23 03:40:21 UTC 2012 Class-Changed-Why: Undo class change with previous edit. http://www.freebsd.org/cgi/query-pr.cgi?pr=170904 From owner-freebsd-net@FreeBSD.ORG Thu Aug 23 03:47:46 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96E30106566C; Thu, 23 Aug 2012 03:47:46 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6A75E8FC08; Thu, 23 Aug 2012 03:47:46 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q7N3lkrh022586; Thu, 23 Aug 2012 03:47:46 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q7N3lkgs022582; Thu, 23 Aug 2012 03:47:46 GMT (envelope-from linimon) Date: Thu, 23 Aug 2012 03:47:46 GMT Message-Id: <201208230347.q7N3lkgs022582@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-net@FreeBSD.org, freebsd-wireless@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/170904: [ath] ath driver: configure related parameters when radar detection (DFS) is enabled X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Aug 2012 03:47:46 -0000 Synopsis: [ath] ath driver: configure related parameters when radar detection (DFS) is enabled Responsible-Changed-From-To: freebsd-net->freebsd-wireless Responsible-Changed-By: linimon Responsible-Changed-When: Thu Aug 23 03:47:27 UTC 2012 Responsible-Changed-Why: Set more canonical assignment. http://www.freebsd.org/cgi/query-pr.cgi?pr=170904 From owner-freebsd-net@FreeBSD.ORG Thu Aug 23 05:50:06 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 468C11065672 for ; Thu, 23 Aug 2012 05:50:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 135AD8FC14 for ; Thu, 23 Aug 2012 05:50:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q7N5o50u037426 for ; Thu, 23 Aug 2012 05:50:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q7N5o5oD037425; Thu, 23 Aug 2012 05:50:05 GMT (envelope-from gnats) Date: Thu, 23 Aug 2012 05:50:05 GMT Message-Id: <201208230550.q7N5o5oD037425@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Garrett Cooper Cc: Subject: Re: kern/170713: [cxgb] Driver must be loaded after boot due to timing issues checking for kern.ipc.nmb* values set via /boot/loader.conf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Garrett Cooper List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 05:50:06 -0000 The following reply was made to PR kern/170713; it has been noted by GNATS. From: Garrett Cooper To: Navdeep Parhar Cc: bug-followup@freebsd.org Subject: Re: kern/170713: [cxgb] Driver must be loaded after boot due to timing issues checking for kern.ipc.nmb* values set via /boot/loader.conf Date: Wed, 22 Aug 2012 22:48:23 -0700 On Wed, Aug 22, 2012 at 5:56 PM, Navdeep Parhar wrote: > First, note that only kern.ipc.nmbclusters is a valid tunable. The rest of > the nmbXXX settings in your loader.conf have no effect. There are sysctls > but no tunables for the rest. Yes. I've been tweaking things between both areas, and I agree that sysctl-only works for non-nmbclusters. > Take a look at tunable_mbinit in kern_mbuf.c -- on recent FreeBSD versions > it starts with nmbclusters and sizes others based on this. You can set > nmbclusters really high and influence the values of the other parameters. > > In my opinion we should have a TUNABLE_INT_FETCH for all of the nmbXXX and > autocalculate the ones that are not set, just like what we do for > nmbclusters today. > > static void > tunable_mbinit(void *dummy) > { > TUNABLE_INT_FETCH("kern.ipc.nmbclusters", &nmbclusters); > > /* This has to be done before VM init. */ > if (nmbclusters == 0) > nmbclusters = 1024 + maxusers * 64; > nmbjumbop = nmbclusters / 2; > nmbjumbo9 = nmbjumbop / 2; > nmbjumbo16 = nmbjumbo9 / 2; > } > > > Compare this to the tunable_mbinit in 7 and you can see why the nmbclusters > tunable does not affect the others -- it is updated after the other values > have already been calculated. > static void > tunable_mbinit(void *dummy) > { > > /* This has to be done before VM init. */ > nmbclusters = 1024 + maxusers * 64; > nmbjumbop = nmbclusters / 2; > nmbjumbo9 = nmbjumbop / 2; > nmbjumbo16 = nmbjumbo9 / 2; > TUNABLE_INT_FETCH("kern.ipc.nmbclusters", &nmbclusters); > } Funny. I'll do some poking around in our sourcebase and see whether this has been backported.. Thanks, -Garrett From owner-freebsd-net@FreeBSD.ORG Thu Aug 23 20:13:49 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E6F01065670 for ; Thu, 23 Aug 2012 20:13:49 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5C6C58FC19 for ; Thu, 23 Aug 2012 20:13:48 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so2178543pbb.13 for ; Thu, 23 Aug 2012 13:13:42 -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; bh=TZX4rlpgM903F09V5I24K74eM8gLeuuyKYoz7LtyPAA=; b=kEwD7YkeIRBoLWnoRmXB9Od5s4WoGfBuY0u7WCxLTEWvvEWhKryXM8WbeRxDFswGFy mJRx7hH7KUomSyWec18KRG0Ukv6s+uiXgrj3GNU1CnrweDi5uoMgV9FfQBG3XBVQ5tb/ 1TZ2TBfI7Jra5dcVR+Bc3UC7ScmeB0zSTP4V12IpIM91sbVEjtXUl2UNfbO+V+94YJhV ROlSKjBXN6kXkaveYvGYF49e4W8BPXrdnCho/A4J6e+4IVzmB3hvHK9hmUebdnsjhyCQ /4BCE6vc3M/W06BDlGrcyYoK0zBWufQgb0VK1/Dmv2cjV+e4fMtsmIC5J0Pge7At51Q/ a3Vw== Received: by 10.68.212.161 with SMTP id nl1mr7422801pbc.84.1345752822669; Thu, 23 Aug 2012 13:13:42 -0700 (PDT) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPS id uu10sm6658415pbc.2.2012.08.23.13.13.40 (version=SSLv3 cipher=OTHER); Thu, 23 Aug 2012 13:13:41 -0700 (PDT) Sender: Navdeep Parhar Message-ID: <50368EF3.4050600@FreeBSD.org> Date: Thu, 23 Aug 2012 13:13:39 -0700 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120821 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary="------------020407010101070509020805" Subject: [PATCH] Allow nmbjumboX to be set via kernel tunables. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Aug 2012 20:13:49 -0000 This is a multi-part message in MIME format. --------------020407010101070509020805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Here is a patch that allows each of nmbjumboXX to be set via tunables at boot-time, independent of nmbclusters. It is useful to be able to set them this way and avoid problems like the one reported in kern/170713 here: http://www.freebsd.org/cgi/query-pr.cgi?pr=170713 What do you think? If there are no objections I'll test and commit this in two weeks. If people agree I'll commit it right away. Regards, Navdeep diff -r dca9027569a2 sys/kern/kern_mbuf.c --- a/sys/kern/kern_mbuf.c Thu Aug 23 12:00:12 2012 -0700 +++ b/sys/kern/kern_mbuf.c Thu Aug 23 12:26:09 2012 -0700 @@ -110,14 +110,23 @@ static void tunable_mbinit(void *dummy) { - TUNABLE_INT_FETCH("kern.ipc.nmbclusters", &nmbclusters); /* This has to be done before VM init. */ + TUNABLE_INT_FETCH("kern.ipc.nmbclusters", &nmbclusters); if (nmbclusters == 0) nmbclusters = 1024 + maxusers * 64; - nmbjumbop = nmbclusters / 2; - nmbjumbo9 = nmbjumbop / 2; - nmbjumbo16 = nmbjumbo9 / 2; + + TUNABLE_INT_FETCH("kern.ipc.nmbjumbop", &nmbjumbop); + if (nmbjumbop == 0) + nmbjumbop = nmbclusters / 2; + + TUNABLE_INT_FETCH("kern.ipc.nmbjumbo9", &nmbjumbo9); + if (nmbjumbo9 == 0) + nmbjumbo9 = nmbclusters / 4; + + TUNABLE_INT_FETCH("kern.ipc.nmbjumbo16", &nmbjumbo16); + if (nmbjumbo16 == 0) + nmbjumbo16 = nmbclusters / 8; } SYSINIT(tunable_mbinit, SI_SUB_TUNABLES, SI_ORDER_MIDDLE, tunable_mbinit, NULL); --------------020407010101070509020805 Content-Type: text/plain; charset=us-ascii; name="nmb.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="nmb.diff" diff -r dca9027569a2 sys/kern/kern_mbuf.c --- a/sys/kern/kern_mbuf.c Thu Aug 23 12:00:12 2012 -0700 +++ b/sys/kern/kern_mbuf.c Thu Aug 23 13:10:31 2012 -0700 @@ -110,14 +110,23 @@ static void tunable_mbinit(void *dummy) { - TUNABLE_INT_FETCH("kern.ipc.nmbclusters", &nmbclusters); /* This has to be done before VM init. */ + TUNABLE_INT_FETCH("kern.ipc.nmbclusters", &nmbclusters); if (nmbclusters == 0) nmbclusters = 1024 + maxusers * 64; - nmbjumbop = nmbclusters / 2; - nmbjumbo9 = nmbjumbop / 2; - nmbjumbo16 = nmbjumbo9 / 2; + + TUNABLE_INT_FETCH("kern.ipc.nmbjumbop", &nmbjumbop); + if (nmbjumbop == 0) + nmbjumbop = nmbclusters / 2; + + TUNABLE_INT_FETCH("kern.ipc.nmbjumbo9", &nmbjumbo9); + if (nmbjumbo9 == 0) + nmbjumbo9 = nmbclusters / 4; + + TUNABLE_INT_FETCH("kern.ipc.nmbjumbo16", &nmbjumbo16); + if (nmbjumbo16 == 0) + nmbjumbo16 = nmbclusters / 8; } SYSINIT(tunable_mbinit, SI_SUB_TUNABLES, SI_ORDER_MIDDLE, tunable_mbinit, NULL); --------------020407010101070509020805-- From owner-freebsd-net@FreeBSD.ORG Thu Aug 23 20:45:37 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B5C83106566B; Thu, 23 Aug 2012 20:45:37 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 791B08FC12; Thu, 23 Aug 2012 20:45:37 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so2221055pbb.13 for ; Thu, 23 Aug 2012 13:45:37 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=eTs2PDCvXo7HJ4XyB3Z7nXzztmeJZO27snyZbgEdlj4=; b=qUu9nVbvlEtvRhOXcVR/7/WsbrLdmN91xKPJ6kf/ZdqCNXgdJIQQTftCM4Lo0LHhN5 spYO9JsLOkRhXXqThR5otK6SceocRLgzETNJ3gEql8NjBzeSa/lUw6ho6fdrkmMRej1P ZfUWl1PycXy0ov5H2ZgzJTtEng0D93LtnKwT78dL+VTnvnNjNeguusQ6gbBh6V+JIV66 1PHZ9crCEYy/MWCwbsA5G7JJ7n+f5JgBPVmGezKwGoZqZ0B18SSaydMfpuUYk9CBpj7G fFdH7+D4LS83kXDtV2EXXXgY5PacQuxa+c6IhgQLEIr5RaWihkqcZAQME60d4hQyVvQN Sa2g== MIME-Version: 1.0 Received: by 10.68.238.74 with SMTP id vi10mr7562884pbc.48.1345754737174; Thu, 23 Aug 2012 13:45:37 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.36.106 with HTTP; Thu, 23 Aug 2012 13:45:37 -0700 (PDT) In-Reply-To: <20120822215244.GC67796@onelab2.iet.unipi.it> References: <50324DB4.6080905@cabletv.dp.ua> <201208220802.14588.jhb@freebsd.org> <201208221521.06954.jhb@freebsd.org> <20120822215244.GC67796@onelab2.iet.unipi.it> Date: Thu, 23 Aug 2012 13:45:37 -0700 X-Google-Sender-Auth: cEMIlt1cCvnwt95ul82zb1EHs6E Message-ID: From: Adrian Chadd To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Wojciech Puchar , Mitya , John Baldwin , freebsd-net@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Aug 2012 20:45:37 -0000 You can't assume the ethernet addresses will be aligned. For wifi headers you're definitely going to have at least one address be non-dword aligned, even if the header itself is dword aligned. The whole point of using a macro is so it becomes really easy to change the copy type at compile time. Otherwise I'll have to go through the code, find all the (CPU intensive/stalling) places where those 6 byte copies are occuring and replace them. Adrian From owner-freebsd-net@FreeBSD.ORG Thu Aug 23 20:55:03 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D41321065730; Thu, 23 Aug 2012 20:55:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id E17198FC1E; Thu, 23 Aug 2012 20:55:01 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 44EF4B978; Thu, 23 Aug 2012 16:55:01 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Date: Thu, 23 Aug 2012 16:51:59 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <50368EF3.4050600@FreeBSD.org> In-Reply-To: <50368EF3.4050600@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201208231651.59413.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 23 Aug 2012 16:55:01 -0400 (EDT) Cc: Navdeep Parhar Subject: Re: [PATCH] Allow nmbjumboX to be set via kernel tunables. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Aug 2012 20:55:04 -0000 On Thursday, August 23, 2012 4:13:39 pm Navdeep Parhar wrote: > Here is a patch that allows each of nmbjumboXX to be set via tunables at > boot-time, independent of nmbclusters. It is useful to be able to set > them this way and avoid problems like the one reported in kern/170713 here: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=170713 > > What do you think? If there are no objections I'll test and commit this > in two weeks. If people agree I'll commit it right away. Great idea and patch. Commit! Thanks. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri Aug 24 00:39:34 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 420E7106566B; Fri, 24 Aug 2012 00:39:34 +0000 (UTC) (envelope-from bde@FreeBSD.org) Received: from ref10-i386.freebsd.org (unknown [IPv6:2001:4f8:fff6::5e]) by mx1.freebsd.org (Postfix) with ESMTP id 2B38E8FC08; Fri, 24 Aug 2012 00:39:34 +0000 (UTC) Received: from ref10-i386.freebsd.org (localhost [127.0.0.1]) by ref10-i386.freebsd.org (8.14.5/8.14.5) with ESMTP id q7O0dYZK029436; Fri, 24 Aug 2012 00:39:34 GMT (envelope-from bde@ref10-i386.freebsd.org) Received: (from bde@localhost) by ref10-i386.freebsd.org (8.14.5/8.14.5/Submit) id q7O0dUbl029143; Fri, 24 Aug 2012 00:39:30 GMT (envelope-from bde) Date: Fri, 24 Aug 2012 00:39:30 GMT From: Bruce Evans Message-Id: <201208240039.q7O0dUbl029143@ref10-i386.freebsd.org> To: jhb@FreeBSD.org, rizzo@iet.unipi.it In-Reply-To: <20120822215244.GC67796@onelab2.iet.unipi.it> Cc: freebsd-hackers@FreeBSD.org, adrian@FreeBSD.org, mitya@cabletv.dp.ua, wojtek@wojtek.tensor.gdynia.pl, freebsd-net@FreeBSD.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Aug 2012 00:39:34 -0000 >From owner-freebsd-net@FreeBSD.org Thu Aug 23 10:58:03 2012 Delivered-To: freebsd-net@freebsd.org Date: Wed, 22 Aug 2012 23:52:44 +0200 From: Luigi Rizzo To: John Baldwin References: <50324DB4.6080905@cabletv.dp.ua> <201208220802.14588.jhb@freebsd.org> <201208221521.06954.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201208221521.06954.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@FreeBSD.org, Adrian Chadd , Mitya , Wojciech Puchar , freebsd-net@FreeBSD.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: owner-freebsd-net@FreeBSD.org Errors-To: owner-freebsd-net@FreeBSD.org Content-Length: 2762 Lines: 64 On Wed, Aug 22, 2012 at 03:21:06PM -0400, John Baldwin wrote: > On Wednesday, August 22, 2012 2:54:07 pm Adrian Chadd wrote: > > On 22 August 2012 05:02, John Baldwin wrote: > > > On Tuesday, August 21, 2012 12:34:42 pm Adrian Chadd wrote: > > >> Hi, > > >> > > >> What about just creating an ETHER_ADDR_COPY(dst, src) and putting that > > >> in a relevant include file, then hide the ugliness there? > > >> > > >> The same benefits will likely appear when copying wifi MAC addresses > > >> to/from headers. > > >> > > >> Thanks, I'm glad someone noticed this. > > > > > > I doubt we even _need_ the ugliness. We should just use *dst = *src > > > unless there is a compelling reason not to. > > > > Because it's not very clear? :-) I'd much prefer my array-of-things > > copies to be explicit. > > Eh? 'struct foo *src, *dst; *dst = *src' is pretty bog-standard C. That > isn't really all that obtuse. the thread has probably forked causing people to miss the explanation that Bruce gave: quite often the function is called by casting arbitrary pointers into 'struct foo *', so the compiler's expectations about alignment do not necessarily match the user's lies. Unfortunately we are building kernels with many compiler checks disabled, so there is a fair chance that the compiler will not detect such invalid casts. Probably addresses are aligned to 2-byte boundaries, but certainly not on a 4-byte, which means that a safe copy might require 3 instructions, even though a compiler could otherwise decide to align all non-packed 'struct foo' to a 4- or 8-byte boundary and possibly do the copy with 2 or even 1 instruction. I would also suggest to try the code i posted in response to bruce so you can check how good or bad are the various solutions on different architectures or CPUs, and see if there is a reasonable compromise. cheers luigi > > Also, the optimisation and compiler silliness may not be THAT obvious > > on intel (except when you're luigi and using netmap) but I can't help > > but wonder whether the same does hold for MIPS/ARM. Getting it wrong > > there will lead to some very very poor performing code. > > Don't you think there's a really good chance the compiler knows how to copy a > structure appropriately for each architecture already? > > -- > John Baldwin > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-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 Fri Aug 24 01:08:38 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 13056106566B; Fri, 24 Aug 2012 01:08:38 +0000 (UTC) (envelope-from bde@FreeBSD.org) Received: from ref10-i386.freebsd.org (unknown [IPv6:2001:4f8:fff6::5e]) by mx1.freebsd.org (Postfix) with ESMTP id EF9AD8FC14; Fri, 24 Aug 2012 01:08:37 +0000 (UTC) Received: from ref10-i386.freebsd.org (localhost [127.0.0.1]) by ref10-i386.freebsd.org (8.14.5/8.14.5) with ESMTP id q7O18bCU009633; Fri, 24 Aug 2012 01:08:37 GMT (envelope-from bde@ref10-i386.freebsd.org) Received: (from bde@localhost) by ref10-i386.freebsd.org (8.14.5/8.14.5/Submit) id q7O18bej009632; Fri, 24 Aug 2012 01:08:37 GMT (envelope-from bde) Date: Fri, 24 Aug 2012 01:08:37 GMT From: Bruce Evans Message-Id: <201208240108.q7O18bej009632@ref10-i386.freebsd.org> To: jhb@FreeBSD.org, rizzo@iet.unipi.it In-Reply-To: <20120822215244.GC67796@onelab2.iet.unipi.it> Cc: freebsd-hackers@FreeBSD.org, adrian@FreeBSD.org, mitya@cabletv.dp.ua, wojtek@wojtek.tensor.gdynia.pl, freebsd-net@FreeBSD.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Aug 2012 01:08:38 -0000 luigi wrote: > On Wed, Aug 22, 2012 at 03:21:06PM -0400, John Baldwin wrote: > > On Wednesday, August 22, 2012 2:54:07 pm Adrian Chadd wrote: > > > On 22 August 2012 05:02, John Baldwin wrote: > > > > On Tuesday, August 21, 2012 12:34:42 pm Adrian Chadd wrote: > > > >> Hi, > > > >> > > > >> What about just creating an ETHER_ADDR_COPY(dst, src) and putting that > > > >> in a relevant include file, then hide the ugliness there? Good for source code ugliness and bloat (not just in the macro). > > > >> The same benefits will likely appear when copying wifi MAC addresses > > > >> to/from headers. Why stop there? Change all assignments to use the ASSIGN() macro. The compiler doesn't understand assignment, but we do ;-). > > > >> Thanks, I'm glad someone noticed this. > > > > > > > > I doubt we even _need_ the ugliness. We should just use *dst = *src > > > > unless there is a compelling reason not to. > > > > > > Because it's not very clear? :-) I'd much prefer my array-of-things > > > copies to be explicit. > > > > Eh? 'struct foo *src, *dst; *dst = *src' is pretty bog-standard C. That > > isn't really all that obtuse. (Builtin) memcpy is better for this in general (no sarcasm now). It reduces to a struct copy if the object being copy is a struct, and is not limited to structs. However, ethernet address types are now fully pessimized, so compilers are almost forced to assume that they are fully misaligned. From net/ethernet.h: % /* % * Structure of a 10Mb/s Ethernet header. % */ Wow, 10Mb/s. % struct ether_header { % u_char ether_dhost[ETHER_ADDR_LEN]; % u_char ether_shost[ETHER_ADDR_LEN]; % u_short ether_type; % } __packed; This used to be not quite guaranteed to be 16-bit aligned by the short in it. Perhaps it is still aligned in practice, But in 2006, it was fully pessimized by adding __packed without adding __aligned(2). This __packed prevents the struct being padded to a multiple of 32 bits in size on arm. It has the side effect of allowing the compiler to not add padding for alignment before instances of this struct, and allowing embedded short to be misaligned, so all accesses to this short might require 2 1-byte load/store instructions and more instructions to combine the bytes. On x86, the accesses can be a single load/store (or sometimes an arithmetic operation), with the hardware doing the combination, possibly more slowly than for aligned accesses. The pessimization is better on other arches. % /* % * Structure of a 48-bit Ethernet address. % */ % struct ether_addr { % u_char octet[ETHER_ADDR_LEN]; % } __packed; This was always just an array of bytes, so it was nevever required to have more than byte alignment. However, the compiler was permitted to add padding before and after it to align it and the thing after it. __packed on it may prevent this. I hope that it actually takes a __packed on the containing struct or on the struct member with this type to prevent external padding, but __packed on everything may be needed anyway for __packed on this to have much effect. An ETHER_ADDR_COPY() macro can only do worse than the compiler here, since the object is nothing more than an array of bytes after forgetting the extra packing info that may be known to the compiler. On x86, the macro can use 2 possibly-misaligned load/stores, but so can the compiler, or the macro can use a dynamic comparison of the address to find the alignment point and then do 1, 2 or 3 aligned load/store pairs, but so can the compiler, or the macro can use "rep movsb", but so can the compiler... The best choice depends on CFLAGS (a static test that is easiest for the compiler) or on the CPU. For a complete implementation, the macro must of course patch the instructions used to best suit the current CPU. This would be a lot of work for an unimportant (~0.1% max) optimization. On non-x86 or any arch with strict alignment requirements, the only obviously correct implementions of the macro are 6 1-byte load/store pairs, or memcpy(), or bcopy(). The compiler can easily beat all of these. > the thread has probably forked causing people to miss the explanation > that Bruce gave: quite often the function is called by casting > arbitrary pointers into 'struct foo *', so the compiler's expectations > about alignment do not necessarily match the user's lies. Except for struct ether_addr, the cast would actually reduce alignment (unless the compiler is smart enough to not do it literally). > Unfortunately we are building kernels with many compiler checks > disabled, so there is a fair chance that the compiler will not > detect such invalid casts. Er, we check more in the kernel than almost everywhere else. > Probably addresses are aligned to 2-byte boundaries, but certainly > not on a 4-byte, which means that a safe copy might require 3 > instructions, even though a compiler could otherwise decide to align > all non-packed 'struct foo' to a 4- or 8-byte boundary and possibly > do the copy with 2 or even 1 instruction. The code actually asks for 1-byte alignment. From if_ethersubr.c: % int % ether_output(struct ifnet *ifp, struct mbuf *m, % struct sockaddr *dst, struct route *ro) % { % short type; % int error = 0, hdrcmplt = 0; % u_char esrc[ETHER_ADDR_LEN], edst[ETHER_ADDR_LEN]; This asks for raw byte arrays. gcc tends to align even arrays of char more than asked for but the code asks for minimal alignment. % struct llentry *lle = NULL; % struct rtentry *rt0 = NULL; % struct ether_header *eh; This points into an array of data. Such pointers may lose extra alignment info that may be present in the original type. % struct pf_mtag *t; % int loop_copy = 1; % int hlen; /* link layer header length */ Another pessimization technique used in this code is to initialize many variables in their declarations, despite unbroken versions of style(9) forbidding this. Out of order execution and x86 speed hides the slowness from this about as well as it hides the slowness from extra memcpy()'s. (gcc likes to do all of these inititializations "early" in program order, but with out of order execution there is no strict order and you can't do much better by delaying or avoiding the initializations.) Bruce From owner-freebsd-net@FreeBSD.ORG Fri Aug 24 12:40:03 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9D9CA106566C for ; Fri, 24 Aug 2012 12:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7D31E8FC12 for ; Fri, 24 Aug 2012 12:40:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q7OCe3LH014078 for ; Fri, 24 Aug 2012 12:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q7OCe3CY014077; Fri, 24 Aug 2012 12:40:03 GMT (envelope-from gnats) Date: Fri, 24 Aug 2012 12:40:03 GMT Message-Id: <201208241240.q7OCe3CY014077@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Theodor-Iulian Ciobanu Cc: Subject: Re: kern/157418: [em] em driver lockup during boot on Supermicro X9SCM-F X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Theodor-Iulian Ciobanu List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 12:40:03 -0000 The following reply was made to PR kern/157418; it has been noted by GNATS. From: Theodor-Iulian Ciobanu To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/157418: [em] em driver lockup during boot on Supermicro X9SCM-F Date: Fri, 24 Aug 2012 15:37:39 +0300 Hello, I've stumbled upon this problem while deploying a custom kernel for an Optiplex 990 with Intel 82579LM onboard. I then thought of testing the driver available from intel.com, as it's newer than the one in src (I'm using 9.0-p4, which has version 7.2.3 of the driver, download center provides em-7.2.4), but compilation fails with two errors. While I was able to find a fix for the first one here: http://lists.freebsd.org/pipermail/freebsd-current/2011-March/023529.html I wasn't able to find anything for the second: if_em.c: In function 'em_enable_wakeup': if_em.c:4769: warning: implicit declaration of function 'e1000_disable_gig_wol_ich8lan' if_em.c:4769: warning: nested extern declaration of 'e1000_disable_gig_wol_ich8lan' [-Wnested-externs] *** Error code 1 That function is provided by e1000_ich8lan.c which the download is missing, but I don't know if it's ok to just copy it from /usr/src. As I have no idea if this version of the driver will actually fix my problem, this is where I stopped. If anyone can help me out with this, I'm willing to test patches to get the issue fixed. Thank you and regards, -- Theo From owner-freebsd-net@FreeBSD.ORG Sat Aug 25 04:12:39 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D360E106564A for ; Sat, 25 Aug 2012 04:12:39 +0000 (UTC) (envelope-from anshukla@juniper.net) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by mx1.freebsd.org (Postfix) with ESMTP id 7F8308FC12 for ; Sat, 25 Aug 2012 04:12:39 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUDhQsdHZod7srxXKiARYD5x5L5xlpoKh@postini.com; Fri, 24 Aug 2012 21:12:39 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 24 Aug 2012 21:11:48 -0700 From: Anuranjan Shukla To: "freebsd-net@freebsd.org" Date: Fri, 24 Aug 2012 21:11:45 -0700 Thread-Topic: Proposal for changes to network device drivers and network stack (RFC) Thread-Index: Ac2Cd76xUaKMoSnfRb6WxYbFKGyXpA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Proposal for changes to network device drivers and network stack (RFC) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Aug 2012 04:12:39 -0000 At Juniper Networks, we've been using FreeBSD to build JUNOS (Juniper's network operating system). So far the additions and changes to the functionality were made inline, making the task of upgrading to new versions of FreeBSD progressively difficult. We've been looking at JUNOS to see if we can build it off of a clean FreeBSD base rather than making changes to the OS inline. As part of that work, we've come up with a few expansive change proposals to FreeBSD kernel that will make this task possible for us, and hopefully also contribute something of interest to the community. If the community is in agreement with these, we'd like to contribute/commit them to FreeBSD. This is a proposal and an RFC. The actual nomenclature is open to ideas (naming etc). From Juniper, Marcel (marcel@freebsd.org) will be attending the upcoming DevSummit at Cambridge. He's indicated that interested folks are welcome to chat with him about this stuff during the summit. The changes we propose are (the code/diffs etc are indicated at the end of this email): - Network Device Drivers - Building FreeBSD kernel without network stack, network stack as a module - Changes to mbuf and socket structures (minor member additions) Network Device Drivers: ----------------------- As we indicated during DevSummit 2012, JUNOS extended the interface functionality in a big way to support logical interfaces, interface hierarchies and scaling in general. Not surprisingly this resulted in changing the drivers to use our custom interface structure(s). A simple way to resolve this without impacting the rest of the large codebase is to avoid directly accessing (get/set) the ifnet structure from the drivers. Using get/set functions to update the functionality would make the driver more 'flexible' for the network stack to work with in situations where the stack wants to extend the interface functionality. For eg, em_start_locked(struct ifnet *ifp, struct tx_ring *txr) { - struct adapter *adapter =3D ifp->if_softc; + struct adapter *adapter =3D if_getsoftc(ifp); struct mbuf *m_head; =20 EM_TX_LOCK_ASSERT(txr); =20 - if ((ifp->if_drv_flags & (IFF_DRV_RUNNING|IFF_DRV_OACTIVE)) !=3D + if ((if_getdrvflags(ifp) & (IFF_DRV_RUNNING|IFF_DRV_OACTIVE)) !=3D IFF_DRV_RUNNING) return; =20 if (!adapter->link_active) return; =20 - while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) { + while (!if_sendq_empty(ifp)) { /* Call cleanup if number of TX descriptors low */ if (txr->tx_avail <=3D EM_TX_CLEANUP_THRESHOLD) em_txeof(txr); if (txr->tx_avail < EM_MAX_SCATTER) { - ifp->if_drv_flags |=3D IFF_DRV_OACTIVE; + if_setdrvflagbits(ifp,IFF_DRV_OACTIVE, 0); break; } - IFQ_DRV_DEQUEUE(&ifp->if_snd, m_head); + m_head =3D if_dequeue(ifp); if (m_head =3D=3D NULL) break; /* @@ -1010,7 +1009,7 @@ em_start_locked(struct ifnet *ifp, struct tx_ring if (em_xmit(txr, &m_head)) { if (m_head =3D=3D NULL) break; - IFQ_DRV_PREPEND(&ifp->if_snd, m_head); + if_sendq_prepend(ifp, m_head); break; This allows Juniper to have its own interface structure(s) instead of ifnet, and still be able to use the driver without modification. Since the notion of ifnet is abstracted away, other users can also find this useful in plugging in functionality without having muck around in the driver code. The ifnet split/restructuring was discussed in DevSummit at BSDCan in May 2012. This change can also aid in that work. This change can be applied to drivers in a phased way. Clearly, it won't have any impact on drivers that haven't been changed. At Juniper we're planning on converting em,fxp and tsec. Are there any strong feelings on whether the phase-wise change is ok or not? Building FreeBSD without the network stack (network stack as a module) ---------------------------------------------------------------------- Today, not compiling networking stack related files in the kernel breaks the kernel build due to dependencies the OS has on the network stack (calling into functions in the network stack). Network stack module isn't there. We've added these in JUNOS. The benefits for us are obvious (we can load our own version of network stack if we desire!), but most likely this functionality will benefit others too. The detailed implementation is indicated later in this email. In short the changes are: - Load network stack as a module. For now via loader, not dynamically loaded. (Is there interest in dynamic loading?). - To facilitate calling network stack functionality from the generic kernel, a new interface has been defined with the kobj framework. - Some files and tunables needed to move to generic kernel areas (accept filters) - Generic socket code calls into network stack for interface and route related ioctls. Network stack now registers these ioctl groups - Other changes: uuid generation (register/query uuid sources), fib/sctp system calls (moved to network stack code, with system calls register dynamically). Changes to mbuf and socket structures -------------------------------------- A couple additions to these structures help JUNOS incorporate cool things like interface/route indices and logical routing. For us the diff today looks=20 something like: struct pkthdr { + uint32_t rcvidx; /* rcv interface index */ + uint32_t rnhidx; /* route or nexthop index */ struct ifnet *rcvif; /* rcv interface */ struct socket { int so_fibnum; /* routing domain for this socket */ uint32_t so_user_cookie; + u_int so_oqueue; /* manage send prioritizing based on application needs */ + u_short so_lrid; /* logical routing */ }; A question for the community is if it's there're strong objections to adding fields to these structures. If so, do we have another way or a suggestion to consider? For a detailed look, diffs can be found at: http://people.freebsd.org/~marcel/Juniper/ddi-mbuf-socket.diff http://people.freebsd.org/~marcel/Juniper/netstack.diff These will provide a good idea of the changes. They're not in final shape yet. From owner-freebsd-net@FreeBSD.ORG Sat Aug 25 07:54:18 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61FA7106564A; Sat, 25 Aug 2012 07:54:18 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from mx1.giulioferro.ch (mx1.giulioferro.ch [217.150.252.208]) by mx1.freebsd.org (Postfix) with ESMTP id D56618FC19; Sat, 25 Aug 2012 07:54:17 +0000 (UTC) Received: from mailscan.giulioferro.ch (unknown [192.168.115.2]) by mx1.giulioferro.ch (Postfix) with ESMTP id 5B06371D36; Sat, 25 Aug 2012 09:54:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at example.com Received: from mx1.giulioferro.ch ([192.168.114.4]) by mailscan.giulioferro.ch (mailscan.giulioferro.ch [192.168.115.2]) (amavisd-new, port 10024) with ESMTP id nVqSFy_6bggf; Sat, 25 Aug 2012 09:54:09 +0200 (CEST) Received: from mail.zirakzigil.org (net-93-70-48-129.cust.dsl.vodafone.it [93.70.48.129]) by mx1.giulioferro.ch (Postfix) with ESMTP id 57CDA71D1E; Sat, 25 Aug 2012 09:54:09 +0200 (CEST) Received: from ext.zirakzigil.org (unknown [192.168.1.2]) by mail.zirakzigil.org (Postfix) with ESMTP id A248D19BB24; Sat, 25 Aug 2012 09:49:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at zirakzigil.org Received: from mail.zirakzigil.org ([192.168.1.2]) by ext.zirakzigil.org (ext.zirakzigil.org [192.168.1.2]) (amavisd-new, port 10024) with ESMTP id mZ6KocGfew8L; Sat, 25 Aug 2012 09:49:53 +0200 (CEST) Received: from [192.168.229.48] (ext [192.168.1.2]) (Authenticated sender: auryn@zirakzigil.org) by mail.zirakzigil.org (Postfix) with ESMTPA id 31D5D19BB1E; Sat, 25 Aug 2012 09:49:53 +0200 (CEST) Message-ID: <503884A0.50708@zirakzigil.org> Date: Sat, 25 Aug 2012 09:54:08 +0200 From: Giulio Ferro User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-net@freebsd.org References: <5033FB17.7020600@zirakzigil.org> In-Reply-To: <5033FB17.7020600@zirakzigil.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Problem with link aggregation + sshd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Aug 2012 07:54:18 -0000 No answer, so it seems that link aggregation doesn't really work in freebsd, this may help others with the same problem... I reverted back to one link for management and one for service, and ssh works as it should... On 08/21/2012 11:18 PM, Giulio Ferro wrote: > Scenario : freebsd 9 stable (yesterday) amd64 on HP server with 4 nic > (igb) > > 1 nic is connected standalone to the management switch, the 3 other nics > are connected to a switch configured for aggregation. > > If I configure the first nic (igb0) there is no problem, I can operate > as I normally do and sshd functions normally. > > The problems start when I configure the 3 other nics for aggregation: > > in /etc/rc.conf > ... > ifconfig_igb1="up" > ifconfig_igb2="up" > ifconfig_igb3="up" > > cloned_interfaces=lagg0 > ifconfig_lagg0="laggproto lacp laggport igb1 laggport igb2 laggport > igb3 192.168.12.7/24" > ... > > I restart the server and the aggregation seems to work correctly, in > fact ifconfig returns the correct lagg0 interface with the aggregated > links, the correct protocol (lacp) and the correct ip address and the > status is active. I can ping other IPs on the aggregated link. > > Also the other (standalone) link seems to work correctly. I can ping > that address from other machines, and I can ping other IPs from that > server. > > DNS lookups work ok too I can also use telnet to connect to pop3 > servers so there seems to be no problem on the network stack. > > But if I try to connect to the sshd service on that server, it hangs > indefinitely. On the server I find two sshd processes: > /usr/sbin/sshd > /usr/sbin/sshd -R > > There is no message in the logs. > > If I try to kill sshd (/etc/rc.d/sshd stop) I can't. it just stays there > forever waiting for the pid to die (it never does) > > Even ssh client doesn't seem to work. In fact, if I try to connect to > another server, the ssh client may start to work correctly, then soon > or later it just hangs there forever, and I can't kill it with ctrl-c. > > No firewall is configured, there is nothing else working on this server. > > Thanks for any suggestions... > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Aug 25 11:18:34 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E8654106566B for ; Sat, 25 Aug 2012 11:18:34 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 6DB6A8FC18 for ; Sat, 25 Aug 2012 11:18:33 +0000 (UTC) Received: by wibhr14 with SMTP id hr14so1363557wib.13 for ; Sat, 25 Aug 2012 04:18:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=pHizajip9b8H7LXvyhSQZ5W+IBj07Q6CDfw7knNCQCA=; b=FIRVfHBHCDuxt9icnPM4+8gtDQL2ZVaZwvjgUnjbRh5qwzMNUal30ppZAQPGwEl+MR IIMCt2HW6fqxIcfXuGgUc4BLaJtjddQ5ExYw3dNU6WoT+h7mOCxOVwNnZSJvKeFUI2Wl TthFBBrHP2JefBDlNzYOoO1X5K98oHwRz42ILkDa7VE5a66VWbHTwx2eAWTKkTa7zy0N 7X//k0d86RrKgJyB7FR/2d+gUA0nkQ/P3QdsXJQ2J2pDiXTzUzT/btDm0L4qYOkq34uR Wom93Tt//cKGkz6HKbqe4a3w7nCTDjRiZhY6KUHG4Dl+8Aaoea2Bat8vrhGax9yysv/Q wl0Q== Received: by 10.217.1.79 with SMTP id m57mr3926630wes.121.1345893512660; Sat, 25 Aug 2012 04:18:32 -0700 (PDT) Received: from [192.168.0.10] (did75-17-88-165-130-96.fbx.proxad.net. [88.165.130.96]) by mx.google.com with ESMTPS id h9sm2563564wiz.1.2012.08.25.04.18.30 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 25 Aug 2012 04:18:31 -0700 (PDT) References: <5033FB17.7020600@zirakzigil.org> <503884A0.50708@zirakzigil.org> In-Reply-To: <503884A0.50708@zirakzigil.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9A405) From: Damien Fleuriot Date: Sat, 25 Aug 2012 13:18:27 +0200 To: Giulio Ferro X-Gm-Message-State: ALoCoQnFAnZbQ2ugVyZ8cf90JHyW/NHe7usKqM9TeZsiZgpFKZsNwMpEiMssoiITFEi6hOGfoKM/ Cc: "freebsd-net@freebsd.org" , "freebsd-stable@freebsd.org" Subject: Re: Problem with link aggregation + sshd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Aug 2012 11:18:35 -0000 I'll get back to you regarding link aggregation when I'm done with groceries= . We use it here in production and it works flawlessly. On 25 Aug 2012, at 09:54, Giulio Ferro wrote: > No answer, so it seems that link aggregation doesn't really work in freebs= d, > this may help others with the same problem... >=20 > I reverted back to one link for management and one for service, and ssh > works as it should... >=20 >=20 > On 08/21/2012 11:18 PM, Giulio Ferro wrote: >> Scenario : freebsd 9 stable (yesterday) amd64 on HP server with 4 nic (ig= b) >>=20 >> 1 nic is connected standalone to the management switch, the 3 other nics >> are connected to a switch configured for aggregation. >>=20 >> If I configure the first nic (igb0) there is no problem, I can operate >> as I normally do and sshd functions normally. >>=20 >> The problems start when I configure the 3 other nics for aggregation: >>=20 >> in /etc/rc.conf >> ... >> ifconfig_igb1=3D"up" >> ifconfig_igb2=3D"up" >> ifconfig_igb3=3D"up" >>=20 >> cloned_interfaces=3Dlagg0 >> ifconfig_lagg0=3D"laggproto lacp laggport igb1 laggport igb2 laggport igb= 3 192.168.12.7/24" >> ... >>=20 >> I restart the server and the aggregation seems to work correctly, in >> fact ifconfig returns the correct lagg0 interface with the aggregated >> links, the correct protocol (lacp) and the correct ip address and the >> status is active. I can ping other IPs on the aggregated link. >>=20 >> Also the other (standalone) link seems to work correctly. I can ping >> that address from other machines, and I can ping other IPs from that >> server. >>=20 >> DNS lookups work ok too I can also use telnet to connect to pop3 >> servers so there seems to be no problem on the network stack. >>=20 >> But if I try to connect to the sshd service on that server, it hangs >> indefinitely. On the server I find two sshd processes: >> /usr/sbin/sshd >> /usr/sbin/sshd -R >>=20 >> There is no message in the logs. >>=20 >> If I try to kill sshd (/etc/rc.d/sshd stop) I can't. it just stays there >> forever waiting for the pid to die (it never does) >>=20 >> Even ssh client doesn't seem to work. In fact, if I try to connect to >> another server, the ssh client may start to work correctly, then soon >> or later it just hangs there forever, and I can't kill it with ctrl-c. >>=20 >> No firewall is configured, there is nothing else working on this server. >>=20 >> Thanks for any suggestions... >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"= >=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Aug 25 11:22:11 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF6E41065691 for ; Sat, 25 Aug 2012 11:22:11 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 2FF788FC1C for ; Sat, 25 Aug 2012 11:22:11 +0000 (UTC) Received: by wicr5 with SMTP id r5so1442478wic.13 for ; Sat, 25 Aug 2012 04:22:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=PfHMycg90xrBC0l5pNdn7VJGSuH0WcFh4u04IZ2PTWw=; b=OZHjFH+pvvrlSyojtUCNJmSPqYiI5nvwZv9Hka4DhsuhUHniGAFcpSkuYk12AUfsjE XRIWCVZ68Q9KncryLnlhwmWc7MBAtu2339H+sUN8e/Yvz1BIUnhSw+y5p8BemmjmZ8L9 sIUfj8mFLUi21VReb7CKwOcYYP65pwolOp3f4PgudYZDst+4whtUtLmUtoZyb7jmMSpX XZ0Z2KDCK5DbKubbD/BSLDTWpw8MFX/YAhxZTBSWH7UqazJtJeobjVivix4l/VeJE6XQ rE7VbjfDrNtVk3DEAZmz2qkqRvLLRw/li16Pa3Y8PVYoHSp1f35cwJNvbWTzWQXe3/D8 x3Jg== Received: by 10.180.104.197 with SMTP id gg5mr11997865wib.9.1345893730240; Sat, 25 Aug 2012 04:22:10 -0700 (PDT) Received: from [192.168.0.10] (did75-17-88-165-130-96.fbx.proxad.net. [88.165.130.96]) by mx.google.com with ESMTPS id eu4sm2573261wib.2.2012.08.25.04.22.08 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 25 Aug 2012 04:22:09 -0700 (PDT) References: <5033FB17.7020600@zirakzigil.org> <503884A0.50708@zirakzigil.org> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9A405) From: Damien Fleuriot Date: Sat, 25 Aug 2012 13:22:06 +0200 To: Damien Fleuriot X-Gm-Message-State: ALoCoQkpC/iYwOsusUd8jVqQt5sbrz2TuGsuKl3jpZ/HXg3Y0nSRFNn2NvtrpbXe1UDtS6NFxjGz Cc: "freebsd-net@freebsd.org" , Giulio Ferro , "freebsd-stable@freebsd.org" Subject: Re: Problem with link aggregation + sshd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Aug 2012 11:22:11 -0000 In the meantime kindly post: Ifconfig for your igb0 Netstat -rn Netstat -aln | grep 22 On 25 Aug 2012, at 13:18, Damien Fleuriot wrote: > I'll get back to you regarding link aggregation when I'm done with groceri= es. >=20 > We use it here in production and it works flawlessly. >=20 >=20 >=20 > On 25 Aug 2012, at 09:54, Giulio Ferro wrote: >=20 >> No answer, so it seems that link aggregation doesn't really work in freeb= sd, >> this may help others with the same problem... >>=20 >> I reverted back to one link for management and one for service, and ssh >> works as it should... >>=20 >>=20 >> On 08/21/2012 11:18 PM, Giulio Ferro wrote: >>> Scenario : freebsd 9 stable (yesterday) amd64 on HP server with 4 nic (i= gb) >>>=20 >>> 1 nic is connected standalone to the management switch, the 3 other nics= >>> are connected to a switch configured for aggregation. >>>=20 >>> If I configure the first nic (igb0) there is no problem, I can operate >>> as I normally do and sshd functions normally. >>>=20 >>> The problems start when I configure the 3 other nics for aggregation: >>>=20 >>> in /etc/rc.conf >>> ... >>> ifconfig_igb1=3D"up" >>> ifconfig_igb2=3D"up" >>> ifconfig_igb3=3D"up" >>>=20 >>> cloned_interfaces=3Dlagg0 >>> ifconfig_lagg0=3D"laggproto lacp laggport igb1 laggport igb2 laggport ig= b3 192.168.12.7/24" >>> ... >>>=20 >>> I restart the server and the aggregation seems to work correctly, in >>> fact ifconfig returns the correct lagg0 interface with the aggregated >>> links, the correct protocol (lacp) and the correct ip address and the >>> status is active. I can ping other IPs on the aggregated link. >>>=20 >>> Also the other (standalone) link seems to work correctly. I can ping >>> that address from other machines, and I can ping other IPs from that >>> server. >>>=20 >>> DNS lookups work ok too I can also use telnet to connect to pop3 >>> servers so there seems to be no problem on the network stack. >>>=20 >>> But if I try to connect to the sshd service on that server, it hangs >>> indefinitely. On the server I find two sshd processes: >>> /usr/sbin/sshd >>> /usr/sbin/sshd -R >>>=20 >>> There is no message in the logs. >>>=20 >>> If I try to kill sshd (/etc/rc.d/sshd stop) I can't. it just stays there= >>> forever waiting for the pid to die (it never does) >>>=20 >>> Even ssh client doesn't seem to work. In fact, if I try to connect to >>> another server, the ssh client may start to work correctly, then soon >>> or later it just hangs there forever, and I can't kill it with ctrl-c. >>>=20 >>> No firewall is configured, there is nothing else working on this server.= >>>=20 >>> Thanks for any suggestions... >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org= " >>=20 >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"= From owner-freebsd-net@FreeBSD.ORG Sat Aug 25 23:04:04 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EE74E1065781 for ; Sat, 25 Aug 2012 23:04:04 +0000 (UTC) (envelope-from djmitche@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 85B7B8FC1F for ; Sat, 25 Aug 2012 23:04:04 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so2205337wgb.31 for ; Sat, 25 Aug 2012 16:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=0Zzfj/dvDcN8oSbDmw8zQX2cKku3jmcS2pfKXDaAGt0=; b=JltkwtzeeK+GUxv2X+m80U9TctPg5yGQzfL83h0dEJ2x0PWB8GpslrMPc1JivjWX4C Sq/iq5yvzhdfioUy+ODpmsQQB0K43N7iD7ZdpG8ZEMS9rdqtMNYxdz/HeO1kipkr8xLE /djcfRr+PjhZQM9PeNtq07ceU3hhrcuTg+em1FU0v0qjX0Xfg7IO5wqnX7l3f7i5/uTK TENPv/40xezAPKa33tbD/ACFD9IZ+ilMsbYEXIBOoDl59UAdWTYOWjdUq8ppA1u7Mack cEwTboATjWQNEEkf4mDSCRdsi7WQHBKwOlKHZeK9H/NNG5eGhBTW2EK0lM51IPOsvUgZ qaeQ== MIME-Version: 1.0 Received: by 10.180.81.66 with SMTP id y2mr14591173wix.22.1345935843474; Sat, 25 Aug 2012 16:04:03 -0700 (PDT) Sender: djmitche@gmail.com Received: by 10.223.4.215 with HTTP; Sat, 25 Aug 2012 16:04:03 -0700 (PDT) Date: Sat, 25 Aug 2012 19:04:03 -0400 X-Google-Sender-Auth: HULdO27f-H5VgNUh7zpfh9vRb5Y Message-ID: From: "Dustin J. Mitchell" To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: bridging VLAN interfaces and STP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Aug 2012 23:04:05 -0000 Hey folks. I'm trying to set up a system with one 802.1q-tagged upstream, and a few untagged interfaces. So I'd like to bridge the vlan(4) interfaces on vr1 to specific other interfaces. hilbert ~ # ifconfig bridge10 bridge10: flags=8843 metric 0 mtu 1500 ether 02:f4:a1:63:5a:0a inet 172.16.1.21 netmask 0xffffff00 broadcast 172.16.1.255 nd6 options=21 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: vr3 flags=143 ifmaxaddr 0 port 4 priority 128 path cost 55 member: vr2 flags=143 ifmaxaddr 0 port 3 priority 128 path cost 55 member: vr1.10 flags=143 ifmaxaddr 0 port 8 priority 128 path cost 200000 Now, if I try to enable STP on these: hilbert ~ # ifconfig bridge10 stp vr2 hilbert ~ # ifconfig bridge10 stp vr3 hilbert ~ # ifconfig bridge10 stp vr1.20 ifconfig: unable to get bridge flags: No such file or directory and, indeed, the first two succeeded and the third did not: ... member: vr3 flags=147 ifmaxaddr 0 port 4 priority 128 path cost 55 proto rstp role disabled state discarding member: vr2 flags=147 ifmaxaddr 0 port 3 priority 128 path cost 55 proto rstp role disabled state discarding member: vr1.10 flags=143 ifmaxaddr 0 port 8 priority 128 path cost 200000 I tried a bridge interface with vlan'd members only (vr2.10 and vr1.10, to be exact), and still saw this error. So it looks like you can't run STP on vlan interfaces? Can someone confirm? Or is there a secret sysctl to enable this? I'll admit this is a minor point - I'll just leave STP off and not make loops - but it'd be nice to do the right thing :) Dustin