From owner-freebsd-net@FreeBSD.ORG Sun May 19 02:10:02 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5FD35150 for ; Sun, 19 May 2013 02:10:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 360FBECE for ; Sun, 19 May 2013 02:10:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4J2A1uk070781 for ; Sun, 19 May 2013 02:10:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4J2A1VG070780; Sun, 19 May 2013 02:10:01 GMT (envelope-from gnats) Date: Sun, 19 May 2013 02:10:01 GMT Message-Id: <201305190210.r4J2A1VG070780@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: PseudoCylon Subject: Re: kern/178612: [run] kernel panic due the problems with run driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: PseudoCylon List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2013 02:10:02 -0000 The following reply was made to PR kern/178612; it has been noted by GNATS. From: PseudoCylon To: bug-followup@FreeBSD.org, core.dumped.sm@gmail.com Cc: Subject: Re: kern/178612: [run] kernel panic due the problems with run driver Date: Sat, 18 May 2013 20:01:54 -0600 This must be the same bug as kern/153938 http://www.freebsd.org/cgi/query-pr.cgi?pr=153938&cat= and patched at rev. 218676 http://svnweb.freebsd.org/base?view=revision&revision=218676 Please upgrade to 9.1-RELEASE or backport. AK From owner-freebsd-net@FreeBSD.ORG Mon May 20 03:31:22 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E6D78608; Mon, 20 May 2013 03:31:22 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id C0275989; Mon, 20 May 2013 03:31:22 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4K3VMu3083210; Mon, 20 May 2013 03:31:22 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4K3VMm2083209; Mon, 20 May 2013 03:31:22 GMT (envelope-from linimon) Date: Mon, 20 May 2013 03:31:22 GMT Message-Id: <201305200331.r4K3VMm2083209@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/178079: [tcp] Switching TCP CC algorithm panics on sparc64 with a complaint from the MMU X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 03:31:23 -0000 Old Synopsis: Switching TCP CC algorithm panics on sparc64 with a complaint from the MMU New Synopsis: [tcp] Switching TCP CC algorithm panics on sparc64 with a complaint from the MMU Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 20 03:30:59 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=178079 From owner-freebsd-net@FreeBSD.ORG Mon May 20 06:35:25 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7717EDD; Mon, 20 May 2013 06:35:25 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 503AEF18; Mon, 20 May 2013 06:35:25 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4K6ZP2s018959; Mon, 20 May 2013 06:35:25 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4K6ZPbG018958; Mon, 20 May 2013 06:35:25 GMT (envelope-from linimon) Date: Mon, 20 May 2013 06:35:25 GMT Message-Id: <201305200635.r4K6ZPbG018958@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/178782: [ixgbe] 82599EB SFP does not work with passthrough under KVM. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 06:35:25 -0000 Synopsis: [ixgbe] 82599EB SFP does not work with passthrough under KVM. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 20 06:35:14 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=178782 From owner-freebsd-net@FreeBSD.ORG Mon May 20 06:59:34 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4D26C420 for ; Mon, 20 May 2013 06:59:34 +0000 (UTC) (envelope-from havenster@gmail.com) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by mx1.freebsd.org (Postfix) with ESMTP id AFD27FC9 for ; Mon, 20 May 2013 06:59:33 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id eg20so3380512lab.41 for ; Sun, 19 May 2013 23:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jJjX0pPTIWNGrwvZF3aRFM0N36tlfPlWYnsQormj5ZQ=; b=ufaNNkNZ5WjG/nXFY3e0qOvu65QJwpsJbKjlI4GuBGQ8DflLPXe5sfes4uhq0vBy4s LAYKqC+ncxINMS0YMjGBlarS7fjBWGbPcLrXrqF/DwCALoWfAOZ9tOBW5ks5rPdB5XB5 UsACcDekus3a9IjrNBIzNOTeHYVwbFntBHNPikCLdSjnLc9tF+fBndNeqBkgYwtsKIcE JocQkxInoDIK5Bub4PgEkNhXJBQjvkg3ybUdkVcgGDsDqAD7x3vLavfesTPgHMLzrXcR VqKnIEVxnfk10GAnz+EFcKq1pOxjdhRgTlOk3ejQalptdOLttSk+ti+Q4O07zK22DfUk duJA== MIME-Version: 1.0 X-Received: by 10.152.30.103 with SMTP id r7mr5958680lah.25.1369033172468; Sun, 19 May 2013 23:59:32 -0700 (PDT) Received: by 10.112.159.166 with HTTP; Sun, 19 May 2013 23:59:32 -0700 (PDT) In-Reply-To: <201305161156.r4GBu0HQ018200@vps1.elischer.org> References: <201305161156.r4GBu0HQ018200@vps1.elischer.org> Date: Sun, 19 May 2013 23:59:32 -0700 Message-ID: Subject: Re: more FIBs patch for review From: Haven Hash To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 06:59:34 -0000 Was m_fibnum being defined to m_hdr.mh_nextpkt intended? (it doesn't appear to be used here and it seemed an odd mapping to me). Thanks, On Thu, May 16, 2013 at 4:56 AM, Julian Elischer wrote: > Index: sys/conf/NOTES > =================================================================== > --- sys/conf/NOTES (revision 250696) > +++ sys/conf/NOTES (working copy) > @@ -571,7 +571,8 @@ > options INET #Internet communications protocols > options INET6 #IPv6 communications protocols > > -options ROUTETABLES=2 # max 16. 1 is back compatible. > +options ROUTETABLES=2 # allocated fibs up to 65536. > default is 1. > + # but that would be a bad idea as > they are large. > > options TCP_OFFLOAD # TCP offload support. > > Index: sys/net/route.c > =================================================================== > --- sys/net/route.c (revision 250696) > +++ sys/net/route.c (working copy) > @@ -68,8 +68,7 @@ > > #include > > -/* We use 4 bits in the mbuf flags, thus we are limited to 16 FIBS. */ > -#define RT_MAXFIBS 16 > +#define RT_MAXFIBS UINT16_MAX > > /* Kernel config default option. */ > #ifdef ROUTETABLES > @@ -86,17 +85,10 @@ > #define RT_NUMFIBS 1 > #endif > > +/* This is read-only.. */ > u_int rt_numfibs = RT_NUMFIBS; > SYSCTL_UINT(_net, OID_AUTO, fibs, CTLFLAG_RD, &rt_numfibs, 0, ""); > -/* > - * Allow the boot code to allow LESS than RT_MAXFIBS to be used. > - * We can't do more because storage is statically allocated for now. > - * (for compatibility reasons.. this will change. When this changes, code > should > - * be refactored to protocol independent parts and protocol dependent > parts, > - * probably hanging of domain(9) specific storage to not need the full > - * fib * af RNH allocation etc. but allow tuning the number of tables per > - * address family). > - */ > +/* and this can be set too big but will be fixed before it is used */ > TUNABLE_INT("net.fibs", &rt_numfibs); > > /* > Index: sys/netinet6/ip6_output.c > =================================================================== > --- sys/netinet6/ip6_output.c (revision 250696) > +++ sys/netinet6/ip6_output.c (working copy) > @@ -1126,7 +1126,7 @@ > IP6STAT_INC(ip6s_odropped); > goto sendorfree; > } > - m->m_flags = m0->m_flags & M_COPYFLAGS; /* incl. > FIB */ > + m->m_flags = m0->m_flags & M_COPYFLAGS; > *mnext = m; > mnext = &m->m_nextpkt; > m->m_data += max_linkhdr; > @@ -1152,6 +1152,7 @@ > } > m_cat(m, m_frgpart); > m->m_pkthdr.len = len + hlen + sizeof(*ip6f); > + m->m_pkthdr.fibnum = m0->m_pkthdr.fibnum; > m->m_pkthdr.rcvif = NULL; > ip6f->ip6f_reserved = 0; > ip6f->ip6f_ident = id; > Index: sys/sys/mbuf.h > =================================================================== > --- sys/sys/mbuf.h (revision 250696) > +++ sys/sys/mbuf.h (working copy) > @@ -129,6 +129,8 @@ > u_int16_t vt_vtag; /* Ethernet 802.1p+q vlan tag */ > u_int16_t vt_nrecs; /* # of IGMPv3 records in this > chain */ > } PH_vt; > + u_int16_t fibnum; /* this packet should use this fib > */ > + u_int16_t pad2; /* align to 32 bits */ > SLIST_HEAD(packet_tags, m_tag) tags; /* list of packet tags */ > }; > #define ether_vtag PH_vt.vt_vtag > @@ -171,6 +173,7 @@ > #define m_type m_hdr.mh_type > #define m_flags m_hdr.mh_flags > #define m_nextpkt m_hdr.mh_nextpkt > +#define m_fibnum m_hdr.mh_nextpkt > #define m_act m_nextpkt > #define m_pkthdr M_dat.MH.MH_pkthdr > #define m_ext M_dat.MH.MH_dat.MH_ext > @@ -205,12 +208,6 @@ > #define M_FLOWID 0x00400000 /* deprecated: flowid is valid > */ > #define M_HASHTYPEBITS 0x0F000000 /* mask of bits holding flowid > hash type */ > > -/* > - * For RELENG_{6,7} steal these flags for limited multiple routing table > - * support. In RELENG_8 and beyond, use just one flag and a tag. > - */ > -#define M_FIB 0xF0000000 /* steal some bits to store fib > number. */ > - > #define M_NOTIFICATION M_PROTO5 /* SCTP notification */ > > /* > @@ -258,7 +255,7 @@ > */ > #define M_COPYFLAGS \ > > (M_PKTHDR|M_EOR|M_RDONLY|M_PROTOFLAGS|M_SKIP_FIREWALL|M_BCAST|M_MCAST|\ > - > M_FRAG|M_FIRSTFRAG|M_LASTFRAG|M_VLANTAG|M_PROMISC|M_FIB|M_HASHTYPEBITS) > + M_FRAG|M_FIRSTFRAG|M_LASTFRAG|M_VLANTAG|M_PROMISC|M_HASHTYPEBITS) > > /* > * External buffer types: identify ext_buf type. > @@ -1010,17 +1007,18 @@ > m_tag_locate(m, MTAG_ABI_COMPAT, type, start)); > } > > -/* XXX temporary FIB methods probably eventually use tags.*/ > -#define M_FIBSHIFT 28 > -#define M_FIBMASK 0x0F > +static int inline > +rt_m_getfib(struct mbuf *m) > +{ > + KASSERT(m->m_flags & M_EXT , ("attempt to set FIB on non header > mbuf")); > + return (m->m_pkthdr.fibnum); > +} > > -/* get the fib from an mbuf and if it is not set, return the default */ > -#define M_GETFIB(_m) \ > - ((((_m)->m_flags & M_FIB) >> M_FIBSHIFT) & M_FIBMASK) > +#define M_GETFIB(_m) rt_m_getfib(_m) > > #define M_SETFIB(_m, _fib) do { > \ > - _m->m_flags &= ~M_FIB; \ > - _m->m_flags |= (((_fib) << M_FIBSHIFT) & M_FIB); \ > + KASSERT((_m)->m_flags & M_EXT, ("No FIB on non header mbuf")); \ > + ((_m)->m_pkthdr.fibnum) = (_fib); \ > } while (0) > > #endif /* _KERNEL */ > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon May 20 07:46:49 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8F3EFFCD for ; Mon, 20 May 2013 07:46:49 +0000 (UTC) (envelope-from liujie@263.net) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 782A1199 for ; Mon, 20 May 2013 07:46:48 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UeKnw-0007Pi-2w for freebsd-net@freebsd.org; Mon, 20 May 2013 00:46:48 -0700 Date: Mon, 20 May 2013 00:46:48 -0700 (PDT) From: liujie To: freebsd-net@freebsd.org Message-ID: <1369036008085-5813346.post@n5.nabble.com> Subject: netmap bridge can tranmit big packet in line rate ? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 07:46:49 -0000 I tried netmap bridge to transmit 64-byte packets , the performance is well almost line rate.but when we increase the packet size, to performance dropped rapiddly, anyone have tried this situation ? or can we tune some parameters to improve the performance ? thanks. -- View this message in context: http://freebsd.1045724.n5.nabble.com/netmap-bridge-can-tranmit-big-packet-in-line-rate-tp5813346.html Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Mon May 20 11:06:50 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6E20B59D for ; Mon, 20 May 2013 11:06:50 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 5E964DB7 for ; Mon, 20 May 2013 11:06:50 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4KB6oIa082974 for ; Mon, 20 May 2013 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4KB6nGO082972 for freebsd-net@FreeBSD.org; Mon, 20 May 2013 11:06:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 20 May 2013 11:06:49 GMT Message-Id: <201305201106.r4KB6nGO082972@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 11:06:50 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/178782 net [ixgbe] 82599EB SFP does not work with passthrough und o kern/178612 net [run] kernel panic due the problems with run driver o kern/178472 net [ip6] [patch] make return code consistent with IPv4 co o kern/178116 net [ipfilter] [panic] Kernel panic: general protection fa o kern/178079 net [tcp] Switching TCP CC algorithm panics on sparc64 wit s kern/178071 net FreeBSD unable to recongize Kontron (Industrial Comput o kern/177905 net [xl] [panic] ifmedia_set when pluging CardBus LAN card o kern/177618 net [bridge] Problem with bridge firewall with trunk ports o kern/177417 net [ip6] Invalid protocol value in ipsec6_common_input_cb o kern/177402 net [igb] [pf] problem with ethernet driver igb + pf / alt o kern/177400 net [jme] JMC25x 1000baseT establishment issues o kern/177366 net [ieee80211] negative malloc(9) statistics for 80211nod f kern/177362 net [netinet] [patch] Wrong control used to return TOS o kern/177194 net [netgraph] Unnamed netgraph nodes for vlan interfaces o kern/177139 net [igb] igb drops ethernet ports 2 and 3 o kern/176884 net [re] re0 flapping up/down o kern/176671 net [epair] MAC address for epair device not unique o kern/176596 net [firewire] [ip6] Crash with IPv6 and Firewire o kern/176484 net [ipsec] [enc] [patch] panic: IPsec + enc(4); device na o kern/176446 net [netinet] [patch] Concurrency in ixgbe driving out-of- o kern/176420 net [kernel] [patch] incorrect errno for LOCAL_PEERCRED o kern/176419 net [kernel] [patch] socketpair support for LOCAL_PEERCRED o kern/176401 net [netgraph] page fault in netgraph o kern/176167 net [ipsec][lagg] using lagg and ipsec causes immediate pa o kern/176097 net [lagg] [patch] lagg/lacp broken when aggregated interf o kern/176027 net [em] [patch] flow control systcl consistency for em dr o kern/176026 net [tcp] [patch] TCP wrappers caused quite a lot of warni o bin/175974 net ppp(8): logic issue o kern/175864 net [re] Intel MB D510MO, onboard ethernet not working aft o kern/175852 net [amd64] [patch] in_cksum_hdr() behaves differently on o kern/175734 net no ethernet detected on system with EG20T PCH chipset o kern/175267 net [pf] [tap] pf + tap keep state problem o kern/175236 net [epair] [gif] epair and gif Devices On Bridge o kern/175182 net [panic] kernel panic on RADIX_MPATH when deleting rout o kern/175153 net [tcp] will there miss a FIN when do TSO? o kern/174959 net [net] [patch] rnh_walktree_from visits spurious nodes o kern/174958 net [net] [patch] rnh_walktree_from makes unreasonable ass o kern/174897 net [route] Interface routes are broken o kern/174851 net [bxe] [patch] UDP checksum offload is wrong in bxe dri o kern/174850 net [bxe] [patch] bxe driver does not receive multicasts o kern/174849 net [bxe] [patch] bxe driver can hang kernel when reset o kern/174822 net [tcp] Page fault in tcp_discardcb under high traffic o kern/174602 net [gif] [ipsec] traceroute issue on gif tunnel with ipse o kern/174535 net [tcp] TCP fast retransmit feature works strange o kern/173871 net [gif] process of 'ifconfig gif0 create hangs' when if_ o kern/173475 net [tun] tun(4) stays opened by PID after process is term o kern/173201 net [ixgbe] [patch] Missing / broken ixgbe sysctl's and tu o kern/173137 net [em] em(4) unable to run at gigabit with 9.1-RC2 o kern/173002 net [patch] data type size problem in if_spppsubr.c o kern/172895 net [ixgb] [ixgbe] do not properly determine link-state o kern/172683 net [ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos o kern/172113 net [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net [ip6] IPv6 packets transmitting only on queue 0 o kern/171739 net [bce] [panic] bce related kernel panic o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net [ndis] undocumented dependency for ndis(4) o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net [epair] [request] Add the ability to name epair device o kern/171228 net [re] [patch] if_re - eeprom write issues o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169664 net [bgp] Wrongful replacement of interface connected net o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/166940 net [ipfilter] [panic] Double fault in kern 8.2 o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166372 net [patch] [ipfilter] drops UDP packets with zero checksu o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis o kern/165963 net [panic] [ipfilter] ipfilter/nat NULL pointer deference p kern/165903 net mbuf leak o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155680 net [multicast] problems with multicast s kern/155642 net [new driver] [request] Add driver for Realtek RTL8191S o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel p kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [new driver] [request]: Port brcm80211 driver from Lin o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph f kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipfilter] There is no ippool start script/ipfilter ma o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [ipfilter] [rc.d] [patch] No good way to set ipfilter o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipfilter] FreeBSD 6.1+VPN+ipnat+ipf: port mapping doe o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipfilter] [panic] Kernel Panic Trap No 12 Page Fault o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipfilter] [patch] ipfilter drops OOW packets under 6. o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipfilter] [patch] wrong behaviour with skip rule insi o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87521 net [ipfilter] [panic] using ipfilter "auth" keyword leads o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipfilter] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation s kern/77195 net [ipfilter] [patch] ipfilter ioctl SIOCGNATL does not m o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipfilter] ipfilter ipnat problem with h323 proxy supp o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipfilter] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipfilter] [ppp] Interactive use of user PPP and ipfil f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 463 problems total. From owner-freebsd-net@FreeBSD.ORG Mon May 20 12:29:09 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6AB943D9 for ; Mon, 20 May 2013 12:29:09 +0000 (UTC) (envelope-from micchie@sfc.wide.ad.jp) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by mx1.freebsd.org (Postfix) with ESMTP id 3EC76617 for ; Mon, 20 May 2013 12:29:09 +0000 (UTC) Received: from epi.lan (prova.iet.unipi.it [131.114.58.86]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 7FF1D2780B1; Mon, 20 May 2013 21:29:05 +0900 (JST) Subject: Re: netmap bridge can tranmit big packet in line rate ? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michio Honda In-Reply-To: <1369036008085-5813346.post@n5.nabble.com> Date: Mon, 20 May 2013 14:29:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2F381156-B29B-4ED9-B7C4-CC1C629ABF6A@sfc.wide.ad.jp> References: <1369036008085-5813346.post@n5.nabble.com> To: liujie X-Mailer: Apple Mail (2.1283) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 12:29:09 -0000 I'm running the same experiments, but I see the line rate with any = packet size. Can you tell me your hardware setup and packet forwarding rates you = observed? Cheers, - Michio On May 20, 2013, at 9:46 AM, liujie wrote: > I tried netmap bridge to transmit 64-byte packets , the performance is = well > almost line rate.but when we increase the packet size, to performance > dropped rapiddly, anyone have tried this situation ? or can we tune = some > parameters to improve the performance ? > thanks. >=20 >=20 >=20 > -- > View this message in context: = http://freebsd.1045724.n5.nabble.com/netmap-bridge-can-tranmit-big-packet-= in-line-rate-tp5813346.html > Sent from the freebsd-net mailing list archive at Nabble.com. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >=20 From owner-freebsd-net@FreeBSD.ORG Mon May 20 20:05:42 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A64A5452 for ; Mon, 20 May 2013 20:05:42 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 63BB31AD7 for ; Mon, 20 May 2013 20:05:42 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r4KK5eg1060709 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 20 May 2013 13:05:41 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <519A820F.10807@freebsd.org> Date: Mon, 20 May 2013 13:05:35 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Haven Hash Subject: Re: more FIBs patch for review References: <201305161156.r4GBu0HQ018200@vps1.elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Julian Elischer , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 20:05:42 -0000 On 5/19/13 11:59 PM, Haven Hash wrote: > Was m_fibnum being defined to m_hdr.mh_nextpkt intended? (it doesn't appear > to be used here and it seemed an odd mapping to me). it is wrong and unused it was not supposed to get committed I plan to remove it > > Thanks, > > > On Thu, May 16, 2013 at 4:56 AM, Julian Elischer > wrote: > >> Index: sys/conf/NOTES >> =================================================================== >> --- sys/conf/NOTES (revision 250696) >> +++ sys/conf/NOTES (working copy) >> @@ -571,7 +571,8 @@ >> options INET #Internet communications protocols >> options INET6 #IPv6 communications protocols >> >> -options ROUTETABLES=2 # max 16. 1 is back compatible. >> +options ROUTETABLES=2 # allocated fibs up to 65536. >> default is 1. >> + # but that would be a bad idea as >> they are large. >> >> options TCP_OFFLOAD # TCP offload support. >> >> Index: sys/net/route.c >> =================================================================== >> --- sys/net/route.c (revision 250696) >> +++ sys/net/route.c (working copy) >> @@ -68,8 +68,7 @@ >> >> #include >> >> -/* We use 4 bits in the mbuf flags, thus we are limited to 16 FIBS. */ >> -#define RT_MAXFIBS 16 >> +#define RT_MAXFIBS UINT16_MAX >> >> /* Kernel config default option. */ >> #ifdef ROUTETABLES >> @@ -86,17 +85,10 @@ >> #define RT_NUMFIBS 1 >> #endif >> >> +/* This is read-only.. */ >> u_int rt_numfibs = RT_NUMFIBS; >> SYSCTL_UINT(_net, OID_AUTO, fibs, CTLFLAG_RD, &rt_numfibs, 0, ""); >> -/* >> - * Allow the boot code to allow LESS than RT_MAXFIBS to be used. >> - * We can't do more because storage is statically allocated for now. >> - * (for compatibility reasons.. this will change. When this changes, code >> should >> - * be refactored to protocol independent parts and protocol dependent >> parts, >> - * probably hanging of domain(9) specific storage to not need the full >> - * fib * af RNH allocation etc. but allow tuning the number of tables per >> - * address family). >> - */ >> +/* and this can be set too big but will be fixed before it is used */ >> TUNABLE_INT("net.fibs", &rt_numfibs); >> >> /* >> Index: sys/netinet6/ip6_output.c >> =================================================================== >> --- sys/netinet6/ip6_output.c (revision 250696) >> +++ sys/netinet6/ip6_output.c (working copy) >> @@ -1126,7 +1126,7 @@ >> IP6STAT_INC(ip6s_odropped); >> goto sendorfree; >> } >> - m->m_flags = m0->m_flags & M_COPYFLAGS; /* incl. >> FIB */ >> + m->m_flags = m0->m_flags & M_COPYFLAGS; >> *mnext = m; >> mnext = &m->m_nextpkt; >> m->m_data += max_linkhdr; >> @@ -1152,6 +1152,7 @@ >> } >> m_cat(m, m_frgpart); >> m->m_pkthdr.len = len + hlen + sizeof(*ip6f); >> + m->m_pkthdr.fibnum = m0->m_pkthdr.fibnum; >> m->m_pkthdr.rcvif = NULL; >> ip6f->ip6f_reserved = 0; >> ip6f->ip6f_ident = id; >> Index: sys/sys/mbuf.h >> =================================================================== >> --- sys/sys/mbuf.h (revision 250696) >> +++ sys/sys/mbuf.h (working copy) >> @@ -129,6 +129,8 @@ >> u_int16_t vt_vtag; /* Ethernet 802.1p+q vlan tag */ >> u_int16_t vt_nrecs; /* # of IGMPv3 records in this >> chain */ >> } PH_vt; >> + u_int16_t fibnum; /* this packet should use this fib >> */ >> + u_int16_t pad2; /* align to 32 bits */ >> SLIST_HEAD(packet_tags, m_tag) tags; /* list of packet tags */ >> }; >> #define ether_vtag PH_vt.vt_vtag >> @@ -171,6 +173,7 @@ >> #define m_type m_hdr.mh_type >> #define m_flags m_hdr.mh_flags >> #define m_nextpkt m_hdr.mh_nextpkt >> +#define m_fibnum m_hdr.mh_nextpkt >> #define m_act m_nextpkt >> #define m_pkthdr M_dat.MH.MH_pkthdr >> #define m_ext M_dat.MH.MH_dat.MH_ext >> @@ -205,12 +208,6 @@ >> #define M_FLOWID 0x00400000 /* deprecated: flowid is valid >> */ >> #define M_HASHTYPEBITS 0x0F000000 /* mask of bits holding flowid >> hash type */ >> >> -/* >> - * For RELENG_{6,7} steal these flags for limited multiple routing table >> - * support. In RELENG_8 and beyond, use just one flag and a tag. >> - */ >> -#define M_FIB 0xF0000000 /* steal some bits to store fib >> number. */ >> - >> #define M_NOTIFICATION M_PROTO5 /* SCTP notification */ >> >> /* >> @@ -258,7 +255,7 @@ >> */ >> #define M_COPYFLAGS \ >> >> (M_PKTHDR|M_EOR|M_RDONLY|M_PROTOFLAGS|M_SKIP_FIREWALL|M_BCAST|M_MCAST|\ >> - >> M_FRAG|M_FIRSTFRAG|M_LASTFRAG|M_VLANTAG|M_PROMISC|M_FIB|M_HASHTYPEBITS) >> + M_FRAG|M_FIRSTFRAG|M_LASTFRAG|M_VLANTAG|M_PROMISC|M_HASHTYPEBITS) >> >> /* >> * External buffer types: identify ext_buf type. >> @@ -1010,17 +1007,18 @@ >> m_tag_locate(m, MTAG_ABI_COMPAT, type, start)); >> } >> >> -/* XXX temporary FIB methods probably eventually use tags.*/ >> -#define M_FIBSHIFT 28 >> -#define M_FIBMASK 0x0F >> +static int inline >> +rt_m_getfib(struct mbuf *m) >> +{ >> + KASSERT(m->m_flags & M_EXT , ("attempt to set FIB on non header >> mbuf")); >> + return (m->m_pkthdr.fibnum); >> +} >> >> -/* get the fib from an mbuf and if it is not set, return the default */ >> -#define M_GETFIB(_m) \ >> - ((((_m)->m_flags & M_FIB) >> M_FIBSHIFT) & M_FIBMASK) >> +#define M_GETFIB(_m) rt_m_getfib(_m) >> >> #define M_SETFIB(_m, _fib) do { >> \ >> - _m->m_flags &= ~M_FIB; \ >> - _m->m_flags |= (((_fib) << M_FIBSHIFT) & M_FIB); \ >> + KASSERT((_m)->m_flags & M_EXT, ("No FIB on non header mbuf")); \ >> + ((_m)->m_pkthdr.fibnum) = (_fib); \ >> } while (0) >> >> #endif /* _KERNEL */ >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Mon May 20 20:42:24 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0DAB12F2 for ; Mon, 20 May 2013 20:42:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id D4A0C1892 for ; Mon, 20 May 2013 20:42:23 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BFD61B917; Mon, 20 May 2013 16:42:22 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: High CPU interrupt load on intel I350T4 with igb on 8.3 Date: Mon, 20 May 2013 16:02:08 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <517A657B.7060003@gmail.com> In-Reply-To: <517A657B.7060003@gmail.com> MIME-Version: 1.0 Message-Id: <201305201602.08281.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 20 May 2013 16:42:22 -0400 (EDT) Cc: "=?iso-8859-1?q?Cl=E9ment_Hermann?= \(nodens\)" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 20:42:24 -0000 On Friday, April 26, 2013 7:31:07 am Cl=E9ment Hermann (nodens) wrote: > Hi list, >=20 > We use pf+ALTQ for trafic shaping on some routers. >=20 > We are switching to new servers : Dell PowerEdge R620 with 2 8-cores=20 > Intel Processor (E5-2650L), 8GB RAM and Intel I350T4 (quad port) using=20 > igb driver. The old hardware is using em driver, the CPU load is high=20 > but mostly due to kernel and a large pf ruleset. >=20 > On the new hardware, we see high CPU Interrupt load (up to 95%), even=20 > though there is not much trafic currently (peaks about 150Mbps and=20 > 40Kpps). All queues are used and binded to a cpu according to top, but a= =20 > lot of CPU time is spent on igb queues (interrupt or wait). The load is=20 > fine when we stay below 20Kpps. >=20 > We see no mbuf shortage, no dropped packet, but there is little margin=20 > left on CPU time (about 25% idle at best, most of CPU time is spent on=20 > interrupts), which is disturbing. >=20 > We have done some tuning, but to no avail : If you have the processing_limit set to -1, you should never see CPU time=20 spent in the igb task threads (any such time means there is a bug). One su= ch=20 bug was fixed in 8.x here (that is after 8.3): http://svnweb.freebsd.org/base?view=3Drevision&revision=3D235553 This may not help with any issues in pf(4), but we had workloads at work (n= ot=20 involving pf) where this bug could cause boxes to spend 100% CPU in igb=20 threads. =2D-=20 John Baldwin From owner-freebsd-net@FreeBSD.ORG Mon May 20 23:08:09 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EC226542 for ; Mon, 20 May 2013 23:08:09 +0000 (UTC) (envelope-from lkchen@k-state.edu) Received: from ksu-out.merit.edu (ksu-out.merit.edu [207.75.117.132]) by mx1.freebsd.org (Postfix) with ESMTP id B97E8FFF for ; Mon, 20 May 2013 23:08:09 +0000 (UTC) X-Merit-ExtLoop1: 1 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAOsmlHPS3TT/2dsb2JhbABagwiDa78WFnSCJiNxGgINGQJZNYdxnAeOZok9iA6BJoxWgUKCK4ETA6h4gyuBTjw X-IronPort-AV: E=Sophos;i="4.87,711,1363147200"; d="scan'208";a="48700694" X-MERIT-SOURCE: KSU Received: from ksu-sfpop-mailstore02.merit.edu ([207.75.116.211]) by sfpop-ironport03.merit.edu with ESMTP; 20 May 2013 19:08:02 -0400 Date: Mon, 20 May 2013 19:08:02 -0400 (EDT) From: "Lawrence K. Chen, P.Eng." To: net@freebsd.org Message-ID: <380998552.18795251.1369091282251.JavaMail.root@k-state.edu> In-Reply-To: <20130419100620.GA94200@babolo.ru> Subject: Re: ipfilter(4) needs maintainer MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [70.179.144.108] X-Mailer: Zimbra 7.2.2_GA_2852 (ZimbraWebClient - GC27 ([unknown])/7.2.2_GA_2852) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 23:08:10 -0000 I'm late into this discussion, but I guess I'm glad that ipfilter will continue in FreeBSD.... It has only been since last summer that we've gotten our first production FreeBSD server. Several of us in the sysadmin team have been behind the possibility to varying degrees. We had pitched it an option to a federal site that we support, that was looking to replace their aging Solaris server. They had come to like ZFS and Zones in Solaris 10, but wanted to maximize performance and work within their declining IT budget, so going to FreeBSD with ZFS and jails seemed ideal. One day it suddenly appeared.... I was able to get up to speed and quickly adapt most of our configuration management system (cfengine2) to support FreeBSD 9 (before this I had only used FreeBSD 2 -- ran a Free-Net.) In the area of host based firewall, pretty much the only changes for FreeBSD was /usr/sbin/ipf vs /sbin/ipf and SMF vs /etc/rc.d. Having to support another firewall in our configuration generation process would've been a problem (though it is in need of a rewrite, which it may get since its likely we'll be moving to chef in the near future.) While personally, I would likely have adapted to using something else on my home system since I had played a little bit with ipfw and pf while investigating a performance problem of doing policy based routing to be able to have a jail with a different gateway. Which was resolved by using FIBs. And, I've been thinking of replacing my dd-wrt routers with pfsense.... And, I'm staying with cfengine3 for configuration management of my home systems, even though management has decided that we will go with chef ... because it might have some interesting features (and does things that requires purchasing the enterprise edition of cfengine3), though it doesn't do some of the processes that are critical to our current processes. We're still using cfengine2 at work, though I've heard that getting server upgraded to cfengine3 is nearly done. Though sounds like to get us on board, they'll send us to chef training....(or bring training on site) From owner-freebsd-net@FreeBSD.ORG Tue May 21 04:26:19 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6E3EC407 for ; Tue, 21 May 2013 04:26:19 +0000 (UTC) (envelope-from liujie@263.net) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 556A3DBB for ; Tue, 21 May 2013 04:26:18 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1Uee9L-0005YV-Tw for freebsd-net@freebsd.org; Mon, 20 May 2013 21:26:11 -0700 Date: Mon, 20 May 2013 21:26:11 -0700 (PDT) From: liujie To: freebsd-net@freebsd.org Message-ID: <1369110371922-5813589.post@n5.nabble.com> In-Reply-To: <2F381156-B29B-4ED9-B7C4-CC1C629ABF6A@sfc.wide.ad.jp> References: <1369036008085-5813346.post@n5.nabble.com> <2F381156-B29B-4ED9-B7C4-CC1C629ABF6A@sfc.wide.ad.jp> Subject: Re: netmap bridge can tranmit big packet in line rate ? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 04:26:19 -0000 My hardware setup is: CPU: i7 2600,MEM:16G NETWORK: intel 82599 OS:freebsd 9.1 when the packet size increases,the transmit rate drops. 1518-byte packet can only transmit about 80% can you tell me your hardware setup ? do you have any modification to bridge.c and netmap ? thanks for your reply. -- View this message in context: http://freebsd.1045724.n5.nabble.com/netmap-bridge-can-tranmit-big-packet-in-line-rate-tp5813346p5813589.html Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Tue May 21 07:40:17 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0E026C37 for ; Tue, 21 May 2013 07:40:17 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by mx1.freebsd.org (Postfix) with ESMTP id 8C3807D5 for ; Tue, 21 May 2013 07:40:16 +0000 (UTC) Received: by mail-lb0-f175.google.com with SMTP id v10so415098lbd.20 for ; Tue, 21 May 2013 00:40:15 -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=1PNARcyw0BSm/0mXwGLX38+kAFHeS6LpHiKlH5YEH1k=; b=eVvvp/D68wf0+us0QHIiwnwdSUQOpLO3qBhTbZh03EWg+axrXnP+V3YutQm3QgBPFw InJl7ntg0FZU+FQqojw6F7YvIIa+bxL1TgBrGeSH+H9owNP2/mVEJCW09lR4WMeK5zEf kp8Ngi06DfjIIDDndTQuAJW/K4T55NoSHCA2A8rbPealokcmUZMlLW9fNrEKhMlHhlmH m1pM1gHJcqyGQ2e1Ey5XzCpXizwqjWtkj4Mb6lh3NrUkztSiGdk6KWYKkv+ziGPxs8C8 nqtXBqhq7XukXgf4q5LuQ8K4pPgnFdBhXuECbmVd74UtJusNH4mxyp/NobtkdkKvELC+ NXsw== MIME-Version: 1.0 X-Received: by 10.112.169.72 with SMTP id ac8mr813940lbc.115.1369122015192; Tue, 21 May 2013 00:40:15 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.175.137 with HTTP; Tue, 21 May 2013 00:40:15 -0700 (PDT) In-Reply-To: <1369110371922-5813589.post@n5.nabble.com> References: <1369036008085-5813346.post@n5.nabble.com> <2F381156-B29B-4ED9-B7C4-CC1C629ABF6A@sfc.wide.ad.jp> <1369110371922-5813589.post@n5.nabble.com> Date: Tue, 21 May 2013 09:40:15 +0200 X-Google-Sender-Auth: jRJyLm_AulLNOYlNsJs7vn2Zoig Message-ID: Subject: Re: netmap bridge can tranmit big packet in line rate ? From: Luigi Rizzo To: liujie Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 07:40:17 -0000 On Tue, May 21, 2013 at 6:26 AM, liujie wrote: > My hardware setup is: > CPU: i7 2600,MEM:16G NETWORK: intel 82599 OS:freebsd 9.1 > when the packet size increases,the transmit rate drops. 1518-byte packet > can > only transmit about 80% > you should really tell us what numbers you see with various packet sizes, and whether you measure on the sender or on the receiver or on the bridge (you say "using netmap bridge to transmit..." which makes it unclear where you are making the measurements, whether you are using two machines or one, etc. 60-byte packets is the most challenging configuration for netmap, if you get line rate there then there is no reason not to go as fast with larger packets. > can you tell me your hardware setup ? > do you have any modification to bridge.c and netmap ? > nothing different from the ones in the FreeBSD tree, and we used it on a variety of different machines including test an i7-820 i think cheers luigi > > thanks for your reply. > > > > > -- > View this message in context: > http://freebsd.1045724.n5.nabble.com/netmap-bridge-can-tranmit-big-packet-in-line-rate-tp5813346p5813589.html > Sent from the freebsd-net mailing list archive at Nabble.com. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Tue May 21 09:25:17 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 308A246A for ; Tue, 21 May 2013 09:25:17 +0000 (UTC) (envelope-from liujie@263.net) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 15FC41C3 for ; Tue, 21 May 2013 09:25:16 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1Ueiom-0003UL-6G for freebsd-net@freebsd.org; Tue, 21 May 2013 02:25:16 -0700 Date: Tue, 21 May 2013 02:25:16 -0700 (PDT) From: liujie To: freebsd-net@freebsd.org Message-ID: <1369128316187-5813643.post@n5.nabble.com> In-Reply-To: References: <1369036008085-5813346.post@n5.nabble.com> <2F381156-B29B-4ED9-B7C4-CC1C629ABF6A@sfc.wide.ad.jp> <1369110371922-5813589.post@n5.nabble.com> Subject: Re: netmap bridge can tranmit big packet in line rate ? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 09:25:17 -0000 Hi, Prof.Luigi RIZZO Firstly i should thank you for netmap. I tried to send a e-mail to you yestoday, but it was rejected. I used two machines to test netmap bridge. all with i7-2600 cpu and intel 82599 dual-interfaces card. One worked as sender and receiver with pkt-gen, the other worked as bridge with bridge.c. as you said,I feeled comfous too when i saw the big packet performance dropped, i tried to change the memory parameters of netmap(netmap_mem1.c netmap_mem2.c),but it seemed that can not resove the problem. 60-byte packet send 14882289 pps recv 13994753 pps 124-byte send 8445770 pps recv 7628942 pps 252-byte send 4529819 pps recv 3757843 pps 508-byte send 2350815 pps recv 1645647 pps 1514-byte send 814288 pps recv 489133 pps sender command: pkt-gen -i ix0 -t 500000000 -l 60 receiver command: pkt-gen -i ix1 -r 500000000 bridge(other machine) command:bridge -i ix0 -i ix1 can sender and receiver on a same machine ? thank you for your reply. -- View this message in context: http://freebsd.1045724.n5.nabble.com/netmap-bridge-can-tranmit-big-packet-in-line-rate-tp5813346p5813643.html Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Tue May 21 10:08:34 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EB45923B for ; Tue, 21 May 2013 10:08:34 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 887B73FC for ; Tue, 21 May 2013 10:08:34 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id c10so2784481wiw.7 for ; Tue, 21 May 2013 03:08:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=5TGvseDuYXAEQFI/xLMSWj+yH7MtHRLok9+PqTpkvKI=; b=e9Lkir+YJSQoUWTVeBHRckbxIMKrmdNOQH4auYFhBurIERKat1Zo1PibdIgPVukqwO 9vqC8GC28losDz14nQGmyrFrabp1OjZsucoFAwkRfJ9vkURcoSEObIW725i0B3xik+8w bKK3pySSZ5tbEMwHL/f8a82+6lEdX41aLivdvhxI6yNeySERcsTAYir7M6pW2BMUJv7c zH/lelyUssZUBFwpZmFSg69SEzKr4klYcyscyQa0T6hjSUdxAtnhD0a4GH/HvvMemg3M njWCfWJn6+ept2EsXYHKB/BUHNGH6/EGzhTBiLkp/8zznsBD4v/8n9GXl7LT5XAjqw9h kglQ== MIME-Version: 1.0 X-Received: by 10.180.105.231 with SMTP id gp7mr22112312wib.23.1369130490873; Tue, 21 May 2013 03:01:30 -0700 (PDT) Received: by 10.180.108.5 with HTTP; Tue, 21 May 2013 03:01:30 -0700 (PDT) Date: Tue, 21 May 2013 18:01:30 +0800 Message-ID: Subject: ALTQ + em or ixgbe does not works. From: Marcelo Araujo To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: araujo@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 10:08:35 -0000 Hello All, As I do believe more people has the same problem, I'm wondering if there is anyone taking a looking on this problem that is pretty much serious. ALTQ does not works with any ixgbe, em, gbe drivers on FreeBSD 9.1-RELEASE. I saw Glebius also mention about this problem while ago. Any solution? Best Regards, -- Marcelo Araujo araujo@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Tue May 21 10:32:40 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3FF8C9EE for ; Tue, 21 May 2013 10:32:40 +0000 (UTC) (envelope-from zec@fer.hr) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) by mx1.freebsd.org (Postfix) with ESMTP id C9D6678E for ; Tue, 21 May 2013 10:32:39 +0000 (UTC) Received: from dyn4.nxlab.fer.hr (161.53.63.204) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 21 May 2013 12:31:27 +0200 From: Marko Zec To: Subject: Re: netmap bridge can tranmit big packet in line rate ? Date: Tue, 21 May 2013 12:29:27 +0200 User-Agent: KMail/1.9.10 References: <1369036008085-5813346.post@n5.nabble.com> <1369128316187-5813643.post@n5.nabble.com> In-Reply-To: <1369128316187-5813643.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <201305211229.28182.zec@fer.hr> X-Originating-IP: [161.53.63.204] Cc: liujie X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 10:32:40 -0000 On Tuesday 21 May 2013 11:25:16 liujie wrote: > Hi, Prof.Luigi RIZZO > > Firstly i should thank you for netmap. I tried to send a e-mail to you > yestoday, but it was rejected. > > I used two machines to test netmap bridge. all with i7-2600 cpu and > intel 82599 dual-interfaces card. > > One worked as sender and receiver with pkt-gen, the other worked as > bridge with bridge.c. > > as you said,I feeled comfous too when i saw the big packet performance > dropped, i tried to change the memory parameters of netmap(netmap_mem1.c > netmap_mem2.c),but it seemed that can not resove the problem. > 60-byte packet send 14882289 pps recv 13994753 pps > 124-byte send 8445770 pps recv 7628942 pps > 252-byte send 4529819 pps recv 3757843 pps > 508-byte send 2350815 pps recv 1645647 pps > 1514-byte send 814288 pps recv 489133 pps > > sender command: pkt-gen -i ix0 -t 500000000 -l 60 > receiver command: pkt-gen -i ix1 -r 500000000 > bridge(other machine) command:bridge -i ix0 -i ix1 > > can sender and receiver on a same machine ? Most likely the PCIe path between the dual-ported card and the CPU is the bottleneck. Depending on the chipset and motherboard design, it may be that your card is only using 4 instead of 8 PCIe lanes, because some of the lanes may be "shared" with another PCIe slot, such as the one in which a graphic card is plugged in. You can also try experimenting with slightly overclocking the PCIe bus if the BIOS permits that - I had no problems overclocking the ixgbe and an AMD PCIe chipset by 25%. Marko From owner-freebsd-net@FreeBSD.ORG Tue May 21 11:30:03 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 842CE504 for ; Tue, 21 May 2013 11:30:03 +0000 (UTC) (envelope-from liujie@263.net) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 696159AD for ; Tue, 21 May 2013 11:30:03 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UeklW-0002zF-Bm for freebsd-net@freebsd.org; Tue, 21 May 2013 04:30:02 -0700 Date: Tue, 21 May 2013 04:30:02 -0700 (PDT) From: liujie To: freebsd-net@freebsd.org Message-ID: <1369135802357-5813661.post@n5.nabble.com> In-Reply-To: <201305211229.28182.zec@fer.hr> References: <1369036008085-5813346.post@n5.nabble.com> <2F381156-B29B-4ED9-B7C4-CC1C629ABF6A@sfc.wide.ad.jp> <1369110371922-5813589.post@n5.nabble.com> <1369128316187-5813643.post@n5.nabble.com> <201305211229.28182.zec@fer.hr> Subject: Re: netmap bridge can tranmit big packet in line rate ? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 11:30:03 -0000 Thank marko. My machine mainboard chipset is intel c206, and network is dual-port intel x520 card. I'll find other machine to test once more. -- View this message in context: http://freebsd.1045724.n5.nabble.com/netmap-bridge-can-tranmit-big-packet-in-line-rate-tp5813346p5813661.html Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Tue May 21 11:46:31 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4E9CCF74 for ; Tue, 21 May 2013 11:46:31 +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 11A18A64 for ; Tue, 21 May 2013 11:46:29 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 3D6A37300A; Tue, 21 May 2013 13:40:20 +0200 (CEST) Date: Tue, 21 May 2013 13:40:20 +0200 From: Luigi Rizzo To: liujie Subject: Re: netmap bridge can tranmit big packet in line rate ? Message-ID: <20130521114020.GB79320@onelab2.iet.unipi.it> References: <1369036008085-5813346.post@n5.nabble.com> <2F381156-B29B-4ED9-B7C4-CC1C629ABF6A@sfc.wide.ad.jp> <1369110371922-5813589.post@n5.nabble.com> <1369128316187-5813643.post@n5.nabble.com> <201305211229.28182.zec@fer.hr> <1369135802357-5813661.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1369135802357-5813661.post@n5.nabble.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 11:46:31 -0000 On Tue, May 21, 2013 at 04:30:02AM -0700, liujie wrote: > Thank marko. > > My machine mainboard chipset is intel c206, and network is dual-port intel > x520 card. while you run your tests, try to instrument bridge.c and see how many pps it actually receives and transmits. As Marko said, there might be congestion on the PCIe bus, but i would expect a lot more of it with small packet sizes than large ones. cheers luigi > I'll find other machine to test once more. > > > > -- > View this message in context: http://freebsd.1045724.n5.nabble.com/netmap-bridge-can-tranmit-big-packet-in-line-rate-tp5813346p5813661.html > Sent from the freebsd-net mailing list archive at Nabble.com. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue May 21 12:42:18 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ED095716 for ; Tue, 21 May 2013 12:42:18 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm27-vm0.bullet.mail.ne1.yahoo.com (nm27-vm0.bullet.mail.ne1.yahoo.com [98.138.91.63]) by mx1.freebsd.org (Postfix) with ESMTP id A094EE80 for ; Tue, 21 May 2013 12:42:18 +0000 (UTC) Received: from [98.138.90.53] by nm27.bullet.mail.ne1.yahoo.com with NNFMP; 21 May 2013 12:40:08 -0000 Received: from [98.138.226.166] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 21 May 2013 12:40:08 -0000 Received: from [127.0.0.1] by omp1067.mail.ne1.yahoo.com with NNFMP; 21 May 2013 12:40:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 136420.86532.bm@omp1067.mail.ne1.yahoo.com Received: (qmail 961 invoked by uid 60001); 21 May 2013 12:40:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1369140008; bh=jGYAe5SJ25lT9ZYJSc5GyyPVtUaxAJ8kAbphDKLa6zw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=u6f0ou4K5m9RfwJp/wqicB/sbHkrAej978CpJqVQU2YC+2lMJ9uvPNLHob8kQbEgpMneZ5fa4OWOrWWLVJEfjlq7PXkDqfVIJAeUztMuaqliWXGI8R6QhvBrGT+ORPS2hBDLB9nIarlb9Isc46k+0EKw/3vT9XA7GNDszzwzc8I= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=nJeIyYZFf0aeyzdIJ5vfAP6fRcLF4FZF5ADINCNGKyjOjLtnSORkqvne36tBvPbdNX/TxfoceKuBqPRXK/kKoF1sytAsvEjno/tySNS1mblwpe6mik0e3qY2SEnO0vN6rvrIxVzZMxOLtV1KqU7yQAxrdrjHWSdI4GnqjwcueQ4=; X-YMail-OSG: iynRALUVM1ntHpeZdd1ZGrrQVYd0h9ebp8cxjZYbaUtqIN9 zSqZDB72euDIl8NBMqHZ3KD5CJKwigcApP7O2.UqDqOPN7AgCAah0_czLXRD XZyr.Su53igTwDG9__CuPWKdFhZU74ldhQf2eiQpSq9K7F7FjEi8tfEPLDmF G1cYtbN89NSIxfrnrAWHtfAM9cE3v8HODjjmLtyjbji.CpHY4BirGAUWYDnS cJWBmaU7DzYMXnphu0PyyMjaRVnzseGi6pFTEiXMOBFkMG7doYiqONFPJlJ5 IWGURNf_czPSJ3O.DSWkeqAFE3XWyYKWbIxxWC1ibdkPAjTntFAF1rko5D24 scfLwdD2o_.ysunUeS5R73ozGhujmFRkBkDSI6lqi7fgDVvA6zNmZLOC5G5w vi6Oq76iywLtZrE__h2f3tlh8vSRRmu261HJQEk5xsbG_X4xrGfShWyOm.Yc lp6MV5sDV3dAq0G.wDCnjDeagzKXIoMa8ob0ff9ekZNpCOKzmq1SLUEwyM6R bH_xGs40E9JxZjrO7ykkX4SRWVrCL0HKjo40u8zQ- Received: from [98.203.118.124] by web121602.mail.ne1.yahoo.com via HTTP; Tue, 21 May 2013 05:40:07 PDT X-Rocket-MIMEInfo: 002.001, CgotLS0gT24gVHVlLCA1LzIxLzEzLCBsaXVqaWUgPGxpdWppZUAyNjMubmV0PiB3cm90ZToKCj4gRnJvbTogbGl1amllIDxsaXVqaWVAMjYzLm5ldD4KPiBTdWJqZWN0OiBSZTogbmV0bWFwIGJyaWRnZSBjYW4gdHJhbm1pdCBiaWcgcGFja2V0IGluIGxpbmUgcmF0ZSA_Cj4gVG86IGZyZWVic2QtbmV0QGZyZWVic2Qub3JnCj4gRGF0ZTogVHVlc2RheSwgTWF5IDIxLCAyMDEzLCA1OjI1IEFNCj4gSGksIFByb2YuTHVpZ2kgUklaWk8KPiDCoMKgwqAKPiAgRmlyc3RseSBpIHNob3VsZCB0aGFuayB5b3UgZm9yIG4BMAEBAQE- X-Mailer: YahooMailClassic/15.1.8 YahooMailWebService/0.8.142.542 Message-ID: <1369140007.80942.YahooMailClassic@web121602.mail.ne1.yahoo.com> Date: Tue, 21 May 2013 05:40:07 -0700 (PDT) From: Barney Cordoba Subject: Re: netmap bridge can tranmit big packet in line rate ? To: freebsd-net@freebsd.org In-Reply-To: <1369128316187-5813643.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: liujie@263.net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 12:42:19 -0000 =0A=0A--- On Tue, 5/21/13, liujie wrote:=0A=0A> From: liuj= ie =0A> Subject: Re: netmap bridge can tranmit big packet i= n line rate ?=0A> To: freebsd-net@freebsd.org=0A> Date: Tuesday, May 21, 20= 13, 5:25 AM=0A> Hi, Prof.Luigi RIZZO=0A> =A0=A0=A0=0A> Firstly i should th= ank you for netmap. I tried to send a=0A> e-mail to you=0A> yestoday, but i= t was rejected.=0A> =0A> I used two machines to test netmap bridge. all wi= th i7-2600=0A> cpu and intel=0A> 82599 dual-interfaces card.=0A> =0A> One = worked as sender and receiver with pkt-gen, the other=0A> worked as bridge= =0A> with bridge.c.=0A> =0A> as you said,I feeled comfous too when i saw t= he big packet=0A> performance=0A> dropped, i tried to change the memory par= ameters of=0A> netmap(netmap_mem1.c=0A> netmap_mem2.c),but it seemed that= =A0 can not resove the=0A> problem.=0A> =A0 60-byte packet send 14882289 pp= s=A0 recv=A0=0A> 13994753 pps=0A> =A0 124-byte=A0 =A0 =A0=0A> =A0=A0=A0send= =A0=A0=A08445770 pps=A0=0A> recv=A0 =A0 7628942 pps=0A> =A0 252-byte=A0 =A0= =A0=0A> =A0=A0=A0send=A0=A0=A04529819 pps=A0=0A> recv=A0 =A0=A0=A03757843 = pps=0A> =A0 508-byte=A0 =A0 =A0=0A> =A0=A0=A0send=A0 =A0 2350815 pps=A0=0A>= recv=A0 =A0 1645647 pps=0A> =A0 1514-byte=A0 =A0 =A0=A0=A0send=A0=0A> =A0 = 814288 pps=A0 =A0=A0=A0recv=A0 489133=0A> pps=0A=0AThese numbers indicate y= ou're tx'ing 7.2Gb/s with 60 byte packets and=0A9.8Gb/s with 1514, so maybe= you just need a new calculator?=0A=0ABC From owner-freebsd-net@FreeBSD.ORG Tue May 21 14:21:14 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F10C9735 for ; Tue, 21 May 2013 14:21:14 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by mx1.freebsd.org (Postfix) with ESMTP id 8983B3E7 for ; Tue, 21 May 2013 14:21:14 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id c10so403417wiw.3 for ; Tue, 21 May 2013 07:21:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=EZH3INnmS6PFIkxoZGKu9YLJv4t6pqVZMFZSScBRRy4=; b=s02gx8PKSXUWcaLQTo8QTth9e20XU0oxk9evEw7aUGZ/ZD19WA7tcQVvj4wMeL3osT axfi7ltDLoEO8W/PKFOjKyWrpCb3b12/ryoQXGgk5lzgzReZbJ7K8uTOvI2tilhUp8M7 FCcLCMq/Tqcw2MaKcSof0wDb8ypRgP9l63eDiHGswwVphKIWWM38J99UpdAJafmxDLSa fnW5aBhD10odFm5gRuVquJnkOX+S+UqF0wkyBY2zF4/yd06Zs6y/sX5x7zo+/nIbCXPw U0u+PrNLuwP4jzzok4Q1PeWQIlrwXJ1sqG9TC4lJNst2pMSQwzL/LfckWmj8/weoOQAN 7G5w== X-Received: by 10.180.74.207 with SMTP id w15mr5456688wiv.19.1369146073647; Tue, 21 May 2013 07:21:13 -0700 (PDT) Received: from [192.168.2.30] ([2.176.232.238]) by mx.google.com with ESMTPSA id x13sm4208302wib.3.2013.05.21.07.21.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 May 2013 07:21:12 -0700 (PDT) Message-ID: <519B82D8.9010508@gmail.com> Date: Tue, 21 May 2013 18:51:12 +0430 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: netmap bridge can tranmit big packet in line rate ? References: <1369140007.80942.YahooMailClassic@web121602.mail.ne1.yahoo.com> In-Reply-To: <1369140007.80942.YahooMailClassic@web121602.mail.ne1.yahoo.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 14:21:15 -0000 On 5/21/2013 5:10 PM, Barney Cordoba wrote: > > --- On Tue, 5/21/13, liujie wrote: > >> From: liujie >> Subject: Re: netmap bridge can tranmit big packet in line rate ? >> To: freebsd-net@freebsd.org >> Date: Tuesday, May 21, 2013, 5:25 AM >> Hi, Prof.Luigi RIZZO >> >> Firstly i should thank you for netmap. I tried to send a >> e-mail to you >> yestoday, but it was rejected. >> >> I used two machines to test netmap bridge. all with i7-2600 >> cpu and intel >> 82599 dual-interfaces card. >> >> One worked as sender and receiver with pkt-gen, the other >> worked as bridge >> with bridge.c. >> >> as you said,I feeled comfous too when i saw the big packet >> performance >> dropped, i tried to change the memory parameters of >> netmap(netmap_mem1.c >> netmap_mem2.c),but it seemed that can not resove the >> problem. >> 60-byte packet send 14882289 pps recv >> 13994753 pps >> 124-byte >> send 8445770 pps >> recv 7628942 pps >> 252-byte >> send 4529819 pps >> recv 3757843 pps >> 508-byte >> send 2350815 pps >> recv 1645647 pps >> 1514-byte send >> 814288 pps recv 489133 >> pps > These numbers indicate you're tx'ing 7.2Gb/s with 60 byte packets and > 9.8Gb/s with 1514, so maybe you just need a new calculator? > > BC > _______________________________________________ > AsBarney pointed outalready, your numbers are reasonable. You have almost saturated the link with 1514 byte packets.In the case of 64 byte packets, you do not achieve line rate probably because of the congestion on the bus.Can you show us "top -SI" output on the sender machine? -- Best regards. Hooman Fazaeli From owner-freebsd-net@FreeBSD.ORG Tue May 21 14:36:19 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 95D7F14C for ; Tue, 21 May 2013 14:36:19 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 0D3C869F for ; Tue, 21 May 2013 14:36:18 +0000 (UTC) Received: (qmail 32228 invoked from network); 21 May 2013 15:36:08 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 May 2013 15:36:08 -0000 Message-ID: <519B8657.6070201@freebsd.org> Date: Tue, 21 May 2013 16:36:07 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Hooman Fazaeli Subject: Re: netmap bridge can tranmit big packet in line rate ? References: <1369140007.80942.YahooMailClassic@web121602.mail.ne1.yahoo.com> <519B82D8.9010508@gmail.com> In-Reply-To: <519B82D8.9010508@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: liujie@263.net, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 14:36:19 -0000 On 21.05.2013 16:21, Hooman Fazaeli wrote: > AsBarney pointed outalready, your numbers are reasonable. You have almost saturated > the link with 1514 byte packets.In the case of 64 byte packets, you do not achieve line > rate probably because of the congestion on the bus.Can you show us "top -SI" output on the > sender machine? Be aware that "line rate" for small packets is NOT raw link speed divided by packet size. There's also pre- and post-amble bits and inter-frame gap to be considered. Those bits are on the wire too but invisible as they are handled entirely by the ethernet NIC. The minimum size of an ethernet frame is 64 bytes (excluding the additional bits, 84 bytes including them) even though IP packets can be smaller. The difference is padded by the NIC. So the maximum is 14,880,960 pps at 64 bytes and 812,740 at 1500 bytes. There's a number of resources explaining this issue in more detail: http://www.cisco.com/web/about/security/intelligence/network_performance_metrics.html http://ekb.spirent.com/resources/sites/SPIRENT/content/live/FAQS/10000/FAQ10597/en_US/How_to_Test_10G_Ethernet_WhitePaper_RevB.PDF -- Andre From owner-freebsd-net@FreeBSD.ORG Tue May 21 14:36:34 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3F11B1DC for ; Tue, 21 May 2013 14:36:34 +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 04F736A7 for ; Tue, 21 May 2013 14:36:33 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id B9D9073027; Tue, 21 May 2013 16:39:06 +0200 (CEST) Date: Tue, 21 May 2013 16:39:06 +0200 From: Luigi Rizzo To: Hooman Fazaeli Subject: Re: netmap bridge can tranmit big packet in line rate ? Message-ID: <20130521143906.GA80993@onelab2.iet.unipi.it> References: <1369140007.80942.YahooMailClassic@web121602.mail.ne1.yahoo.com> <519B82D8.9010508@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <519B82D8.9010508@gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 14:36:34 -0000 On Tue, May 21, 2013 at 06:51:12PM +0430, Hooman Fazaeli wrote: > On 5/21/2013 5:10 PM, Barney Cordoba wrote: > > > > --- On Tue, 5/21/13, liujie wrote: > > > >> From: liujie > >> Subject: Re: netmap bridge can tranmit big packet in line rate ? > >> To: freebsd-net@freebsd.org > >> Date: Tuesday, May 21, 2013, 5:25 AM > >> Hi, Prof.Luigi RIZZO > >> > >> Firstly i should thank you for netmap. I tried to send a > >> e-mail to you > >> yestoday, but it was rejected. > >> > >> I used two machines to test netmap bridge. all with i7-2600 > >> cpu and intel > >> 82599 dual-interfaces card. > >> > >> One worked as sender and receiver with pkt-gen, the other > >> worked as bridge > >> with bridge.c. > >> > >> as you said,I feeled comfous too when i saw the big packet > >> performance > >> dropped, i tried to change the memory parameters of > >> netmap(netmap_mem1.c > >> netmap_mem2.c),but it seemed that can not resove the > >> problem. > >> 60-byte packet send 14882289 pps recv > >> 13994753 pps > >> 124-byte > >> send 8445770 pps > >> recv 7628942 pps > >> 252-byte > >> send 4529819 pps > >> recv 3757843 pps > >> 508-byte > >> send 2350815 pps > >> recv 1645647 pps > >> 1514-byte send > >> 814288 pps recv 489133 > >> pps > > These numbers indicate you're tx'ing 7.2Gb/s with 60 byte packets and > > 9.8Gb/s with 1514, so maybe you just need a new calculator? > > > > BC > > _______________________________________________ > > > AsBarney pointed outalready, your numbers are reasonable. You have almost saturated > the link with 1514 byte packets.In the case of 64 byte packets, you do not achieve line > rate probably because of the congestion on the bus.Can you show us "top -SI" output on the > sender machine? the OP is commenting that on the receive side he is seeing a much lower number than on the tx side (A:ix1 489Kpps vs A:ix0 814Kpps). [pkt-gen -f tx ix0]-->--[ix0 bridge ] [ HOST A ] [ HOST B ] [pkt-gen -f rx ix1]--<--[ix1 ] What is unclear is where the loss occurs. cheers luigi From owner-freebsd-net@FreeBSD.ORG Tue May 21 14:54:11 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B1AD7A97 for ; Tue, 21 May 2013 14:54:11 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm30-vm4.bullet.mail.ne1.yahoo.com (nm30-vm4.bullet.mail.ne1.yahoo.com [98.138.91.190]) by mx1.freebsd.org (Postfix) with ESMTP id 7189B829 for ; Tue, 21 May 2013 14:54:11 +0000 (UTC) Received: from [98.138.90.55] by nm30.bullet.mail.ne1.yahoo.com with NNFMP; 21 May 2013 14:52:24 -0000 Received: from [98.138.89.175] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 21 May 2013 14:52:24 -0000 Received: from [127.0.0.1] by omp1031.mail.ne1.yahoo.com with NNFMP; 21 May 2013 14:52:24 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 441181.86690.bm@omp1031.mail.ne1.yahoo.com Received: (qmail 31454 invoked by uid 60001); 21 May 2013 14:52:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1369147944; bh=ggNK0FpIVCfgkC0LtOhOv9a454KxDS9hq2lj9ZB17Fc=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=oFGJ5KzqBUgKCMlWoaM3zMNbvVi0cnBmHrq3hDENxSIoR9FGkWbcN3D/+ZUi1pjnScKsnoCwWhu1hVi1Dt2b9+BdDRLg+ytR7zXMhOVFkyq8Of8vqn/GhVdCrkaGvk2xQ05iKNPRrME+S448sbL6A9urJrL3EAUjQbe/oTxPn1g= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=wvIqEyNNQS0r7iwJDUtypO4tSP7zCCIpd++rdWpAY6ljXs1dLvRhHCXHbH3uyY5hfckgnfeyZ5jHxgeWKEPLJ7qGHh+TN6PMT/OCM16I8/swemagOcJc74Rajw8NhumdrG9PdsufUDBX9MF5i2WoS9uSX17/vX4ZQc8nNYOXp84=; X-YMail-OSG: NdwprkEVM1mzG9UFn57t2MztH09r8niG8oCtpkQ80JM9IXz Flx5j1e81Ha2qNZ2daALOkp1ww_Mbpvu4z0RIGwP_eTbqWzKLuHzK.dF4QFX vK1m7Js_Njyx27rBRJqeWWAk_u9lthhYGXhcyiE34rcSD6__4rkWJ47DiXvi SaujORE_LSP9KV.U4R8Hv19bHTVETeqNO4OqqE7bA7v0Bi8x5DL3A6UBUe55 3wVdj1hO81gG9Sef7RXEP6jpcOYgCV4LU9qCBgYLPDpDFtAWH_JraiOuoT63 GvV.W5WOtb4OTTFmSxHxzzBKmbe36ytRmP6S7Ua1zjFbABct6vL1lPJL9t4M F1TCgqrF3oWZvlZC0XHbQ549zhlrG3gVSfi5XPEh3RLv7MsMV.plu1tNiUjD cXJjRFQvLZA4E_YGcrc9RaM9Aa_WVT3zcSvdiVTKRTZmUx33otZeaciXL2hp vP6Vy_v6ZuH71IO.3a2UX9Fw6ubQNUtGdO7be3ZygLczxepgiVRJFDbsMM3k GmGq1oC2.sYRDLFDweqrK0MId9dfrfd9lb1IrJpo2FzSYlQi_EOeglLYOwVi ECdwLdKbcFhug.zIkIthzgutRWQXJBOI- Received: from [98.203.118.124] by web121606.mail.ne1.yahoo.com via HTTP; Tue, 21 May 2013 07:52:24 PDT X-Rocket-MIMEInfo: 002.001, CgotLS0gT24gVHVlLCA1LzIxLzEzLCBMdWlnaSBSaXp6byA8cml6em9AaWV0LnVuaXBpLml0PiB3cm90ZToKCj4gRnJvbTogTHVpZ2kgUml6em8gPHJpenpvQGlldC51bmlwaS5pdD4KPiBTdWJqZWN0OiBSZTogbmV0bWFwIGJyaWRnZSBjYW4gdHJhbm1pdCBiaWcgcGFja2V0IGluIGxpbmUgcmF0ZSA_Cj4gVG86ICJIb29tYW4gRmF6YWVsaSIgPGhvb21hbmZhemFlbGlAZ21haWwuY29tPgo.IENjOiBmcmVlYnNkLW5ldEBmcmVlYnNkLm9yZwo.IERhdGU6IFR1ZXNkYXksIE1heSAyMSwgMjAxMywgMTA6MzkgQU0BMAEBAQE- X-Mailer: YahooMailClassic/15.1.8 YahooMailWebService/0.8.142.542 Message-ID: <1369147944.27968.YahooMailClassic@web121606.mail.ne1.yahoo.com> Date: Tue, 21 May 2013 07:52:24 -0700 (PDT) From: Barney Cordoba Subject: Re: netmap bridge can tranmit big packet in line rate ? To: Hooman Fazaeli , Luigi Rizzo In-Reply-To: <20130521143906.GA80993@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 14:54:11 -0000 =0A=0A--- On Tue, 5/21/13, Luigi Rizzo wrote:=0A=0A> F= rom: Luigi Rizzo =0A> Subject: Re: netmap bridge can tr= anmit big packet in line rate ?=0A> To: "Hooman Fazaeli" =0A> Cc: freebsd-net@freebsd.org=0A> Date: Tuesday, May 21, 2013, 10= :39 AM=0A> On Tue, May 21, 2013 at 06:51:12PM=0A> +0430, Hooman Fazaeli wro= te:=0A> > On 5/21/2013 5:10 PM, Barney Cordoba wrote:=0A> > >=0A> > > --- O= n Tue, 5/21/13, liujie =0A> wrote:=0A> > >=0A> > >> From: l= iujie =0A> > >> Subject: Re: netmap bridge can tranmit big= =0A> packet in line rate ?=0A> > >> To: freebsd-net@freebsd.org=0A> > >> Da= te: Tuesday, May 21, 2013, 5:25 AM=0A> > >> Hi, Prof.Luigi RIZZO=0A> > >>= =A0 =A0 =0A> > >>=A0 Firstly i should thank you for netmap. I=0A> tried to = send a=0A> > >> e-mail to you=0A> > >> yestoday, but it was rejected.=0A> >= >>=0A> > >>=A0 I used two machines to test netmap=0A> bridge. all with i7-= 2600=0A> > >> cpu and intel=0A> > >> 82599 dual-interfaces card.=0A> > >>= =0A> > >>=A0 One worked as sender and receiver with=0A> pkt-gen, the other= =0A> > >> worked as bridge=0A> > >> with bridge.c.=0A> > >>=0A> > >>=A0 as = you said,I feeled comfous too when i=0A> saw the big packet=0A> > >> perfor= mance=0A> > >> dropped, i tried to change the memory=0A> parameters of=0A> = > >> netmap(netmap_mem1.c=0A> > >> netmap_mem2.c),but it seemed that=A0 can= =0A> not resove the=0A> > >> problem.=0A> > >>=A0=A0=A060-byte packet send = 14882289=0A> pps=A0 recv =0A> > >> 13994753 pps=0A> > >>=A0=A0=A0124-byte= =A0=0A> =A0=A0=A0=0A> > >>=A0 =A0 send=A0=A0=A08445770 pps=0A> =0A> > >> re= cv=A0 =A0 7628942 pps=0A> > >>=A0=A0=A0252-byte=A0=0A> =A0=A0=A0=0A> > >>= =A0 =A0 send=A0=A0=A04529819 pps=0A> =0A> > >> recv=A0 =A0=A0=A03757843 pps= =0A> > >>=A0=A0=A0508-byte=A0=0A> =A0=A0=A0=0A> > >>=A0 =A0 send=A0 =A0 235= 0815 pps =0A> > >> recv=A0 =A0 1645647 pps=0A> > >>=A0=A0=A01514-byte=A0 = =A0=0A> =A0=A0=A0send =0A> > >>=A0=A0=A0814288 pps=A0=0A> =A0=A0=A0recv=A0 = 489133=0A> > >> pps=0A> > > These numbers indicate you're tx'ing 7.2Gb/s wi= th=0A> 60 byte packets and=0A> > > 9.8Gb/s with 1514, so maybe you just nee= d a new=0A> calculator?=0A> > >=0A> > > BC=0A> > > ________________________= _______________________=0A> > >=0A> > AsBarney pointed outalready, your num= bers are=0A> reasonable. You have almost saturated=0A> > the link with 1514= byte packets.In the case of 64 byte=0A> packets, you do not achieve line= =0A> > rate probably because of the congestion on the bus.Can=0A> you show = us "top -SI" output on the=0A> > sender machine?=0A> =0A> the OP is comment= ing that on the receive side he is seeing a=0A> much=0A> lower number than = on the tx side (A:ix1 489Kpps vs A:ix0=0A> 814Kpps).=0A> =0A> =A0 =A0 [pkt-= gen -f tx ix0]-->--[ix0 bridge ]=0A> =A0 =A0 [=A0=A0=A0HOST A=A0 =A0 =A0=0A= > =A0 ]=A0 =A0=A0=A0[=A0 =A0 HOST B ]=0A> =A0 =A0 [pkt-gen -f rx ix1]--<--[= ix1=A0 =A0=0A> =A0 =A0 ]=0A> =0A> What is unclear is where the loss occurs.= =0A> =0A> =A0=A0=A0 cheers=0A> =A0=A0=A0 luigi=0A=0AThe ixgbe driver has ma= c stats that will answer that. Just look at the=0Asysctl output.=0A=0ABC From owner-freebsd-net@FreeBSD.ORG Wed May 22 03:05:33 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5BEC64DA for ; Wed, 22 May 2013 03:05:33 +0000 (UTC) (envelope-from giorgiolago@gmail.com) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 9964C1D6 for ; Wed, 22 May 2013 03:05:32 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id u59so175163wes.29 for ; Tue, 21 May 2013 20:05:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=k/5EQT7wg3eEa1whlgOaKbTtVgDYOAtSP7gNpPKYLH8=; b=ykN9Qdw8q/yVZKtHcKRVnrCMZ93lrgjRTrW2/wTylSX2MkOpC2v8WloaEyw4gmC8VB qHQH0ar1tRAQNy68W/U4huaQ8l/KnpSCcPpPwOIvYDPBJthqKYAeP/vX1b5zMZXWGl3P kcqvMAC3Sbr93/0c67bV6oFdvSb8/Vi6bfs6NBvhJYRvRLQ5GxcKui95erK/Iqpm6MVt li81NuDhvEwvXw8Z/DnAQXYSYF45iGm8CFrx0LRUkGv1XPalijr2aeC48B/M2wiq8jaa 4p8HuscMTcizIQjTXNo+KlImHDQ0h0swrsLMHUQ/2Rlm8HgDSzPANxKXBVjbTgt89HYl y/vg== MIME-Version: 1.0 X-Received: by 10.180.109.48 with SMTP id hp16mr10069801wib.24.1369191931641; Tue, 21 May 2013 20:05:31 -0700 (PDT) Received: by 10.194.174.231 with HTTP; Tue, 21 May 2013 20:05:31 -0700 (PDT) Date: Wed, 22 May 2013 00:05:31 -0300 Message-ID: Subject: em2: watchdog timeout - resetting From: Giorgio Emanuel To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 03:05:33 -0000 Hello, I have a server pfsense in bridge mode to function as transparent FW, the problem is that once I connect the pfsense between my router core and my core switch catalyst a few seconds begin to appear several messages like these: em2: watchdog timeout - resetting em2: watchdog timeout - resetting em2: watchdog timeout - resetting em2: watchdog timeout - resetting And the connection falls back repeatedly and indefinitely. Searching on google did some tweaks: hw.em.rxd =3D "4096" hw.em.txd =3D "4096" hw.em.tx_int_delay =3D "250" hw.em.rx_int_delay =3D "250" hw.em.tx_abs_int_delay =3D "250" hw.em.rx_abs_int_delay =3D "250" hw.em.enable_msix =3D "0" hw.em.msix_queues =3D "2" hw.em.rx_process_limit =3D "-1" hw.em.fc_setting =3D "0" hw.em.num_queues =3D 1 I tried several variations, but also without success. My infrastructure: (7301 cisco router) ------ em1 (pfsense bridge0) em2 ------ sw core cisco catalyst I tried also a fresh installation of pfsense 2.0.3 without success. My network card is an Intel =AE PRO/1000 MT Dual Port Server Adapter PCI-X = on a 32-bit PCI slot, operating bridge in 1 <-> em2. Motherboard ASUS P8H61-V and CPU corei5, I tried disabling all onboard devices, also without success. I have 4 nics identical, tested one per one all without success also. I am using the latest bios from ASUS site, I tried various combinations of bios, also without success. I tried to activate the device polling unsuccessfully to solve the problem. I tried disable acpi on boot menu but the ser without acpi wont boot. I tried disable TOE, FLOW CONTROL, no sucess. This is a link to a troughput 60 Mbits with multiple VLANs (more than 200) Wisp provider. I tested the same server same hardware but using linux (debian 6) did the bridges, and everything worked properly!, so it is clear that this is a problem software (in intel em driver?) Tested on another server (P5VD2MX + Core2Duo) but with the same NIC, and the problem occurs in the same way. I realized that it generates a huge number of interruptions em2 over 200 thousand. #vmstat -i interrupt total rate irq16: em1 12891 40 irq17: em2 546630 1713 irq19: atapci0 5181 16 irq23: ehci0 ehci1 1049 3 cpu0: timer 637069 1997 irq256: em0 1557 4 cpu3: timer 636939 1996 cpu2: timer 636939 1996 cpu1: timer 636938 1996 Total 3115193 9765 Data for debug: [2.0.3-RELEASE] [root@pfsense.localdomain] / root (1): sysctl hw.em hw.em.eee_setting: 0 hw.em.rx_process_limit: 100 hw.em.enable_msix: 0 hw.em.sbp: 0 hw.em.smart_pwr_down: 0 hw.em.txd: 4096 hw.em.rxd: 4096 hw.em.rx_abs_int_delay: 66 hw.em.tx_abs_int_delay: 66 hw.em.rx_int_delay: 0 hw.em.tx_int_delay: 0 [2.0.3-RELEASE] [root@pfsense.localdomain] / root (3): sysctl dev.em.2 dev.em.2.% desc: Intel (R) PRO/1000 Legacy Network Connection 1.0.4 dev.em.2.% driver: in dev.em.2.% location: slot =3D 0 function =3D 1 dev.em.2.% pnpinfo: vendor =3D 0x8086 device =3D 0x1079 subvendor =3D 0x808= 6 subdevice =3D 0x1179 class =3D 0x020000 dev.em.2.% parent: PCI4 dev.em.2.nvm: -1 dev.em.2.rx_int_delay: 0 dev.em.2.tx_int_delay: 0 dev.em.2.rx_abs_int_delay: 66 dev.em.2.tx_abs_int_delay: 66 dev.em.2.rx_processing_limit: 100 dev.em.2.flow_control: 0 dev.em.2.mbuf_alloc_fail: 0 dev.em.2.cluster_alloc_fail: 0 dev.em.2.dropped: 0 dev.em.2.tx_dma_fail: 0 dev.em.2.tx_desc_fail1: 0 dev.em.2.tx_desc_fail2: 0 dev.em.2.rx_overruns: 0 dev.em.2.watchdog_timeouts: 0 dev.em.2.device_control: 1076888137 dev.em.2.rx_control: 32794 dev.em.2.fc_high_water: 47104 dev.em.2.fc_low_water: 45604 dev.em.2.fifo_workaround: 0 dev.em.2.fifo_reset: 0 dev.em.2.txd_head: 243 dev.em.2.txd_tail: 243 dev.em.2.rxd_head: 1374 dev.em.2.rxd_tail: 1373 dev.em.2.mac_stats.excess_coll: 0 dev.em.2.mac_stats.single_coll: 0 dev.em.2.mac_stats.multiple_coll: 0 dev.em.2.mac_stats.late_coll: 0 dev.em.2.mac_stats.collision_count: 0 dev.em.2.mac_stats.symbol_errors: 0 dev.em.2.mac_stats.sequence_errors: 0 dev.em.2.mac_stats.defer_count: 0 dev.em.2.mac_stats.missed_packets: 0 dev.em.2.mac_stats.recv_no_buff: 0 dev.em.2.mac_stats.recv_undersize: 0 dev.em.2.mac_stats.recv_fragmented: 0 dev.em.2.mac_stats.recv_oversize: 0 dev.em.2.mac_stats.recv_jabber: 0 dev.em.2.mac_stats.recv_errs: 0 dev.em.2.mac_stats.crc_errs: 0 dev.em.2.mac_stats.alignment_errs: 0 dev.em.2.mac_stats.coll_ext_errs: 0 dev.em.2.mac_stats.xon_recvd: 0 dev.em.2.mac_stats.xon_txd: 0 dev.em.2.mac_stats.xoff_recvd: 0 dev.em.2.mac_stats.xoff_txd: 0 dev.em.2.mac_stats.total_pkts_recvd: 6681156 dev.em.2.mac_stats.good_pkts_recvd: 6681156 dev.em.2.mac_stats.bcast_pkts_recvd: 17313 dev.em.2.mac_stats.mcast_pkts_recvd: 156511 dev.em.2.mac_stats.rx_frames_64: 1199707 dev.em.2.mac_stats.rx_frames_65_127: 2110104 dev.em.2.mac_stats.rx_frames_128_255: 396 862 dev.em.2.mac_stats.rx_frames_256_511: 196001 dev.em.2.mac_stats.rx_frames_512_1023: 138581 dev.em.2.mac_stats.rx_frames_1024_1522: 2639901 dev.em.2.mac_stats.good_octets_recvd: 4439337234 dev.em.2.mac_stats.good_octets_txd: 15529 dev.em.2.mac_stats.total_pkts_txd: 143 dev.em.2.mac_stats.good_pkts_txd: 143 dev.em.2.mac_stats.bcast_pkts_txd: 104 dev.em.2.mac_stats.mcast_pkts_txd: 39 dev.em.2.mac_stats.tx_frames_64: 48 dev.em.2.mac_stats.tx_frames_65_127: 69 dev.em.2.mac_stats.tx_frames_128_255: 20 dev.em.2.mac_stats.tx_frames_256_511: 6 dev.em.2.mac_stats.tx_frames_512_1023: 0 dev.em.2.mac_stats.tx_frames_1024_1522: 0 dev.em.2.mac_stats.tso_txd: 0 dev.em.2.mac_stats.tso_ctx_fail: 0 #uname -a FreeBSD pfsense.localdomain 8.1-RELEASE-p13 FreeBSD 8.1-RELEASE-p13 #1: Fri Apr 12 10:58:43 EDT 2013 root@snapshots-8_1-amd64.builders.pfsense.org:/usr/obj.pfSense/usr/pfSenses= rc/src/sys/pfSense_SMP.8 amd64 # Pciconf-lvc: em1 @ pci0: 4:0:0: class =3D 0x020000 card =3D 0x11798086 chip =3D 0x107980= 86 rev =3D 0x03 hdr =3D 0x00 class =3D network subclass =3D ethernet cap 01 [dc] =3D powerspec 2 supports D0 D3 current D0 cap 07 [e4] =3D PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split transaction em2 @ pci0: 4:0:1: class =3D 0x020000 card =3D 0x11798086 chip =3D 0x107980= 86 rev =3D 0x03 hdr =3D 0x00 class =3D network subclass =3D ethernet cap 01 [dc] =3D powerspec 2 supports D0 D3 current D0 cap 07 [e4] =3D PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split transaction dmesg Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.1-RELEASE-p13 #1: Fri Apr 12 10:58:43 EDT 2013 root@snapshots-8_1-amd64.builders.pfsense.org:/usr/obj.pfSense/usr/pfSe= nsesrc/src/sys/pfSense_SMP.8 amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM) i5-2310 CPU @ 2.90GHz (2892.73-MHz K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0x206a7 Family =3D 6 Model =3D 2a St= epping =3D 7 Features=3D0xbfebfbff Features2=3D0x179ae3bf,SSE4.1,SSE4.2,POPCNT,,AESNI,XSAVE,> AMD Features=3D0x28100800 AMD Features2=3D0x1 TSC: P-state invariant real memory =3D 8589934592 (8192 MB) avail memory =3D 7952838656 (7584 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 ioapic0 irqs 0-23 on motherboard wlan: mac acl policy registered kbd1 at kbdmux0 cryptosoft0: on motherboard padlock0: No ACE support. acpi0: on motherboard acpi0: [ITHREAD] ACPI Error (psargs-0464): [RAMB] Namespace lookup failure, AE_NOT_FOUND ACPI Exception: AE_NOT_FOUND, Could not execute arguments for [RAMW] (Region) (20100331/nsinit-442) acpi0: Power Button (fixed) acpi0: reservation of 67, 1 (4) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xf000-0xf03f mem 0xf7800000-0xf7bfffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 pci0: at device 22.0 (no driver attached) ehci0: mem 0xf7f04000-0xf7f043ff irq 23 at device 26.0 on pci0 ehci0: [ITHREAD] usbus0: EHCI version 1.0 usbus0: on ehci0 pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 em0: port 0xe000-0xe01f mem 0xf7e20000-0xf7e3ffff,0xf7e00000-0xf7e1ffff irq 16 at device 0.0 on pci2 em0: Using an MSI interrupt em0: [FILTER] pcib3: irq 16 at device 28.4 on pci0 pci3: on pcib3 pcib4: irq 16 at device 0.0 on pci3 pci4: on pcib4 em1: port 0xd040-0xd07f mem 0xf7d20000-0xf7d3ffff,0xf7cc0000-0xf7cfffff irq 16 at device 0.0 on pci= 4 em1: [FILTER] em2: port 0xd000-0xd03f mem 0xf7d00000-0xf7d1ffff,0xf7c40000-0xf7c7ffff irq 17 at device 0.1 on pci= 4 em2: [FILTER] ehci1: mem 0xf7f03000-0xf7f033ff irq 23 at device 29.0 on pci0 ehci1: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci1 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xf0b0-0xf0b7,0xf0a0-0xf0a3,0xf090-0xf097,0xf080-0xf083,0xf060-0xf07f mem 0xf7f02000-0xf7f027ff irq 19 at device 31.2 on pci0 atapci0: [ITHREAD] atapci0: AHCI v1.30 controller with 4 3Gbps ports, PM not supported ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 acpi_tz0: on acpi0 acpi_tz1: on acpi0 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: cannot reserve I/O port range coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 coretemp2: on cpu2 est2: on cpu2 p4tcc2: on cpu2 coretemp3: on cpu3 est3: on cpu3 p4tcc3: on cpu3 Timecounters tick every 1.000 msec IPsec: Initialized Security Association Processing. usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ad4: 476940MB at ata2-master UDMA100 SATA 3Gb/s ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 acd0: DVDR at ata3-master UDMA100 SATA 1.5Gb/s SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! Root mount waiting for: usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered Root mount waiting for: usbus1 usbus0 ugen0.2: at usbus0 uhub2: on usbus0 ugen1.2: at usbus1 uhub3: on usbus1 Root mount waiting for: usbus1 usbus0 uhub2: 4 ports with 4 removable, self powered uhub3: 6 ports with 6 removable, self powered ugen0.3: at usbus0 ukbd0: on usbus0 kbd2 at ukbd0 uhid0: on usbus0 Trying to mount root from ufs:/dev/ad4s1a pflog0: promiscuous mode enabled em2: link state changed to UP bridge0: promiscuous mode enabled pflog0: promiscuous mode disabled Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 0 done All buffers synced. Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.1-RELEASE-p13 #1: Fri Apr 12 10:58:43 EDT 2013 root@snapshots-8_1-amd64.builders.pfsense.org:/usr/obj.pfSense/usr/pfSe= nsesrc/src/sys/pfSense_SMP.8 amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM) i5-2310 CPU @ 2.90GHz (2892.72-MHz K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0x206a7 Family =3D 6 Model =3D 2a St= epping =3D 7 Features=3D0xbfebfbff Features2=3D0x179ae3bf,SSE4.1,SSE4.2,POPCNT,,AESNI,XSAVE,> AMD Features=3D0x28100800 AMD Features2=3D0x1 TSC: P-state invariant real memory =3D 8589934592 (8192 MB) avail memory =3D 7952838656 (7584 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 ioapic0 irqs 0-23 on motherboard wlan: mac acl policy registered kbd1 at kbdmux0 cryptosoft0: on motherboard padlock0: No ACE support. acpi0: on motherboard acpi0: [ITHREAD] ACPI Error (psargs-0464): [RAMB] Namespace lookup failure, AE_NOT_FOUND ACPI Exception: AE_NOT_FOUND, Could not execute arguments for [RAMW] (Region) (20100331/nsinit-442) acpi0: Power Button (fixed) acpi0: reservation of 67, 1 (4) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xf000-0xf03f mem 0xf7800000-0xf7bfffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 pci0: at device 22.0 (no driver attached) ehci0: mem 0xf7f04000-0xf7f043ff irq 23 at device 26.0 on pci0 ehci0: [ITHREAD] usbus0: EHCI version 1.0 usbus0: on ehci0 pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 em0: port 0xe000-0xe01f mem 0xf7e20000-0xf7e3ffff,0xf7e00000-0xf7e1ffff irq 16 at device 0.0 on pci2 em0: Using an MSI interrupt em0: [FILTER] pcib3: irq 16 at device 28.4 on pci0 pci3: on pcib3 pcib4: irq 16 at device 0.0 on pci3 pci4: on pcib4 em1: port 0xd040-0xd07f mem 0xf7d20000-0xf7d3ffff,0xf7cc0000-0xf7cfffff irq 16 at device 0.0 on pci= 4 em1: [FILTER] em2: port 0xd000-0xd03f mem 0xf7d00000-0xf7d1ffff,0xf7c40000-0xf7c7ffff irq 17 at device 0.1 on pci= 4 em2: [FILTER] ehci1: mem 0xf7f03000-0xf7f033ff irq 23 at device 29.0 on pci0 ehci1: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci1 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xf0b0-0xf0b7,0xf0a0-0xf0a3,0xf090-0xf097,0xf080-0xf083,0xf060-0xf07f mem 0xf7f02000-0xf7f027ff irq 19 at device 31.2 on pci0 atapci0: [ITHREAD] atapci0: AHCI v1.30 controller with 4 3Gbps ports, PM not supported ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 acpi_tz0: on acpi0 acpi_tz1: on acpi0 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: cannot reserve I/O port range coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 coretemp2: on cpu2 est2: on cpu2 p4tcc2: on cpu2 coretemp3: on cpu3 est3: on cpu3 p4tcc3: on cpu3 Timecounters tick every 1.000 msec IPsec: Initialized Security Association Processing. usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ad4: 476940MB at ata2-master UDMA100 SATA 3Gb/s ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 acd0: DVDR at ata3-master UDMA100 SATA 1.5Gb/s SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #1 Launched! Root mount waiting for: usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered Root mount waiting for: usbus1 usbus0 ugen0.2: at usbus0 uhub2: on usbus0 ugen1.2: at usbus1 uhub3: on usbus1 uhub2: 4 ports with 4 removable, self powered uhub3: 6 ports with 6 removable, self powered Root mount waiting for: usbus0 ugen0.3: at usbus0 ukbd0: on usbus0 kbd2 at ukbd0 uhid0: on usbus0 Trying to mount root from ufs:/dev/ad4s1a pflog0: promiscuous mode enabled em2: link state changed to UP bridge0: promiscuous mode enabled From owner-freebsd-net@FreeBSD.ORG Wed May 22 12:56:03 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DF1E987D for ; Wed, 22 May 2013 12:56:03 +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 A93C1D7E for ; Wed, 22 May 2013 12:56:00 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 7413D7300A; Wed, 22 May 2013 14:58:28 +0200 (CEST) Date: Wed, 22 May 2013 14:58:28 +0200 From: Luigi Rizzo To: net@freebsd.org Subject: RFC: removing redundant checks in ether_input_internal() Message-ID: <20130522125828.GA93728@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 12:56:03 -0000 if_ethersubr.c :: ether_input_internal() is only called as follows: static void ether_nh_input(struct mbuf *m) { ether_input_internal(m->m_pkthdr.rcvif, m); } hence the following checks in the body are unnecessary: if (m->m_pkthdr.rcvif == NULL) { if_printf(ifp, "discard frame w/o interface pointer\n"); ifp->if_ierrors++; m_freem(m); return; } #ifdef DIAGNOSTIC if (m->m_pkthdr.rcvif != ifp) { if_printf(ifp, "Warning, frame marked as received on %s\n", m->m_pkthdr.rcvif->if_xname); } #endif Any objection if i remove them ? cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed May 22 14:53:43 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 56E3B9DA for ; Wed, 22 May 2013 14:53:43 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id C392C9EE for ; Wed, 22 May 2013 14:53:42 +0000 (UTC) Received: (qmail 40198 invoked from network); 22 May 2013 15:53:20 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 22 May 2013 15:53:20 -0000 Message-ID: <519CDBE9.304@freebsd.org> Date: Wed, 22 May 2013 16:53:29 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: RFC: removing redundant checks in ether_input_internal() References: <20130522125828.GA93728@onelab2.iet.unipi.it> In-Reply-To: <20130522125828.GA93728@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 14:53:43 -0000 On 22.05.2013 14:58, Luigi Rizzo wrote: > if_ethersubr.c :: ether_input_internal() is only called as follows: > > static void > ether_nh_input(struct mbuf *m) > { > > ether_input_internal(m->m_pkthdr.rcvif, m); > } > > hence the following checks in the body are unnecessary: > > if (m->m_pkthdr.rcvif == NULL) { > if_printf(ifp, "discard frame w/o interface pointer\n"); > ifp->if_ierrors++; > m_freem(m); > return; > } > #ifdef DIAGNOSTIC > if (m->m_pkthdr.rcvif != ifp) { > if_printf(ifp, "Warning, frame marked as received on %s\n", > m->m_pkthdr.rcvif->if_xname); > } > #endif > > Any objection if i remove them ? No, but they should remain as KASSERTs. None of these should trigger in production and all of them are an indication that something is very wrong with the packet or the caller. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed May 22 15:39:09 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3F495293 for ; Wed, 22 May 2013 15:39:09 +0000 (UTC) (envelope-from wonko@4amlunch.net) Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) by mx1.freebsd.org (Postfix) with ESMTP id 1EF64E9B for ; Wed, 22 May 2013 15:39:08 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id x10so1712364pdj.15 for ; Wed, 22 May 2013 08:39:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:x-useless-header:user-agent:x-gm-message-state; bh=vVFkF/r8+xz9s1YUz1jnCrrzanTz+Kl5jmUtxiqOJnI=; b=D6h6caAOABcuCxSU4g/H2O3sffXvs1SQRji/r3nbuHaSPY6Hu2QYlgyC/YWsGvn9Eu QTEM5Xw/X62sqYHIAVu5erQZAaZTgK2yD7LwxLXw5TRCw5LaoRY+CD8QT8SM6bz/HmuV OBHOSuJ0pl6zzhYtubWKb6JWZYOSrc8De9rt91I1hfJR+sf4/xSKM1A5IvG4FXQEQVU9 OxUmaSkFVPx8NYd6AkUpn/b+mWXy3rS/Hbvm9p/AJ0yDay2qTbec8e+1ftSq++aPzVb3 XZRs/VrcxQ8fyVFSvirRA2jBOfZf4jTzh48MiuEytBKHH2JhpMzM9MSNvjnTZ+ZEdv0r GFmQ== X-Received: by 10.68.132.34 with SMTP id or2mr8319822pbb.99.1369237147954; Wed, 22 May 2013 08:39:07 -0700 (PDT) Received: from wiggum (wiggum.4amlunch.net. [65.19.130.45]) by mx.google.com with ESMTPSA id 3sm7644425pbj.46.2013.05.22.08.39.06 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 22 May 2013 08:39:07 -0700 (PDT) Date: Wed, 22 May 2013 11:39:05 -0400 From: Brian Hechinger To: freebsd-net@freebsd.org Subject: GRE and BPF Message-ID: <20130522153905.GP887@wiggum> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Useless-Header: Why? Because i can. User-Agent: Mutt/1.5.21 (2010-09-15) X-Gm-Message-State: ALoCoQmD3gPbOcIyNzYus6tp5dXyZALfk5a+96+ACM9MGRMAN0X0cL1vqGDePaFts/eUbmu8jTBD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 15:39:09 -0000 Hello all, I've been having some trouble with a GRE tunnel. Specifically with non-IP traffic (DECnet, in this case) and BPF. I can see the GRE packets containing the DECnet packets coming over the physical interface but when I do a tcpdump of bge0 I never see them. This is an issue because the program I want to use will be using pcap to pull packets off of the bge0 interface. I can get IP packets off of the bge0 interface with tcpdump, however. Is this just never going to work or am I missing something here? The other end is a Cisco is it really matters. I'm running: FreeBSD wiggum 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243826: Tue Dec 4 06:55:39 UTC 2012 root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 Thanks! -brian From owner-freebsd-net@FreeBSD.ORG Wed May 22 15:48:42 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CDEDA5A4 for ; Wed, 22 May 2013 15:48:42 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by mx1.freebsd.org (Postfix) with ESMTP id 9E849F27 for ; Wed, 22 May 2013 15:48:42 +0000 (UTC) Received: by mail-oa0-f50.google.com with SMTP id l20so2891424oag.9 for ; Wed, 22 May 2013 08:48:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=cnCvfT/JDI4ke8/qj37TtGgjVcY1yqpZ4vGE+gGFlw0=; b=ORd2Hq/EM1nMnkrMIOaP69DVbQhqfckV8tvMHg2PecHhxUTxGZu4WUFyMud35YZz4j sKcMIQY8jr4FeUTCLt5O7DBclcHEtHmQko643E0PYszWd+qDJs5CHtRLU5xKVkZRNHr4 DSIU8irquJpzRh9xnbaibGgx4MgKN7MI1JmYhx8NYDMQXzVK+oB8zXjVv0rAPAa5IbX+ G7nU/8l8W0eK4IJWVDLXNpriaogBAyYDKZaTKQglZzprf+XJABHEageNgcV7FUP7HKxw Pctys0g0MGPxHob/Q957LGKq+Q1f58FbxbhS3P2VY+uW/aNjvxiXq8a+TnRyvmlc9LZZ aJrg== MIME-Version: 1.0 X-Received: by 10.60.142.103 with SMTP id rv7mr5302068oeb.34.1369237716488; Wed, 22 May 2013 08:48:36 -0700 (PDT) Received: by 10.60.35.132 with HTTP; Wed, 22 May 2013 08:48:36 -0700 (PDT) In-Reply-To: <20130522153905.GP887@wiggum> References: <20130522153905.GP887@wiggum> Date: Wed, 22 May 2013 08:48:36 -0700 Message-ID: Subject: Re: GRE and BPF From: Michael Sierchio To: "freebsd-net@freebsd.org" X-Gm-Message-State: ALoCoQlBBvG7LUZJslGbRMud02b392V22EpxhX6mWqm9DoPisoWo6LcN9z3JqOaB0McirTwCjQK4 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 15:48:42 -0000 On Wed, May 22, 2013 at 8:39 AM, Brian Hechinger wrote: > Hello all, > > I've been having some trouble with a GRE tunnel. Specifically with > non-IP traffic (DECnet, in this case) and BPF. > > I can see the GRE packets containing the DECnet packets coming over the > physical interface but when I do a tcpdump of bge0 I never see them. > > This is an issue because the program I want to use will be using pcap to > pull packets off of the bge0 interface. > > I can get IP packets off of the bge0 interface with tcpdump, however. > > Is this just never going to work or am I missing something here? > > What does ifconfig report for the MTU of the gre interface? Does it match the Cisco? Is grekey set? Do you have a route to the network that is encapsulated on the other side? is net.inet.ip.forwarding set to 1? - M From owner-freebsd-net@FreeBSD.ORG Wed May 22 15:54:40 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7CF8383D for ; Wed, 22 May 2013 15:54:40 +0000 (UTC) (envelope-from wonko@4amlunch.net) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) by mx1.freebsd.org (Postfix) with ESMTP id 5ABA1F9A for ; Wed, 22 May 2013 15:54:40 +0000 (UTC) Received: by mail-pd0-f179.google.com with SMTP id q11so1830189pdj.38 for ; Wed, 22 May 2013 08:54:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-useless-header :user-agent:x-gm-message-state; bh=WudUE93ZmTCaQLI4DA9BP4HgELwWr6s2xcnnNBw6o8U=; b=dcrAv05Gby0qpL1NEFvQzlMHrVaFRL4w0604MHwoHWoAm65BVOn4YWcTl9mC//ucOl 4+P3Bs31u/28zANfk+11D1Q5hF7eFD6JwIlTCpJPdYRm8IdLeKtxetacZIuCcGzY+MPE Nhvh5150HQGqTlv3yzdulKKgUTO9pZOHSDMEOx/hQcajRwJlCG7Wk5sKdkhC+g+6zZCn Pi/gLTrNKFIlQGU+27uoc8cUNtfRlTJXxS8OgRYOekH7f7oOXwhYPeDMEFkClnLrzhO6 +OULTvYhSpYbNAHulTki969ORLShtDsilEnFnpX74fbnXpTYl/FyVfjU4OanuWm+vhMD dlDw== X-Received: by 10.66.27.174 with SMTP id u14mr4196138pag.97.1369238079828; Wed, 22 May 2013 08:54:39 -0700 (PDT) Received: from wiggum (wiggum.4amlunch.net. [65.19.130.45]) by mx.google.com with ESMTPSA id vb8sm7761908pbc.11.2013.05.22.08.54.38 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 22 May 2013 08:54:39 -0700 (PDT) Date: Wed, 22 May 2013 11:54:37 -0400 From: Brian Hechinger To: freebsd-net@freebsd.org Subject: Re: GRE and BPF Message-ID: <20130522155437.GQ887@wiggum> References: <20130522153905.GP887@wiggum> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Useless-Header: Why? Because i can. User-Agent: Mutt/1.5.21 (2010-09-15) X-Gm-Message-State: ALoCoQlPwfVCvclUR+QfgrtBROl33R9AqF0UrTN2pt5rB4dCAKjWyfIC/P50ZowewBWl+grs1bLU X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 15:54:40 -0000 On Wed, May 22, 2013 at 08:48:36AM -0700, Michael Sierchio wrote: > On Wed, May 22, 2013 at 8:39 AM, Brian Hechinger wrote: > > > Hello all, > > > > I've been having some trouble with a GRE tunnel. Specifically with > > non-IP traffic (DECnet, in this case) and BPF. > > > > I can see the GRE packets containing the DECnet packets coming over the > > physical interface but when I do a tcpdump of bge0 I never see them. > > > > This is an issue because the program I want to use will be using pcap to > > pull packets off of the bge0 interface. > > > > I can get IP packets off of the bge0 interface with tcpdump, however. > > > > Is this just never going to work or am I missing something here? > > > > > What does ifconfig report for the MTU of the gre interface? Does it match > the Cisco? Is grekey set? On the Cisco: Tunnel transport MTU 1476 bytes On the FreeBSD box: gre0: flags=9051 metric 0 mtu 1476 No grekey set. > Do you have a route to the network that is encapsulated on the other side? It will once communication is established. DECnet does dynamic routing. > is net.inet.ip.forwarding set to 1? I don't see how that's relevant unless that turns on some sort of magic? I'm not trying to do IP forwarding at all. In fact, I'm not trying to do any forwarding. I have a user mode application that just wants to read and write packets off the the GRE tunnel. -brian From owner-freebsd-net@FreeBSD.ORG Wed May 22 16:40:10 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F2E3592E for ; Wed, 22 May 2013 16:40:09 +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 BC4C8323 for ; Wed, 22 May 2013 16:40:09 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 2050C7300A; Wed, 22 May 2013 18:42:44 +0200 (CEST) Date: Wed, 22 May 2013 18:42:44 +0200 From: Luigi Rizzo To: net@freebsd.org Subject: surprise surprise (VM related) [luigi@FreeBSD.org: svn commit: r250911 - head/sys/kern] Message-ID: <20130522164244.GB95808@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 16:40:10 -0000 all that work on paravirtualization (as presented at bsdcan) http://info.iet.unipi.it/~luigi/netmap/talk-bsdcan-2013.html just to discover that simply enabling DEVICE_POLLING (10-years old technology) gives the same performance gains plus livelock-avoidance. And no, linux's NAPI is nowhere near us. cheers luigi ----- Forwarded message from Luigi Rizzo ----- Date: Wed, 22 May 2013 16:32:18 +0000 (UTC) From: Luigi Rizzo Subject: svn commit: r250911 - head/sys/kern To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Author: luigi Date: Wed May 22 16:32:18 2013 New Revision: 250911 URL: http://svnweb.freebsd.org/changeset/base/250911 Log: Increase the (arbitrary) limit for the number of packets per tick from 1k to 20k The previous value was good 10 years ago, but not anymore now. More importantly, lots of good surprises: polling is incredibly effective under virtualization, and not only prevents livelock but also saves most of the VM exit overhead in receive mode. Using polling, a FreeBSD instance under qemu-kvm remains perfectly responsive even when bombed with 10 Mpps over an emulated e1000, and happily processes 1.7 Mpps through ipfw. Note that some incompatibilities still remain: e.g. polling is not (yet) compatible with netmap, and seems to freeze the guest when kern.polling.idle_poll=1 MFC after: 3 days Modified: head/sys/kern/kern_poll.c Modified: head/sys/kern/kern_poll.c ============================================================================== --- head/sys/kern/kern_poll.c Wed May 22 15:15:05 2013 (r250910) +++ head/sys/kern/kern_poll.c Wed May 22 16:32:18 2013 (r250911) @@ -87,12 +87,11 @@ static struct mtx poll_mtx; * The following constraints hold * * 1 <= poll_each_burst <= poll_burst <= poll_burst_max - * 0 <= poll_each_burst * MIN_POLL_BURST_MAX <= poll_burst_max <= MAX_POLL_BURST_MAX */ #define MIN_POLL_BURST_MAX 10 -#define MAX_POLL_BURST_MAX 1000 +#define MAX_POLL_BURST_MAX 20000 static uint32_t poll_burst = 5; static uint32_t poll_burst_max = 150; /* good for 100Mbit net and HZ=1000 */ ----- End forwarded message ----- From owner-freebsd-net@FreeBSD.ORG Wed May 22 19:08:38 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8CCB6104 for ; Wed, 22 May 2013 19:08:38 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 51CA1F94 for ; Wed, 22 May 2013 19:08:38 +0000 (UTC) Received: by mail-ob0-f172.google.com with SMTP id tb18so2884368obb.17 for ; Wed, 22 May 2013 12:08:37 -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=dh6uJ1JpyUnEa6jv9B4knZaTo3aq496zn44X3ESl0xM=; b=TzShzo1PrmW8LTF7ouPVYfsKnPf5HW3RkNATYU0aS3WCsU7lKWc3AlIrlsfx8Y/UDe fd15luS14yQDIQWbBw7ralPyEEZE+oxBpw2QjsjPK7BhlZH9HR3zV6a47rdXoSjl1IVS Wvek7yIvQCMtr/8f+WSk448wIoF4BedSCyRhVEvZmvUvIIMKlgMnQYadX4miCJ6yqhL+ CefZ2wygCrAAsI6GVdft2vcn2/RBd8jF+T9tm2++DFUgNNhMnuaWTYyduA/v5bCibW9t M0FwyYh/kXyTjygiF2C7beCs++EMNqB7yWO8ZlHCaMQKT6SgwcNFlekU4VnfLECAeVwF yEKg== MIME-Version: 1.0 X-Received: by 10.60.131.6 with SMTP id oi6mr5879458oeb.19.1369249717783; Wed, 22 May 2013 12:08:37 -0700 (PDT) Received: by 10.76.90.10 with HTTP; Wed, 22 May 2013 12:08:37 -0700 (PDT) In-Reply-To: <20130522164244.GB95808@onelab2.iet.unipi.it> References: <20130522164244.GB95808@onelab2.iet.unipi.it> Date: Wed, 22 May 2013 15:08:37 -0400 Message-ID: Subject: Re: surprise surprise (VM related) [luigi@FreeBSD.org: svn commit: r250911 - head/sys/kern] From: Ryan Stone To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 19:08:38 -0000 On Wed, May 22, 2013 at 12:42 PM, Luigi Rizzo wrote: > all that work on paravirtualization (as presented at bsdcan) > > http://info.iet.unipi.it/~luigi/netmap/talk-bsdcan-2013.html > > just to discover that simply enabling DEVICE_POLLING (10-years old > technology) gives the same performance gains plus livelock-avoidance. > > And no, linux's NAPI is nowhere near us. > > cheers > luigi > A couple of years ago I started working on upstreaming some DEVICE_POLLING improvements from $WORK that incorporated feedback from polled interfaces to drive rescheduling of a polling iteration (rather than waiting for the next hardclock() to reschedule polling) but I never finished it. It works fine, but I didn't get a chance to test performance. It's available here: https://gitorious.org/~rysto/freebsd/rystos-freebsd-head/commit/e27db681b96cced7d3128ad3268f2cbf7474925a In the same repository I also have a branch that extends DEVICE_POLLING to work with multiple netisr threads. From owner-freebsd-net@FreeBSD.ORG Wed May 22 20:52:28 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1B6D413B2 for ; Wed, 22 May 2013 20:52:28 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by mx1.freebsd.org (Postfix) with ESMTP id DD58E122 for ; Wed, 22 May 2013 20:52:27 +0000 (UTC) Received: by mail-ob0-f173.google.com with SMTP id eh20so3042646obb.32 for ; Wed, 22 May 2013 13:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=HM9+QYnUoOWsni3R5m+p0Lw8xyuVRcTdFbTHWfjKknQ=; b=X79H4GqCsSP9OkrC+4q+FsTCQWBUljZiQIgIlf6cgVfQUb16vOwkGg5uggXbJekqgE 4K6v9ygv7h0gU2Zsrfv3VjwtsVhj6YpOKP38eW3NrwBkMKlLHtDjdR+XSOnfb4fxZ8OW USfRWxq8YFSgnTCIDstfLbBWAZKYF46+bxoe7MBR3FN6SKsSEj1K5jgN+vPbE+kykSiB mVcIvB1xBdVP8UH5yQpTcEihbPHDLs2uU/XHWxMbpaZKc+WRoc9ndUsG2Rpw7yH1sho4 cr5Bk4iDtgf1jFoc9y38QmDrv3JM0epiPuHXSmR7doWMf4ZN1e1BKkfk51nr8oKH6/0d oRLg== X-Received: by 10.60.79.231 with SMTP id m7mr6437384oex.105.1369255947528; Wed, 22 May 2013 13:52:27 -0700 (PDT) Received: from gloom.sandvine.com ([64.7.137.182]) by mx.google.com with ESMTPSA id jt1sm9426426oeb.5.2013.05.22.13.52.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 May 2013 13:52:26 -0700 (PDT) Sender: Mark Johnston Date: Wed, 22 May 2013 16:52:14 -0400 From: Mark Johnston To: Giorgio Emanuel Subject: Re: em2: watchdog timeout - resetting Message-ID: <20130522205214.GE4748@gloom.sandvine.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 20:52:28 -0000 On Wed, May 22, 2013 at 12:05:31AM -0300, Giorgio Emanuel wrote: > Hello, I have a server pfsense in bridge mode to function as transparent > FW, the problem is that once I connect the pfsense between my router core > and my core switch catalyst a few seconds begin to appear several messages > like these: > > em2: watchdog timeout - resetting > em2: watchdog timeout - resetting > em2: watchdog timeout - resetting > em2: watchdog timeout - resetting > > And the connection falls back repeatedly and indefinitely. > Searching on google did some tweaks: > > hw.em.rxd = "4096" > hw.em.txd = "4096" > hw.em.tx_int_delay = "250" > hw.em.rx_int_delay = "250" > hw.em.tx_abs_int_delay = "250" > hw.em.rx_abs_int_delay = "250" > hw.em.enable_msix = "0" > hw.em.msix_queues = "2" > hw.em.rx_process_limit = "-1" > hw.em.fc_setting = "0" > hw.em.num_queues = 1 > > I tried several variations, but also without success. > > My infrastructure: > > (7301 cisco router) ------ em1 (pfsense bridge0) em2 ------ sw core cisco > catalyst > > I tried also a fresh installation of pfsense 2.0.3 without success. > My network card is an Intel ® PRO/1000 MT Dual Port Server Adapter PCI-X on > a 32-bit PCI slot, operating bridge in 1 <-> em2. > Motherboard ASUS P8H61-V and CPU corei5, I tried disabling all onboard > devices, also without success. > I have 4 nics identical, tested one per one all without success also. > I am using the latest bios from ASUS site, I tried various combinations of > bios, also without success. > I tried to activate the device polling unsuccessfully to solve the problem. > I tried disable acpi on boot menu but the ser without acpi wont boot. > I tried disable TOE, FLOW CONTROL, no sucess. > > This is a link to a troughput 60 Mbits with multiple VLANs (more than 200) > Wisp provider. > I tested the same server same hardware but using linux (debian 6) did the > bridges, and everything worked properly!, so it is clear that this is a > problem software (in intel em driver?) > Tested on another server (P5VD2MX + Core2Duo) but with the same NIC, and > the problem occurs in the same way. > I realized that it generates a huge number of interruptions em2 over 200 > thousand. Are you using TSO on the interface? Does the problem go away if you disable it? (ifconfig em2 -tso) I ask because I had to backport the patch below to FreeBSD 8.2 at work; I was seeing tx watchdog timeouts when TSO and hardware VLAN tagging were combined in em(4). It looks like pfSense 2.0.3 is based on FreeBSD 8.1, so unless they've already backported this fix (which is a subset of r228387), you may be running into the same issue. -Mark Index: sys/dev/e1000/if_em.c =================================================================== --- sys/dev/e1000/if_em.c (revision 250913) +++ sys/dev/e1000/if_em.c (working copy) @@ -1963,6 +1963,14 @@ em_transmit_checksum_setup(txr, m_head, ip_off, ip, &txd_upper, &txd_lower); + if (m_head->m_flags & M_VLANTAG) { + /* Set the vlan id. */ + txd_upper |= + (htole16(m_head->m_pkthdr.ether_vtag) << 16); + /* Tell hardware to add tag */ + txd_lower |= htole32(E1000_TXD_CMD_VLE); + } + i = txr->next_avail_desc; /* Set up our transmit descriptors */ @@ -2020,14 +2028,6 @@ if (tso_desc) /* TSO used an extra for sentinel */ txr->tx_avail -= txd_used; - if (m_head->m_flags & M_VLANTAG) { - /* Set the vlan id. */ - ctxd->upper.fields.special = - htole16(m_head->m_pkthdr.ether_vtag); - /* Tell hardware to add tag */ - ctxd->lower.data |= htole32(E1000_TXD_CMD_VLE); - } - tx_buffer->m_head = m_head; tx_buffer_mapped->map = tx_buffer->map; tx_buffer->map = map; From owner-freebsd-net@FreeBSD.ORG Wed May 22 21:06:41 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BF835180E for ; Wed, 22 May 2013 21:06:41 +0000 (UTC) (envelope-from havenster@gmail.com) Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by mx1.freebsd.org (Postfix) with ESMTP id 9F598350 for ; Wed, 22 May 2013 21:06:41 +0000 (UTC) Received: by mail-pd0-f181.google.com with SMTP id bv13so287039pdb.12 for ; Wed, 22 May 2013 14:06:41 -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=btR2bgMiZiBHu3MGDC0R5xDrr3vM261F5SLq4HpwrS0=; b=rrs6fZnGpelz+0n+CuWjtxVFwWWTN5ikuLoQOvyk6heBlghqC9cfemRu9Guuh56Od6 NHvkg/vPc/Npyii0pOyQwY1+ff2GuhdQcJenpicHlb3pFauPsmEfHQP/oVi1juZbOwC5 i6jIw8sAeKf4nHNpvJX9ltp4yxGV1VWFvMQEd3p31qigA8Je6eIE3tnooQQ7rfR7BgrE 5OOeGM/V+fUd5jzqnNTVMR43aeajx32Cniw5/roXt4QMU6rbMIAfgnHkPqrv7Br4cYiB 5NnsekUIFVk/YOt/dDTr5B8HrBz4ZQ5V8R0DS5zN2nucS/AKeydUpAeNIP/zWpiFguj+ U30A== MIME-Version: 1.0 X-Received: by 10.68.190.131 with SMTP id gq3mr9813260pbc.185.1369256800893; Wed, 22 May 2013 14:06:40 -0700 (PDT) Received: by 10.70.46.106 with HTTP; Wed, 22 May 2013 14:06:40 -0700 (PDT) In-Reply-To: <20130522164244.GB95808@onelab2.iet.unipi.it> References: <20130522164244.GB95808@onelab2.iet.unipi.it> Date: Wed, 22 May 2013 14:06:40 -0700 Message-ID: Subject: Re: surprise surprise (VM related) [luigi@FreeBSD.org: svn commit: r250911 - head/sys/kern] From: Haven Hash To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 21:06:41 -0000 I notice the commentary by poll_burst_max stating it's suitability to 100Mbit net, perhaps that could use an increase in its default value as well? On Wed, May 22, 2013 at 9:42 AM, Luigi Rizzo wrote: > all that work on paravirtualization (as presented at bsdcan) > > http://info.iet.unipi.it/~luigi/netmap/talk-bsdcan-2013.html > > just to discover that simply enabling DEVICE_POLLING (10-years old > technology) gives the same performance gains plus livelock-avoidance. > > And no, linux's NAPI is nowhere near us. > > cheers > luigi > > > ----- Forwarded message from Luigi Rizzo ----- > > Date: Wed, 22 May 2013 16:32:18 +0000 (UTC) > From: Luigi Rizzo > Subject: svn commit: r250911 - head/sys/kern > To: src-committers@freebsd.org, svn-src-all@freebsd.org, > svn-src-head@freebsd.org > > Author: luigi > Date: Wed May 22 16:32:18 2013 > New Revision: 250911 > URL: http://svnweb.freebsd.org/changeset/base/250911 > > Log: > Increase the (arbitrary) limit for the number of packets per tick > from 1k to 20k The previous value was good 10 years ago, but not > anymore now. > > More importantly, lots of good surprises: > polling is incredibly effective under virtualization, and not only > prevents livelock but also saves most of the VM exit overhead in > receive mode. > > Using polling, a FreeBSD instance under qemu-kvm remains perfectly > responsive even when bombed with 10 Mpps over an emulated e1000, > and happily processes 1.7 Mpps through ipfw. > > Note that some incompatibilities still remain: e.g. polling is not > (yet) compatible with netmap, and seems to freeze the guest when > kern.polling.idle_poll=1 > > MFC after: 3 days > > Modified: > head/sys/kern/kern_poll.c > > Modified: head/sys/kern/kern_poll.c > > ============================================================================== > --- head/sys/kern/kern_poll.c Wed May 22 15:15:05 2013 (r250910) > +++ head/sys/kern/kern_poll.c Wed May 22 16:32:18 2013 (r250911) > @@ -87,12 +87,11 @@ static struct mtx poll_mtx; > * The following constraints hold > * > * 1 <= poll_each_burst <= poll_burst <= poll_burst_max > - * 0 <= poll_each_burst > * MIN_POLL_BURST_MAX <= poll_burst_max <= MAX_POLL_BURST_MAX > */ > > #define MIN_POLL_BURST_MAX 10 > -#define MAX_POLL_BURST_MAX 1000 > +#define MAX_POLL_BURST_MAX 20000 > > static uint32_t poll_burst = 5; > static uint32_t poll_burst_max = 150; /* good for 100Mbit net and > HZ=1000 */ > > ----- End forwarded message ----- > _______________________________________________ > 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 Wed May 22 21:25:57 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 716F81F09 for ; Wed, 22 May 2013 21:25:57 +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 39021827 for ; Wed, 22 May 2013 21:25:57 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id BEA427300A; Wed, 22 May 2013 23:28:31 +0200 (CEST) Date: Wed, 22 May 2013 23:28:31 +0200 From: Luigi Rizzo To: Haven Hash Subject: Re: surprise surprise (VM related) [luigi@FreeBSD.org: svn commit: r250911 - head/sys/kern] Message-ID: <20130522212831.GA744@onelab2.iet.unipi.it> References: <20130522164244.GB95808@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 21:25:57 -0000 On Wed, May 22, 2013 at 02:06:40PM -0700, Haven Hash wrote: > I notice the commentary by poll_burst_max stating it's suitability to > 100Mbit net, perhaps that could use an increase in its default value as > well? maybe later. I am not sure who is using polling and on what platforms, so i'd rather leave the defaults alone for the time being. cheers luigi From owner-freebsd-net@FreeBSD.ORG Thu May 23 08:34:02 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5C3BA3EA for ; Thu, 23 May 2013 08:34:02 +0000 (UTC) (envelope-from alexl@mellanox.com) Received: from eu1sys200aog116.obsmtp.com (eu1sys200aog116.obsmtp.com [207.126.144.141]) by mx1.freebsd.org (Postfix) with ESMTP id 55FA4D12 for ; Thu, 23 May 2013 08:33:50 +0000 (UTC) Received: from MTLCAS02.mtl.com ([193.47.165.155]) (using TLSv1) by eu1sys200aob116.postini.com ([207.126.147.11]) with SMTP ID DSNKUZ3UbV3Lq8VX3fOrqNeEH0wTKQc4ACpp@postini.com; Thu, 23 May 2013 08:33:50 UTC Received: from MTLDAG01.mtl.com ([10.0.8.75]) by MTLCAS02.mtl.com ([10.0.8.72]) with mapi id 14.03.0123.003; Thu, 23 May 2013 11:32:16 +0300 From: Alex Liptsin To: "freebsd-net@freebsd.org" Subject: Create pkey on FreeBSD 9.1 Thread-Topic: Create pkey on FreeBSD 9.1 Thread-Index: Ac5Xj0ChbAPWD1OURoemsmYlNeqHFQ== Date: Thu, 23 May 2013 08:32:16 +0000 Message-ID: <64DAB3164E410447932305F50F896D8D6AF63DB3@MTLDAG01.mtl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.13.1] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 08:34:02 -0000 Hello. I have FreeBSD 9.1 installed. There is mellanox adapter inside. OFED support is already installed. I try to add pkeys on ib0 port. Usually in Linux I did: echo 0x800c > /sys/class/net/ib0/create_child ifconfig -a To Make sure you see a new interface: ib0.800c How can I do it on FreeBSD? There is no "/sys/class/net/ib0/create_child" d= irectory. Regards, Alex Liptsin From owner-freebsd-net@FreeBSD.ORG Thu May 23 10:27:14 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8C2F92B3 for ; Thu, 23 May 2013 10:27:14 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 51C042C3 for ; Thu, 23 May 2013 10:27:13 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UfSjo-0008Jo-6y for freebsd-net@freebsd.org; Thu, 23 May 2013 12:27:12 +0200 Received: from office-nat.spylog.net ([193.169.234.6]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 23 May 2013 12:27:12 +0200 Received: from citrin by office-nat.spylog.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 23 May 2013 12:27:12 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Anton Yuzhaninov Subject: Re: surprise surprise (VM related) [luigi@FreeBSD.org: svn commit: r250911 - head/sys/kern] Date: Thu, 23 May 2013 10:26:55 +0000 (UTC) Organization: Vega Lines: 6 Sender: Anton Yuzhaninov Message-ID: References: <20130522164244.GB95808@onelab2.iet.unipi.it> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: office-nat.spylog.net X-Comment-To: Luigi Rizzo User-Agent: tin/2.0.1-20111224 ("Achenvoir") (UNIX) (FreeBSD/10.0-CURRENT (i386)) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 10:27:14 -0000 On Wed, 22 May 2013 20:42:44, Luigi Rizzo wrote: LR> Using polling, a FreeBSD instance under qemu-kvm remains perfectly LR> responsive even when bombed with 10 Mpps over an emulated e1000, LR> and happily processes 1.7 Mpps through ipfw. Can you share qemu network configuration used in tests? From owner-freebsd-net@FreeBSD.ORG Thu May 23 11:03:23 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 31B2EE5A for ; Thu, 23 May 2013 11:03:23 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id EBEC56E1 for ; Thu, 23 May 2013 11:03:22 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 51CB17300B; Thu, 23 May 2013 13:05:58 +0200 (CEST) Date: Thu, 23 May 2013 13:05:58 +0200 From: Luigi Rizzo To: Anton Yuzhaninov Subject: Re: surprise surprise (VM related) [luigi@FreeBSD.org: svn commit: r250911 - head/sys/kern] Message-ID: <20130523110558.GA8918@onelab2.iet.unipi.it> References: <20130522164244.GB95808@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 11:03:23 -0000 On Thu, May 23, 2013 at 10:26:55AM +0000, Anton Yuzhaninov wrote: > On Wed, 22 May 2013 20:42:44, Luigi Rizzo wrote: > LR> Using polling, a FreeBSD instance under qemu-kvm remains perfectly > LR> responsive even when bombed with 10 Mpps over an emulated e1000, > LR> and happily processes 1.7 Mpps through ipfw. > > Can you share qemu network configuration used in tests? it is basically qemu-head + kvm (running on a linux host) with modifications to use a VALE switch as a backend, and a few tweaks to speed up access to the guest memory. A patch is at http://info.iet.unipi.it/~luigi/doc/20130523-qemu-diff.gz The FreeBSD guest uses if_lem.c and just sets polling mode. I also have patches for the guest device driver, but they are still in the works. cheers luigi > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu May 23 16:45:51 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 51A52848; Thu, 23 May 2013 16:45:51 +0000 (UTC) (envelope-from MBentkofsky@verisign.com) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by mx1.freebsd.org (Postfix) with ESMTP id A9665FB9; Thu, 23 May 2013 16:45:49 +0000 (UTC) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKUZ5Ht+HM2L2i92KNUw3SEap7O/KXED45@postini.com; Thu, 23 May 2013 09:45:50 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r4NGi1kk028037 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 May 2013 12:44:01 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 23 May 2013 12:44:00 -0400 From: "Bentkofsky, Michael" To: Jeff Roberson , John Baldwin Subject: RE: Followup from Verisign after last week's developer summit Thread-Topic: Followup from Verisign after last week's developer summit Thread-Index: Ac5VXnht9RnhzeKKSL6DcCEAPOWbPABCopwAAAyDTYAAC5LNAAA/pTtw Date: Thu, 23 May 2013 16:44:00 +0000 Message-ID: <080FBD5B7A09F845842100A6DE79623321F703B5@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <080FBD5B7A09F845842100A6DE79623321F6E70C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <201305211320.26818.jhb@freebsd.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" , "jeff@freebsd.org" , "rwatson@freebsd.org" , "Charbon, Julien" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 16:45:51 -0000 I am adding freebsd-net to this and will re-summarize to get additional inp= ut. Thanks for all of the initial suggestions. For benefit of those on freebsd-net@, we are noticing significant locking c= ontention on the V_tcpinfo lock under moderately high connection establishm= ent and teardown rates (around 45-50k connections per second). Our profilin= g suggests the lock contention on V_tcpinfo effectively single-threads all = TCP connections. Similar testing on Linux with equivalent hardware does not= show this contention and can get a much higher connection establishment ra= te. We can attach profiling and test details if anyone would like. JHB recommends: - He has seen similar results in other kinds of testing.=20 - Linux uses RCU for the locking on the equivalent table (we've confirmed t= his to be the case). - Looking into a lock per bucket on the PCB lookup. Jeff recommends: - Changing the lock strategy so the hash lookup can be effectively pushed f= urther down into the stack. - Making the [list] iterators more complex like those in use in the hash lo= okup now. We are starting down these paths to try to break the locking down. We'll po= st some initial patch ideas soon. Meanwhile, any additional suggestions are= certainly welcome. Finally, I will mention that we have enabled PCBGROUPS in some of our testi= ng with 9.1 and found no change for our particular workload with high conne= ction establishment rates. Thanks, Mike -----Original Message----- From: Jeff Roberson [mailto:jroberson@jroberson.net]=20 Sent: Wednesday, May 22, 2013 12:50 AM To: John Baldwin Cc: Bentkofsky, Michael; rwatson@freebsd.org; jeff@freebsd.org; Charbon, Ju= lien Subject: Re: Followup from Verisign after last week's developer summit On Tue, 21 May 2013, Jeff Roberson wrote: > On Tue, 21 May 2013, John Baldwin wrote: > >> On Monday, May 20, 2013 9:48:02 am Bentkofsky, Michael wrote: >>> Greetings gentlemen, >>>=20 >>> It was a pleasure to meet you all last week at the FreeBSD developer=20 >>> summit. >> I would like to thank you for spending the time to discuss all the=20 >> wonderful internals of the network stack. We also thoroughly enjoyed=20 >> the discussion on receive side scaling. >>>=20 >>> I'm sure you will remember both Julien Charbon and me asking=20 >>> questions >> regarding the TCP stack implementation, specifically around the=20 >> locking internals. I am hoping to follow-up with a path forward so we=20 >> might be able to enhance the connection rate performance. Our=20 >> internal testing has found that the V_tcpinfo lock prevents TCP=20 >> scaling under high connection setup and teardown rates. In fact, we=20 >> surmise that a new "FIN flood" attack may be possible to degrade=20 >> server connections significantly. >>>=20 >>> In short, we are interested in changing this locking strategy and=20 >>> hope to >> get input from someone with more familiarity with the implementation.=20 >> We're willing to be part of the coding effort and are willing to=20 >> submit our suggestions to the community. I think we might just need=20 >> some occasional input. >>>=20 >>> Also, I will point out that our similar testing on Linux shows that=20 >>> the >> comparable performance between the two operating systems on the same=20 >> multi- core hardware is significantly different. We're able to drive=20 >> over 200,000 connections per second on a Linux server compared to=20 >> fewer than 50,000 on the FreeBSD server. We have kernel profiling=20 >> details that we can share if you'd like. >>=20 >> I have seen similar results with a redis cluster at work (we ended up=20 >> deploying proxies to allow applications to reuse existing connections=20 >> to avoid this). I believe Linux uses RCU for this table. You could=20 >> perhaps use an rm lock instead of an rw lock. On idea I considered=20 >> was to split the the pcbhash lock up further so you had one lock per=20 >> hash bucket so that you could allow concurrent connection=20 >> setup/teardown so long as they were referencing different buckets. =20 >> However, I did not think this would have been useful for the case at=20 >> work since those connections were insane (single packet request=20 >> followed by single packet reply with all the setup/teardown overhead)=20 >> and all going to the same listening socket (so all the setup's would=20 >> hash to the same bucket). Handling concurrent setup on the same=20 >> listen socket is a PITA but is in fact the common case. > > I don't think it's simply a synchronization primitive problem. It=20 > looks to me like the fundamental issue is that the lock order for the=20 > tables is prior to the inp lock which means we have to grab it very=20 > early. Presumably this is the classic sort of container ->=20 > datastructure, datastructure -> container lock order problem. This=20 > seems to be made more complex by protecting the list of all pcbs, the=20 > port allocation, and parts of the hash by the same lock. > > Have we tried to further decompose this lock? I would experiment with=20 > that as a first step. Is this grabbed in so many places just due to=20 > the complex lock order issue? That seems to be the case. There are=20 > only a handful of fields marked as protected by the inp info lock. Do=20 > we know that this list is complete? > > My second step would be to attempt to turn the locking on its head.=20 > Change the lock order from inp lock to inp info lock. You can resolve=20 > the lookup problem by adding an atomic reference count that holds the=20 > datastructure while you drop the hash lock and before you acquire the=20 > inp lock. Then you could re-validate the inp after lookup. I suspect=20 > it's not that simple and there are higher level races that you'll=20 > discover are being serialized by this big lock but that's just a hunch. > I read some more. We have already done this lookup/ref/etc. dance for the = hash lock. It handles the hard cases of multiple inp_* calls and synchroni= zing the ports, bind, connect, etc. It looks like the list locks have been= optimized to make the iterators simple. I think this is backwards now. W= e should make the iterators complex and the normal setup/teardown path simp= le. The iterators can follow a model like the hash lock using sentinels to= hold their place. We have the same pattern elsewhere. It would allow you= to acquire the INP_INFO lock after the INP lock and push it much deeper in= to the stack. Jeff > What do you think Robert? If it would make improving the tcb locking=20 > simpler it may fall under the umbrella of what Isilon needs but I'm=20 > not sure that's the case. Certainly my earlier attempts at deferred=20 > processing were made more complex by this arrangement. > > Thanks, > Jeff > >>=20 >> The best forum for discussing this is probably on net@ as there are=20 >> likely other interested parties who might have additional ideas. =20 >> Also, it might be interesting to look at how connection groups try to=20 >> handle this. I believe they use an altenate method of decomposing=20 >> the global lock into smaller chunks, and I think they might do=20 >> something to help mitigate the listen socket problem (perhaps they=20 >> duplicate listen sockets in all groups)? Robert would be able to=20 >> chime in on that, but I believe he is not really back home until next=20 >> week. >>=20 >> -- >> John Baldwin >>=20 > From owner-freebsd-net@FreeBSD.ORG Thu May 23 18:36:32 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BF6A372D for ; Thu, 23 May 2013 18:36:32 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8EA6096C for ; Thu, 23 May 2013 18:36:32 +0000 (UTC) Received: by mail-oa0-f42.google.com with SMTP id i10so5006617oag.29 for ; Thu, 23 May 2013 11:36:25 -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=JUPSAxMbZA3HwDoH9MIKDs5Muz3SQl8sebgxUch4coA=; b=Pq0Osf6HYmL3iKUYPdHLlJcTap8Cp9bNFs4lHOfVdv9aDIHrMln9srCM1tFmtfxpfg VCyfOGSegtnR5ctIJGHrnDKfg0CLiElUp7q/PNE02ESLoatNTpccaot7SbpkUNHmpY0s +F1ZWK8wP77uwrpqo1LIBiYThl9S6h+pa5rjd3+zLKRjAf7SjOPQvJOGuWCktnBijGS1 bK+TUk3R4FfnmN5nOHFTYx3CeX9BJGIgM5HbbATe1nGERJa+VBWfKig48oNFeDeVn7Qm 3qGREQCHqXr3O0Wz07YqLYm0Hg/ss+fW+dghddtrqMTRQUDeb0f1aoS5Tty2rVn6dcgL kJ8w== MIME-Version: 1.0 X-Received: by 10.60.155.209 with SMTP id vy17mr9627534oeb.83.1369334185834; Thu, 23 May 2013 11:36:25 -0700 (PDT) Received: by 10.76.90.10 with HTTP; Thu, 23 May 2013 11:36:25 -0700 (PDT) In-Reply-To: <64DAB3164E410447932305F50F896D8D6AF63DB3@MTLDAG01.mtl.com> References: <64DAB3164E410447932305F50F896D8D6AF63DB3@MTLDAG01.mtl.com> Date: Thu, 23 May 2013 14:36:25 -0400 Message-ID: Subject: Re: Create pkey on FreeBSD 9.1 From: Ryan Stone To: Alex Liptsin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 18:36:32 -0000 On Thu, May 23, 2013 at 4:32 AM, Alex Liptsin wrote: > Hello. > > I have FreeBSD 9.1 installed. > There is mellanox adapter inside. > OFED support is already installed. > > I try to add pkeys on ib0 port. > > Usually in Linux I did: > > echo 0x800c > /sys/class/net/ib0/create_child > > ifconfig -a > To Make sure you see a new interface: ib0.800c > > How can I do it on FreeBSD? There is no "/sys/class/net/ib0/create_child" > directory. > > Regards, > Alex Liptsin > > _______________________________________________ > 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 reading the source it looks like this is done by attaching a vlan interface to the interface. So try: ifconfig vlan create vlandev ib0 vlan 0xc This will create a new vlanX interface (ifconfig will its precise name with its unit number to stdout). From owner-freebsd-net@FreeBSD.ORG Thu May 23 21:05:43 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9C88576C; Thu, 23 May 2013 21:05:43 +0000 (UTC) (envelope-from guy.helmer@gmail.com) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by mx1.freebsd.org (Postfix) with ESMTP id 687A511A; Thu, 23 May 2013 21:05:43 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id f4so2588920iea.23 for ; Thu, 23 May 2013 14:05:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=hE9PGv8YxtTJhSJ4p81wT8WNaGu7CrEIY0tLWpOPDRI=; b=Yhf95Vl7mHvvLwMbzjDSoDzMv3OJaalFJL7x8jvl34BmHog/fXD4sSE9RhOV5r6JeS GEgszuHq+WY2aGK4eFA+5DdtrvWABBqljol3PuuuTVjXoNmZVzq9KsEmqAHIH7r0rLBi 5SHvV2EEoG2L5mIqY/Q9vTh7LpZrOmzAKuHQctYmDtOKSlpXPwYcwKdp+KDLsM94os5m PpT4zsTIUO24MnoDg5eiHWXwoHuxAvfG9aOIsBOb1Aom41F5hLyeHf+BxxpeHjEq5TP8 DRCglwTYxf3oDbf7aYv+hf5QjU/FoO0VTCgRDpmnsiSWly7QuQrBSTs9+Jwb1FTVmFp1 Q6Gg== X-Received: by 10.42.27.146 with SMTP id j18mr11629524icc.54.1369343143074; Thu, 23 May 2013 14:05:43 -0700 (PDT) Received: from [192.168.1.107] (173-25-205-212.client.mchsi.com. [173.25.205.212]) by mx.google.com with ESMTPSA id j3sm13510959igv.4.2013.05.23.14.05.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 May 2013 14:05:41 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: bpf hold buffer in-use flag From: Guy Helmer In-Reply-To: <201301091535.04904.jhb@freebsd.org> Date: Thu, 23 May 2013 16:05:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4EA47178-7CE2-40CE-A767-2689FAF7BEBD@gmail.com> References: <9C928117-2230-4F01-9B95-B6D945AF4416@gmail.com> <201301091535.04904.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1503) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 21:05:43 -0000 On Jan 9, 2013, at 2:35 PM, John Baldwin wrote: > On Tuesday, November 13, 2012 4:40:57 pm Guy Helmer wrote: >> To try to completely resolve the race in bpfread(), I have put = together=20 > these changes to add a flag to indicate when the hold buffer cannot be=20= > modified because it is in use. Since it's my first time using = mtx_sleep() and=20 > wakeup(), I wanted to run these past the list to see if I can get any = feedback=20 > on the approach. >>=20 >>=20 >> Index: bpf.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- bpf.c (revision 242997) >> +++ bpf.c (working copy) >> @@ -819,6 +819,7 @@ bpfopen(struct cdev *dev, int flags, int fmt, = stru >> * particular buffer method. >> */ >> bpf_buffer_init(d); >> + d->bd_hbuf_in_use =3D 0; >> d->bd_bufmode =3D BPF_BUFMODE_BUFFER; >> d->bd_sig =3D SIGIO; >> d->bd_direction =3D BPF_D_INOUT; >> @@ -872,6 +873,9 @@ bpfread(struct cdev *dev, struct uio *uio, int = iof >> callout_stop(&d->bd_callout); >> timed_out =3D (d->bd_state =3D=3D BPF_TIMED_OUT); >> d->bd_state =3D BPF_IDLE; >> + while (d->bd_hbuf_in_use) >> + mtx_sleep(&d->bd_hbuf_in_use, &d->bd_lock, >> + PRINET|PCATCH, "bd_hbuf", 0); >=20 > You need to check the return value here, otherwise the PCATCH is = useless (you=20 > will just go back to sleep instead of failing with an error if this is=20= > interrupted by a signal).=20 Thanks for the feedback (sorry it's taken so long to get to it). Would = this change correctly handle interruptions? Index: bpf.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- bpf.c (revision 250941) +++ bpf.c (working copy) @@ -856,9 +856,14 @@ callout_stop(&d->bd_callout); timed_out =3D (d->bd_state =3D=3D BPF_TIMED_OUT); d->bd_state =3D BPF_IDLE; - while (d->bd_hbuf_in_use) - mtx_sleep(&d->bd_hbuf_in_use, &d->bd_lock, + while (d->bd_hbuf_in_use) { + error =3D mtx_sleep(&d->bd_hbuf_in_use, &d->bd_lock, PRINET|PCATCH, "bd_hbuf", 0); + if (error =3D=3D EINTR || error =3D=3D ERESTART) { + BPFD_UNLOCK(d); + return (error); + } + } /* * If the hold buffer is empty, then do a timed sleep, which * ends when the timeout expires or when enough packets From owner-freebsd-net@FreeBSD.ORG Thu May 23 21:28:21 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 80B67E3F for ; Thu, 23 May 2013 21:28:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 5EA74220 for ; Thu, 23 May 2013 21:28:21 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A12A0B917; Thu, 23 May 2013 17:28:19 -0400 (EDT) From: John Baldwin To: Guy Helmer Subject: Re: bpf hold buffer in-use flag Date: Thu, 23 May 2013 17:28:05 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <9C928117-2230-4F01-9B95-B6D945AF4416@gmail.com> <201301091535.04904.jhb@freebsd.org> <4EA47178-7CE2-40CE-A767-2689FAF7BEBD@gmail.com> In-Reply-To: <4EA47178-7CE2-40CE-A767-2689FAF7BEBD@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201305231728.05253.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 23 May 2013 17:28:19 -0400 (EDT) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 21:28:21 -0000 On Thursday, May 23, 2013 5:05:39 pm Guy Helmer wrote: > > On Jan 9, 2013, at 2:35 PM, John Baldwin wrote: > > > On Tuesday, November 13, 2012 4:40:57 pm Guy Helmer wrote: > >> To try to completely resolve the race in bpfread(), I have put together > > these changes to add a flag to indicate when the hold buffer cannot be > > modified because it is in use. Since it's my first time using mtx_sleep() and > > wakeup(), I wanted to run these past the list to see if I can get any feedback > > on the approach. > >> > >> > >> Index: bpf.c > >> =================================================================== > >> --- bpf.c (revision 242997) > >> +++ bpf.c (working copy) > >> @@ -819,6 +819,7 @@ bpfopen(struct cdev *dev, int flags, int fmt, stru > >> * particular buffer method. > >> */ > >> bpf_buffer_init(d); > >> + d->bd_hbuf_in_use = 0; > >> d->bd_bufmode = BPF_BUFMODE_BUFFER; > >> d->bd_sig = SIGIO; > >> d->bd_direction = BPF_D_INOUT; > >> @@ -872,6 +873,9 @@ bpfread(struct cdev *dev, struct uio *uio, int iof > >> callout_stop(&d->bd_callout); > >> timed_out = (d->bd_state == BPF_TIMED_OUT); > >> d->bd_state = BPF_IDLE; > >> + while (d->bd_hbuf_in_use) > >> + mtx_sleep(&d->bd_hbuf_in_use, &d->bd_lock, > >> + PRINET|PCATCH, "bd_hbuf", 0); > > > > You need to check the return value here, otherwise the PCATCH is useless (you > > will just go back to sleep instead of failing with an error if this is > > interrupted by a signal). > > Thanks for the feedback (sorry it's taken so long to get to it). Would this > change correctly handle interruptions? Yes. > Index: bpf.c > =================================================================== > --- bpf.c (revision 250941) > +++ bpf.c (working copy) > @@ -856,9 +856,14 @@ > callout_stop(&d->bd_callout); > timed_out = (d->bd_state == BPF_TIMED_OUT); > d->bd_state = BPF_IDLE; > - while (d->bd_hbuf_in_use) > - mtx_sleep(&d->bd_hbuf_in_use, &d->bd_lock, > + while (d->bd_hbuf_in_use) { > + error = mtx_sleep(&d->bd_hbuf_in_use, &d->bd_lock, > PRINET|PCATCH, "bd_hbuf", 0); > + if (error == EINTR || error == ERESTART) { > + BPFD_UNLOCK(d); > + return (error); > + } > + } Maybe simplify the check to just 'if (error != 0)'? -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri May 24 12:09:54 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9A5092DE for ; Fri, 24 May 2013 12:09:54 +0000 (UTC) (envelope-from prvs=18565eb3ca=agave.spring@cadamericas.com) Received: from cadamericas.com (mail02.amotive.com [173.164.153.20]) by mx1.freebsd.org (Postfix) with ESMTP id 7D1059D8 for ; Fri, 24 May 2013 12:09:53 +0000 (UTC) Received: from agave.cadamericas.com ([64.183.139.162]) by amotive.com (mail02.amotive.com) (MDaemon PRO v13.0.2) with ESMTP id md50002145054.msg; Fri, 24 May 2013 05:09:36 -0700 X-Spam-Processed: mail02.amotive.com, Fri, 24 May 2013 05:09:36 -0700 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 64.183.139.162 X-Return-Path: prvs=18565eb3ca=agave.spring@cadamericas.com X-Envelope-From: agave.spring@cadamericas.com X-MDaemon-Deliver-To: freebsd-net@freebsd.org Date: Fri, 24 May 2013 05:08:14 -0700 To: freebsd-net From: CAD Americas Subject: Build Your Electrical Cad Design Skill Set Message-ID: <4723477847124172927f98aefef680bf@agave.cadamericas.com> X-Priority: 3 X-Mailer: PHPMailer 5.2.1 (http://code.google.com/a/apache-extras.org/p/phpmailer/) X-CampTrackID: 7f12e32f-0f62-822d-87c0-519f586f0235 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: CAD Americas List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 12:09:54 -0000 TIME IS RUNNING OUT! Register for CAD Americas Training Days by MAY 7 and S= AVE!=0ACAD AMERICAS TRAINING DAYS ARRIVE IN YOUR AREA SOON Join us for this= one-day training event in your area. Whether your focus is Mechanical Desi= gn, Construction, BIM, Electrical Design or Plant Design, there will be ses= sions that will improve your productivity immediately!=0AJune 4June 6June 7= June 12June 13June 26 June 27=0A Cleveland Cincinnati Detroit Atlanta D= allas San Jose San_Bernardino =0ATAKE HOME NEW TOOLS AND TECHNIQUES THAT = WILL IMPROVE YOUR PERFORMANCE IMMEDIATELY=0A=0A=0A=0A=0ALynn AllenTechnical= Evangelist More =0ARobert GreenCAD Mgmt Expert More =0ASteve SchainAutoCAD= Expert More =0ATod StephensRevit Expert More =0AClick here to see current = session descriptions.Please note that sessions will vary by location =0ALea= rn from well-known industry instructors who will share best practices and t= rends, product tips and tricks, new features =E2=80=A6 and more.=0AImprove = your productivity with new techniques that you can put to work right away.= =0AMeet your peers and exchange ideas on how to best use the CAD tools you = have to meet the demands of your job.=0ATake a closer look at services and = technologies offered by resellers in your area.=0AREGISTER BY MAY 7TH AND S= AVERegister for=C2=A0a CAD Americas Training Day by May 7th and save.=0AEar= ly Bird Rate: $150 (Until May 7th)=0AStandard Rate: $195 (AFTER May 7th)=0A= Student/Faculty Rate: $95 (must present current student ID upon check-in at= registration)=0AREGISTER FOR CAD AMERICAS TRAINING TODAY!=0A=0A=0A=0A=0AJo= in us at=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=C2=A0INTERNATIONAL SPONSORS=0A= =0A=0A=C2=A0=C2=A0 =C2=A0=C2=A0 =0A=0AEDUCATION SPONSOR=0A=0A=0AMEDIA SPONS= ORS=0A=0A=C2=A0=0AThis email was sent to email address: freebsd-net@freebsd= .org Click here to Opt-Out=0A From owner-freebsd-net@FreeBSD.ORG Fri May 24 13:18:57 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1A15EFF6; Fri, 24 May 2013 13:18:57 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id E77AFD9A; Fri, 24 May 2013 13:18:56 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4ODIuQj070535; Fri, 24 May 2013 13:18:56 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4ODIuab070534; Fri, 24 May 2013 13:18:56 GMT (envelope-from linimon) Date: Fri, 24 May 2013 13:18:56 GMT Message-Id: <201305241318.r4ODIuab070534@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/178947: [arp] arp rejecting not working X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 13:18:57 -0000 Old Synopsis: arp rejecting not working New Synopsis: [arp] arp rejecting not working Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri May 24 13:18:44 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=178947