From owner-freebsd-net@FreeBSD.ORG Sun Dec 8 10:43:26 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E581C74 for ; Sun, 8 Dec 2013 10:43:26 +0000 (UTC) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 412EF19EB for ; Sun, 8 Dec 2013 10:43:26 +0000 (UTC) Received: by mail-pd0-f181.google.com with SMTP id p10so3475347pdj.40 for ; Sun, 08 Dec 2013 02:43:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IROVtG5eL3wKA7shJYgDYABQ4VOX/LIBYsQtRTKGga0=; b=Tb1pKQPDUmdadP62wTneICPNbNE8vuTAOwiLZB6N7FZY1Cy2IKDrRJzl2g8mTIgro3 F18t5iKgAD33vUyeo4glLDzS1nUoIRZBoxvrBTM9tmCWLG6Pgf5K6GUk/aZumUn7ORDd QdjETFjaBSYmrf4TkJdO3pitT2ICV4ULQJ3gKBidsxscW8B64u3h8LGHOTSMElHbXu15 58WXX9MWi6PCM4fwjVVy+2RXESnCvA5wEaJgm8iPjZsPCJz16/M0iUBKiAT2YFU0DLvc Zhn5TfM7gbgaeJfv9XH5LddxOfoZiNzjahO1NYF5uAwIXoAFLRztmYIK5KtwsfAoMCgN BVKw== MIME-Version: 1.0 X-Received: by 10.66.2.66 with SMTP id 2mr14655678pas.72.1386499405830; Sun, 08 Dec 2013 02:43:25 -0800 (PST) Received: by 10.70.127.143 with HTTP; Sun, 8 Dec 2013 02:43:25 -0800 (PST) Received: by 10.70.127.143 with HTTP; Sun, 8 Dec 2013 02:43:25 -0800 (PST) In-Reply-To: References: <5293E3E7.6090604@freebsd.org> Date: Sun, 8 Dec 2013 12:43:25 +0200 Message-ID: Subject: Re: Netgraph ng_patch and ng_input: where to find packets? From: Sami Halabi To: Victor Gamov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 10:43:26 -0000 Hi Gamov, Have got this to work? If so would share configurations? Thanks in advance, Sami =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A 29 =D7=91=D7=A0=D7=95=D7=91 2013 19:28= , "Victor Gamov" =D7=9B=D7=AA=D7=91: > ipfw allow log udp from 192.168.230.9 to 192.168.230.128 dst-port 1234 > > this rule added to ipfw before ngtee action and I see patched packets at > ipfw now -- its marked as received via vlan999 still. Yes, it's OK. > > Also, I make 3 actions at ng_patch now: > set TTL=3D3 > set src_ip=3D192.168.230.9 (vlan333) > set dst_ip=3D192.168.230.128 now. > > But packets still does not exists on vlan333 as outgoing. > > Any suggestions? > > Is it possible patched packets silently drops by kernel ? > > On 26Nov, 2013, at 13:44, Victor Gamov wrote: > > > > > On 26Nov, 2013, at 03:57, Julian Elischer wrote: > > > >> On 11/24/13, 5:05 AM, Victor Gamov wrote: > >>> Hi All > >>> > >>> I want to get 2 or 3 copies of input packet at my system to resend it > to new destinations. So I prepare following configuration: > >>> > >>> # ipfw add 10000 ngtee 100 udp from any to 239.0.0.19 dst-port 1234 i= n > via vlan999 > >>> > >>> # ngctl mkpeer ipfw: hub 100 hub-in > >>> # ngctl name ipfw:100 hub100 > >>> > >>> # ngctl mkpeer hub100: patch hub100-out1 in > >>> # ngctl name hub100:hub100-out1 patch100 > >>> # ngctl msg patch100: setconfig '{ count=3D1 csum_flags=3D1 ops=3D[ { > value=3D0xc0a8e680 offset=3D16 length=3D4 mode=3D1 } ] }' > >>> > >>> Now when I connect to patch:out as > >>> # nghook -a patch100: out > >>> > >>> then I see packets with new IP: > >>> > >>> 0000: 45 00 05 40 00 00 40 00 ff 11 b9 27 c0 a8 0d 12 > >>> 0010: c0 a8 e6 80 04 dc 04 dc 05 2c 00 00 47 4c ef 1a > >>> > >>> Now I want to put this packets back into IP processing to send it to > new destination 192.168.230.128 (0xc0a8e680): > >>> > >>> # ngctl mkpeer patch100: ip_input out new100_to_dst_1 > >>> > >>> But packets not shown on outgoing interface: > >>> > >>> # ifconfig vlan333 > >>> vlan333: flags=3D8843 metric = 0 > mtu 1500 > >>> options=3D103 > >>> ether 00:1b:21:5b:7e:e9 > >>> inet 192.168.230.9 netmask 0xffffff00 broadcast 192.168.230.255 > >>> > >>> # arp 192.168.230.128 > >>> ? (192.168.230.128) at 62:99:4c:3b:22:fc on vlan333 expires in 1190 > seconds > >> I would looking at giving the packet back to the firewall as suggested= .. > >> > >> netgraph cookie > >> Divert packet into netgraph with given cookie. The search > termi- > >> nates. If packet is later returned from netgraph it is > either > >> accepted or continues with the next rule, depending on > >> net.inet.ip.fw.one_pass sysctl variable. > >> see ng_ipfw for more details.. > > > > Yes I read this manuals :-) But I still can't see packets neither at > ipfw nor at outgoing interface. > > > > net.inet.ip.fw.one_pass: 0 > > net.inet.ip.forwarding: 1 > > > > Is my original idea is correct? > > -- > CU, > Victor Gamov > > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Sun Dec 8 12:03:26 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F1DBEA34; Sun, 8 Dec 2013 12:03:25 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7CC7A1EA8; Sun, 8 Dec 2013 12:03:25 +0000 (UTC) Received: from [192.168.1.200] (p508F285F.dip0.t-ipconnect.de [80.143.40.95]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 7ACED1C0C069A; Sun, 8 Dec 2013 13:03:22 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: A small fix for if_em.c, if_igb.c, if_ixgbe.c From: Michael Tuexen In-Reply-To: Date: Sun, 8 Dec 2013 13:03:21 +0100 Content-Transfer-Encoding: 7bit Message-Id: <9E163DC1-D647-4E19-BE23-44E5DFE2F284@lurchi.franken.de> References: <521B9C2A-EECC-4412-9F68-2235320EF324@lurchi.franken.de> <20131202022338.GA3500@michelle.cdnetworks.com> <20131203021658.GC2981@michelle.cdnetworks.com> <20131205223711.GB55638@funkthat.com> <3576B69E-E943-46E0-83E5-0B2194A44ED0@lurchi.franken.de> <20131206202012.GG55638@funkthat.com> <609C63CD-9332-4EAE-AACE-5B911416DF80@lurchi.franken.de> To: Adrian Chadd X-Mailer: Apple Mail (2.1510) Cc: Yong-Hyeon Pyun , Jack F Vogel , John-Mark Gurney , "freebsd-net@freebsd.org list" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 12:03:26 -0000 On Dec 7, 2013, at 12:25 AM, Adrian Chadd wrote: > On 6 December 2013 13:10, Michael Tuexen > wrote: > >> Well, this is what happens: >> The sender takes a packet from the send-queue, calls ip-output. Since >> it returns an error, we don't move it to the sent-queue, but leave >> it in the send queue (assuming it doesn't went on the wire). >> However, the driver puts it on the wire, it makes it to the peer, >> the peer sends SACK, and we receive the SACK. Since the packet is >> not on the sent queue, we don't realize that it is acked. Receiving >> a SACK is a trigger for sending a packet. So we take the next one >> from the send-queue (the one from the beginning), and send it again. >> So it is a wire speed ping pong... >> So in case the lower layer tells us that there was a problem in >> sending the packet, we >> * don't consider it sent >> * wait for the next normal protocol trigger for send another packet. >> This sounds OK to me... >> >> That is why I need to know what an error from ip_output() means. >> If I can't conclude that the provided packet was dropped, I can just >> consider it sent and don't try to do any optimisation. > > We're heading down the right path. > > I'm increasingly believing that ignoring the return value is the > correct thing to do. You mean ignoring the return value transport layer? Why not provide a return code which can be used? Returning a value which needs to be ignored doesn't make a lot of sense to me... I think if_transmit() should only return an error if there was a problem with the provided packet, not with some packet, probably a different one. Can you point me to a consumer of the return code of if_transmit(), which can benefit from the logic you described? Best regards Michael > > > -adrian > From owner-freebsd-net@FreeBSD.ORG Sun Dec 8 15:45:11 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E8052ED for ; Sun, 8 Dec 2013 15:45:11 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F02361B48 for ; Sun, 8 Dec 2013 15:45:10 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-246-96.lns20.per2.internode.on.net [121.45.246.96]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id rB8Fitdb027041 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 8 Dec 2013 07:44:58 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <52A493F1.6040700@freebsd.org> Date: Sun, 08 Dec 2013 23:44:49 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Sami Halabi , Victor Gamov Subject: Re: Netgraph ng_patch and ng_input: where to find packets? References: <5293E3E7.6090604@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 15:45:11 -0000 On 12/8/13, 6:43 PM, Sami Halabi wrote: > Hi Gamov, > Have got this to work? > If so would share configurations? > > Thanks in advance, > Sami > בתאריך 29 בנוב 2013 19:28, "Victor Gamov" כתב: > > if not then the way to track it it to put a breakpoint on the netgraph node that handles the packet and just single step through until you see where the packet goes.. kdb would give you a decent idea but a second machine (or a virtual machine) with kgdb would really show you what's going on. From owner-freebsd-net@FreeBSD.ORG Sun Dec 8 19:03:04 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6429CE71 for ; Sun, 8 Dec 2013 19:03:04 +0000 (UTC) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1D7021750 for ; Sun, 8 Dec 2013 19:03:04 +0000 (UTC) Received: by mail-ve0-f175.google.com with SMTP id jx11so2874882veb.34 for ; Sun, 08 Dec 2013 11:03:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=ti5UnfcOGNlNh8qPo4qoWgr6lgcArtOaGv2UpmEPLe4=; b=ka6tl1xSHIQ+WW8OO3CdJLiHcHNIbxfSIu5wjNhVs1Xhy+5LNfRWJDSLnxZoza52lN JKZuzFiS/AHQzKi7B4heN7UridejRIsgSvlr2pFQN3lcnUoguWV6RvbrjoedKKy3f8Jd mUdEp21wUMeaVUsh3jUXXV5oAkdcVpVcbWgCDz7Xb0lIVyblF0bN0GAzI1EpQipmfJmP adbjDb9KtE3MajCpt+YlDTW44RKWwTfciY2fxN7ofYJD1EUIgXmOqlFi7Rd0GCG45ldy CTP/qNCiBIY7sPEWgYyiR6RdGkHf/EUrEId/1GQJG1rcb4pqPuMDsvSomqVhrbJRDy8+ 58SA== X-Received: by 10.52.171.227 with SMTP id ax3mr99039vdc.34.1386529383307; Sun, 08 Dec 2013 11:03:03 -0800 (PST) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.58.123.5 with HTTP; Sun, 8 Dec 2013 11:02:42 -0800 (PST) In-Reply-To: References: <523457A1.3090606@debian.org> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Sun, 8 Dec 2013 20:02:42 +0100 X-Google-Sender-Auth: X3jWpYT5UQIhlxHylHvIjEzJqec Message-ID: Subject: Re: IPSEC To: Eitan Adler Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-net@freebsd.org" , Robert Millan , "debian-bsd@lists.debian.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 19:03:04 -0000 On Sun, Dec 8, 2013 at 12:16 AM, Eitan Adler wrote: > Hi all, > > I understand this is an old thread but I do not see an answer here. > Can anyone answer the question below? > > On Sat, Sep 14, 2013 at 8:33 AM, Robert Millan wrote: >> >> Hi! >> >> Is there any particular reason (performance, stability concerns...) >> IPSEC support is not enabled in GENERIC? >> >> In Debian GNU/kFreeBSD we're considering enabling it in our default >> builds, due to increased user demand and as it is already enabled for >> our Linux-based flavours. >> >> However we're concerned about diverging from FreeBSD as there might be >> unforeseen consequences. Is there any specific concern on your side? >> >> If not, perhaps it could be considered for HEAD after 10.0 release? > > Here are my own bench result regarding forwarding speed (paquet-per-second) with a kernel compiled without-ipsec and with ipsec (ipsec is not enabled during the tests, just present on the kernel) of FreeBSD 10.0-PRERELEASE: ministat -s without-ipsec ipsec x without-ipsec + ipsec +--------------------------------------------------------------------------------+ |x + x + +x x x + +| | |__________________A_____M____________| | | |_______________M_________A__________________________| | +--------------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 5 1646075 1764528 1725461 1713080 44560.059 + 5 1685034 1833206 1724461 1748666.8 62356.218 No difference proven at 95.0% confidence I didn't see negative impact of enabling ipsec (it's even a little bit better with it). Regards, Olivier From owner-freebsd-net@FreeBSD.ORG Mon Dec 9 03:44:25 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B8DEE3F; Mon, 9 Dec 2013 03:44:25 +0000 (UTC) Received: from mail-qe0-x22f.google.com (mail-qe0-x22f.google.com [IPv6:2607:f8b0:400d:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C263B1E5F; Mon, 9 Dec 2013 03:44:24 +0000 (UTC) Received: by mail-qe0-f47.google.com with SMTP id t7so2457772qeb.34 for ; Sun, 08 Dec 2013 19:44:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=GgUWVoAjqDWJ38HLvQ4PU6sRg+ZF63+eyHFEjo+FSKU=; b=qHEvuOJJLk2G0HGRT/pT4tPFWkx+f66EErPgAPAiKB53AwtjcTXezrW/H2u4EQG1cf 1+r04E4+OhycndNodXeaUne0Gr+sGyEcHsRzZlizqPVrX28arl1LtlaVwsoPPnwO+VMz g8yIWQrQqGMnrPQLAOyUqvngG2hnjlwTOzM4scETrDxR+v6feIlAiW8z0OQhnm5KtobT FAEcXvZ24HT6XNV3ik15jDDBLQQ/93sODO6lgvDYoGyZS7DbGAq//v07UCaz3hfVJwYi Tgsy1t38XPbecyBPXcwMwn3mnTrCvReyrQ/WgfFJbgUE4hcxMNTM7mCb3kfpySN/UoWl quDQ== MIME-Version: 1.0 X-Received: by 10.224.80.129 with SMTP id t1mr141216996qak.95.1386560663937; Sun, 08 Dec 2013 19:44:23 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.53.200 with HTTP; Sun, 8 Dec 2013 19:44:23 -0800 (PST) In-Reply-To: <9E163DC1-D647-4E19-BE23-44E5DFE2F284@lurchi.franken.de> References: <521B9C2A-EECC-4412-9F68-2235320EF324@lurchi.franken.de> <20131202022338.GA3500@michelle.cdnetworks.com> <20131203021658.GC2981@michelle.cdnetworks.com> <20131205223711.GB55638@funkthat.com> <3576B69E-E943-46E0-83E5-0B2194A44ED0@lurchi.franken.de> <20131206202012.GG55638@funkthat.com> <609C63CD-9332-4EAE-AACE-5B911416DF80@lurchi.franken.de> <9E163DC1-D647-4E19-BE23-44E5DFE2F284@lurchi.franken.de> Date: Sun, 8 Dec 2013 19:44:23 -0800 X-Google-Sender-Auth: IJCE4ZN7JU-ht7Xo4K0ghgkhf_w Message-ID: Subject: Re: A small fix for if_em.c, if_igb.c, if_ixgbe.c From: Adrian Chadd To: Michael Tuexen Content-Type: text/plain; charset=ISO-8859-1 Cc: Yong-Hyeon Pyun , Jack F Vogel , John-Mark Gurney , "freebsd-net@freebsd.org list" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 03:44:25 -0000 .. I'm saying that we should have if_transmit( )return an error only on the current packet, and 0 if it was queued. We don't have a mechanism to say that a queued packet actually made it onto the wire. Whether we should is a different discussion. Ie, after thinking about this some more, I'd like to: * change if_transmit in these drivers to do exactly what you suggest - it should return an error only if the given packet couldn't be queued. It shouldn't matter whether it is later transmitted or not - we don't have a feedback mechanism for that. * figure out a very specific definition of what xxx_mq_start_locked() should return - my gut feeling is an error if it couldn't queue a frame, and 0 if it dispatched a frame to the hardware - and then make the code match this definition. -adrian From owner-freebsd-net@FreeBSD.ORG Mon Dec 9 07:36:56 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10DA9D4D; Mon, 9 Dec 2013 07:36:56 +0000 (UTC) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D1D8A1D18; Mon, 9 Dec 2013 07:36:55 +0000 (UTC) Received: by mail-pd0-f177.google.com with SMTP id q10so4695127pdj.36 for ; Sun, 08 Dec 2013 23:36:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gS+hTmpmZioeU0gU4Xxr7uZ3ftGxynS028YfSLXVjaY=; b=L+H5Ge2whJkQyb6d2UORpLCWHaGxvB9LX06PqXy2fb4lSP6nZz7XtstHZmLkI6A9KH uAZkR87mu2DS2mQr1/OOZ0AbJa3Avk/8aRlLdSPCfurDKsv26oMbdwp6Pvi1Vk+Y/JeQ gCCd2Z35EXUxGGl2f59+Z4Fgs72+jUdsInsCC9Lwc1aB2jlvi9Agleuo+v+NVI9b9xBz aaK5O7qdyhGbWXqpH+kvsERPUQg8+22lEBhyfnAANDEw78vaHJE/rCx1Sd41u+rka2Li or0aLTflQ6hLf7JD2VbQl1ADjwqhfEUsqAZKcIWRmMpKBf020/swfTztRBsmYeyfkQJp s5qg== MIME-Version: 1.0 X-Received: by 10.66.66.202 with SMTP id h10mr19281946pat.70.1386574615364; Sun, 08 Dec 2013 23:36:55 -0800 (PST) Received: by 10.70.127.143 with HTTP; Sun, 8 Dec 2013 23:36:55 -0800 (PST) In-Reply-To: <52A493F1.6040700@freebsd.org> References: <5293E3E7.6090604@freebsd.org> <52A493F1.6040700@freebsd.org> Date: Mon, 9 Dec 2013 09:36:55 +0200 Message-ID: Subject: Re: Netgraph ng_patch and ng_input: where to find packets? From: Sami Halabi To: Julian Elischer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-net@freebsd.org" , Victor Gamov X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 07:36:56 -0000 Hi, Actually following the ng_patch the following worked for me (using 9.2-R -amd64): kldload ng_patch kldload ng_ipfw /usr/sbin/ngctl -f- << SEQ mkpeer ipfw: patch 300 in name ipfw:300 src_dst_chg msg src_dst_chg: setconfig { count=3D2 csum_flags=3D1 ops= =3D[ \ { mode=3D1 value=3D0xc0a8e609 length=3D4 offset=3D= 12 } \ { mode=3D1 value=3D0xc0a8e680 length=3D4 offset=3D= 16 } ] } SEQ /sbin/ipfw add 600 netgraph 300 log ip from any to 239.0.0.19 dst-port 1234 in via vlan999 Sami On Sun, Dec 8, 2013 at 5:44 PM, Julian Elischer wrote: > On 12/8/13, 6:43 PM, Sami Halabi wrote: > >> Hi Gamov, >> Have got this to work? >> If so would share configurations? >> >> Thanks in advance, >> Sami >> =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A 29 =D7=91=D7=A0=D7=95=D7=91 2013 19= :28, "Victor Gamov" =D7=9B=D7=AA=D7=91: >> >> >> > if not then the way to track it it to put a breakpoint on the netgraph > node that handles the packet and just single step through until you see > where the packet goes.. > kdb would give you a decent idea but a second machine (or a virtual > machine) with kgdb would really show you what's going on. > > > --=20 Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert From owner-freebsd-net@FreeBSD.ORG Mon Dec 9 09:31:04 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 01E7D7A4 for ; Mon, 9 Dec 2013 09:31:04 +0000 (UTC) Received: from mail.euro-comm.net (mail.euro-comm.net [194.190.78.14]) by mx1.freebsd.org (Postfix) with ESMTP id AC70F1638 for ; Mon, 9 Dec 2013 09:31:02 +0000 (UTC) Received: from [192.168.0.4] (unknown [213.109.0.97]) by mail.euro-comm.net (Postfix) with ESMTPSA id A4E736BD5E3; Mon, 9 Dec 2013 13:30:55 +0400 (MSK) Subject: Re: Netgraph ng_patch and ng_input: where to find packets? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=utf-8 From: Victor Gamov In-Reply-To: Date: Mon, 9 Dec 2013 13:30:53 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5293E3E7.6090604@freebsd.org> <52A493F1.6040700@freebsd.org> To: Sami Halabi X-Mailer: Apple Mail (2.1283) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 09:31:04 -0000 On 09Dec, 2013, at 11:36, Sami Halabi wrote: > Hi, Hi Sami > Actually following the ng_patch the following worked for me (using = 9.2-R -amd64): Yes, ng_patch works fine for me too. Then ng_input works too because I = see patched packets at ipfw. But this packets does not appears on = outgoing interface. Now I haven't machine for future testing, but I'll do more tests on = upcoming 10.0-R because I want to use 10.0 for my project. > kldload ng_patch > kldload ng_ipfw > /usr/sbin/ngctl -f- << SEQ > mkpeer ipfw: patch 300 in > name ipfw:300 src_dst_chg > msg src_dst_chg: setconfig { count=3D2 csum_flags=3D1 = ops=3D[ \ > { mode=3D1 value=3D0xc0a8e609 length=3D4 = offset=3D12 } \ > { mode=3D1 value=3D0xc0a8e680 length=3D4 = offset=3D16 } ] } > SEQ > /sbin/ipfw add 600 netgraph 300 log ip from any to 239.0.0.19 dst-port = 1234 in via vlan999 >=20 > Sami >=20 >=20 > On Sun, Dec 8, 2013 at 5:44 PM, Julian Elischer = wrote: > On 12/8/13, 6:43 PM, Sami Halabi wrote: > Hi Gamov, > Have got this to work? > If so would share configurations? >=20 > Thanks in advance, > Sami > =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A 29 =D7=91=D7=A0=D7=95=D7=91 2013 = 19:28, "Victor Gamov" =D7=9B=D7=AA=D7=91: >=20 >=20 >=20 > if not then the way to track it it to put a breakpoint on the netgraph = node that handles the packet and just single step through until you see = where the packet goes.. > kdb would give you a decent idea but a second machine (or a virtual = machine) with kgdb would really show you what's going on. -- =D0=A1 =D1=83=D0=B2=D0=B0=D0=B6=D0=B5=D0=BD=D0=B8=D0=B5=D0=BC, =D0=93=D0=B0=D0=BC=D0=BE=D0=B2 =D0=92=D0=B8=D0=BA=D1=82=D0=BE=D1=80 From owner-freebsd-net@FreeBSD.ORG Mon Dec 9 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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61F1F20D for ; Mon, 9 Dec 2013 11:06:50 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4CCB01E80 for ; Mon, 9 Dec 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 rB9B6o5U071078 for ; Mon, 9 Dec 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 rB9B6nsj071076 for freebsd-net@FreeBSD.org; Mon, 9 Dec 2013 11:06:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 9 Dec 2013 11:06:49 GMT Message-Id: <201312091106.rB9B6nsj071076@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.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 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/184311 net [bge] [panic] kernel panic with bge(4) on SunFire X210 o kern/184084 net [ral] kernel crash by ral (RT3090) o bin/183687 net [patch] route(8): route add -net 172.20 add wrong host o kern/183659 net [tcp] ]TCP stack lock contention with short-lived conn o conf/183407 net [rc.d] [patch] Routing restart returns non-zero exitco o kern/183391 net [oce] 10gigabit networking problems with Emulex OCE 11 o kern/183390 net [ixgbe] 10gigabit networking problems o kern/182917 net [igb] strange out traffic with igb interfaces o kern/182847 net [netinet6] [patch] Remove dead code o kern/182665 net [wlan] Kernel panic when creating second wlandev. o kern/182382 net [tcp] sysctl to set TCP CC method on BIG ENDIAN system o kern/182297 net [cm] ArcNet driver fails to detect the link address - o kern/182212 net [patch] [ng_mppc] ng_mppc(4) blocks on network errors o kern/181970 net [re] LAN Realtek 8111G is not supported by re driver o kern/181931 net [vlan] [lagg] vlan over lagg over mlxen crashes the ke o kern/181823 net [ip6] [patch] make ipv6 mroute return same errror code o kern/181741 net [kernel] [patch] Packet loss when 'control' messages a o kern/181703 net [re] [patch] Fix Realtek 8111G Ethernet controller not o kern/181657 net [bpf] [patch] BPF_COP/BPF_COPX instruction reservation o kern/181257 net [bge] bge link status change o kern/181236 net [igb] igb driver unstable work o kern/181135 net [netmap] [patch] sys/dev/netmap patch for Linux compat o kern/181131 net [netmap] [patch] sys/dev/netmap memory allocation impr o kern/181006 net [run] [patch] mbuf leak in run(4) driver o kern/180893 net [if_ethersubr] [patch] Packets received with own LLADD o kern/180844 net [panic] [re] Intermittent panic (re driver?) o kern/180775 net [bxe] if_bxe driver broken with Broadcom BCM57711 card o kern/180722 net [bluetooth] bluetooth takes 30-50 attempts to pair to s kern/180468 net [request] LOCAL_PEERCRED support for PF_INET o kern/180065 net [netinet6] [patch] Multicast loopback to own host brok o kern/179926 net [lacp] [patch] active aggregator selection bug o kern/179824 net [ixgbe] System (9.1-p4) hangs on heavy ixgbe network t o kern/179733 net [lagg] [patch] interface loses capabilities when proto o kern/179429 net [tap] STP enabled tap bridge o kern/179299 net [igb] Intel X540-T2 - unstable driver a kern/179264 net [vimage] [pf] Core dump with Packet filter and VIMAGE o kern/178947 net [arp] arp rejecting not working o kern/178782 net [ixgbe] 82599EB SFP does not work with passthrough und o kern/178612 net [run] kernel panic due the problems with run driver o kern/178472 net [ip6] [patch] make return code consistent with IPv4 co o kern/178079 net [tcp] Switching TCP CC algorithm panics on sparc64 wit s kern/178071 net FreeBSD unable to recongize Kontron (Industrial Comput o kern/177905 net [xl] [panic] ifmedia_set when pluging CardBus LAN card o kern/177618 net [bridge] Problem with bridge firewall with trunk ports o kern/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/177184 net [bge] [patch] enable wake on lan o kern/177139 net [igb] igb drops ethernet ports 2 and 3 o kern/176884 net [re] re0 flapping up/down o kern/176671 net [epair] MAC address for epair device not unique o kern/176484 net [ipsec] [enc] [patch] panic: IPsec + enc(4); device na o kern/176446 net [netinet] [patch] Concurrency in ixgbe driving out-of- o kern/176420 net [kernel] [patch] incorrect errno for LOCAL_PEERCRED o kern/176419 net [kernel] [patch] socketpair support for LOCAL_PEERCRED o kern/176401 net [netgraph] page fault in netgraph o kern/176167 net [ipsec][lagg] using lagg and ipsec causes immediate pa o kern/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 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 p 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/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/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis p kern/165903 net mbuf leak o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155680 net [multicast] problems with multicast s kern/155642 net [new driver] [request] Add driver for Realtek RTL8191S o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [new driver] [request]: Port brcm80211 driver from Lin o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl p kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph f kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121534 net [ipl] [nat] FreeBSD Release 6.3 Kernel Trap 12: o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] f kern/108197 net [panic] [gif] [ip6] if_delmulti reference counting pan o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104738 net [inet] [patch] Reentrant problem with inet_ntoa in the o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 472 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Dec 9 11:31:57 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B323DFA4 for ; Mon, 9 Dec 2013 11:31:57 +0000 (UTC) Received: from mail.euro-comm.net (mail.euro-comm.net [194.190.78.14]) by mx1.freebsd.org (Postfix) with ESMTP id 67945119C for ; Mon, 9 Dec 2013 11:31:57 +0000 (UTC) Received: from [192.168.0.4] (unknown [213.109.0.102]) by mail.euro-comm.net (Postfix) with ESMTPSA id 4618F6BD5E3; Mon, 9 Dec 2013 15:31:57 +0400 (MSK) Subject: Re: Netgraph ng_patch and ng_input: where to find packets? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=utf-8 From: Victor Gamov In-Reply-To: Date: Mon, 9 Dec 2013 15:31:55 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5293E3E7.6090604@freebsd.org> <52A493F1.6040700@freebsd.org> To: Sami Halabi X-Mailer: Apple Mail (2.1283) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 11:31:57 -0000 On 09Dec, 2013, at 13:51, Sami Halabi wrote: > What is ng_input cant find man page nor kldload it=E2=80=A6 ng_ip_input=20 sorry > Sami >=20 > =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A 9 =D7=91=D7=93=D7=A6=D7=9E 2013 = 11:30, "Victor Gamov" =D7=9B=D7=AA=D7=91: >=20 > On 09Dec, 2013, at 11:36, Sami Halabi wrote: >=20 > > Hi, >=20 > Hi Sami >=20 > > Actually following the ng_patch the following worked for me (using = 9.2-R -amd64): >=20 > Yes, ng_patch works fine for me too. Then ng_input works too because = I see patched packets at ipfw. But this packets does not appears on = outgoing interface. >=20 > Now I haven't machine for future testing, but I'll do more tests on = upcoming 10.0-R because I want to use 10.0 for my project. >=20 >=20 > > kldload ng_patch > > kldload ng_ipfw > > /usr/sbin/ngctl -f- << SEQ > > mkpeer ipfw: patch 300 in > > name ipfw:300 src_dst_chg > > msg src_dst_chg: setconfig { count=3D2 csum_flags=3D1= ops=3D[ \ > > { mode=3D1 value=3D0xc0a8e609 length=3D4 = offset=3D12 } \ > > { mode=3D1 value=3D0xc0a8e680 length=3D4 = offset=3D16 } ] } > > SEQ > > /sbin/ipfw add 600 netgraph 300 log ip from any to 239.0.0.19 = dst-port 1234 in via vlan999 > > > > Sami > > > > > > On Sun, Dec 8, 2013 at 5:44 PM, Julian Elischer = wrote: > > On 12/8/13, 6:43 PM, Sami Halabi wrote: > > Hi Gamov, > > Have got this to work? > > If so would share configurations? > > > > Thanks in advance, > > Sami > > =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A 29 =D7=91=D7=A0=D7=95=D7=91 = 2013 19:28, "Victor Gamov" =D7=9B=D7=AA=D7=91: > > > > > > > > if not then the way to track it it to put a breakpoint on the = netgraph node that handles the packet and just single step through until = you see where the packet goes.. > > kdb would give you a decent idea but a second machine (or a virtual = machine) with kgdb would really show you what's going on. -- CU, Victor Gamov From owner-freebsd-net@FreeBSD.ORG Mon Dec 9 13:07:05 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08C46A7F for ; Mon, 9 Dec 2013 13:07:05 +0000 (UTC) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CA856184B for ; Mon, 9 Dec 2013 13:07:04 +0000 (UTC) Received: by mail-pb0-f44.google.com with SMTP id rq2so5415902pbb.17 for ; Mon, 09 Dec 2013 05:07:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=K5zKPj+cr8UZUYMZAiuKzjSRrwf0pnzzLU1lfIytU8Q=; b=aMIPRqQIFwBm8To8yzxI7CMthICwwjhPibSx/NKNGfGPF+sbHmxT3ATDDRhG9epnB7 1/5SXEi9dyEHsT5BBx2zkrszlvGLmFZS76OtZd/rwI2vhqAzEkDLznxjIFW8CSBFzxc+ pRKYZ45cnvxnZCxhvCx+X2hPe24pv7MYSU9vBpDtw6F9a3iHeZDAvfA7xQbkbzy/ZajY bGptr9MiIe2/jXwIiIw7LdGzrZfmE8YMOUS/Gei3wXCwO5Y2Ly3clUbo7FxF+fpZO0SP TwVdq1/Ny2hKrSIeZtLfgD/ORlwg4ELe74FQSVy1S/cSnUkQqmVqOfByqsjAWxV0qXr8 W2LQ== MIME-Version: 1.0 X-Received: by 10.66.191.162 with SMTP id gz2mr4221535pac.151.1386594424311; Mon, 09 Dec 2013 05:07:04 -0800 (PST) Received: by 10.70.127.143 with HTTP; Mon, 9 Dec 2013 05:07:03 -0800 (PST) Received: by 10.70.127.143 with HTTP; Mon, 9 Dec 2013 05:07:03 -0800 (PST) In-Reply-To: References: <5293E3E7.6090604@freebsd.org> <52A493F1.6040700@freebsd.org> Date: Mon, 9 Dec 2013 15:07:03 +0200 Message-ID: Subject: Re: Netgraph ng_patch and ng_input: where to find packets? From: Sami Halabi To: Victor Gamov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 13:07:05 -0000 Hi, Got that, the manual is too short with no examples, can u share configuration u did? Sami =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A 9 =D7=91=D7=93=D7=A6=D7=9E 2013 13:31,= "Victor Gamov" =D7=9B=D7=AA=D7=91: > > On 09Dec, 2013, at 13:51, Sami Halabi wrote: > > > What is ng_input cant find man page nor kldload it=E2=80=A6 > > ng_ip_input > > sorry > > > Sami > > > > =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A 9 =D7=91=D7=93=D7=A6=D7=9E 2013 11= :30, "Victor Gamov" =D7=9B=D7=AA=D7=91: > > > > On 09Dec, 2013, at 11:36, Sami Halabi wrote: > > > > > Hi, > > > > Hi Sami > > > > > Actually following the ng_patch the following worked for me (using > 9.2-R -amd64): > > > > Yes, ng_patch works fine for me too. Then ng_input works too because I > see patched packets at ipfw. But this packets does not appears on outgoi= ng > interface. > > > > Now I haven't machine for future testing, but I'll do more tests on > upcoming 10.0-R because I want to use 10.0 for my project. > > > > > > > kldload ng_patch > > > kldload ng_ipfw > > > /usr/sbin/ngctl -f- << SEQ > > > mkpeer ipfw: patch 300 in > > > name ipfw:300 src_dst_chg > > > msg src_dst_chg: setconfig { count=3D2 csum_flags=3D= 1 > ops=3D[ \ > > > { mode=3D1 value=3D0xc0a8e609 length=3D4 off= set=3D12 > } \ > > > { mode=3D1 value=3D0xc0a8e680 length=3D4 off= set=3D16 > } ] } > > > SEQ > > > /sbin/ipfw add 600 netgraph 300 log ip from any to 239.0.0.19 dst-por= t > 1234 in via vlan999 > > > > > > Sami > > > > > > > > > On Sun, Dec 8, 2013 at 5:44 PM, Julian Elischer > wrote: > > > On 12/8/13, 6:43 PM, Sami Halabi wrote: > > > Hi Gamov, > > > Have got this to work? > > > If so would share configurations? > > > > > > Thanks in advance, > > > Sami > > > =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A 29 =D7=91=D7=A0=D7=95=D7=91 2013= 19:28, "Victor Gamov" =D7=9B=D7=AA=D7=91: > > > > > > > > > > > > if not then the way to track it it to put a breakpoint on the netgrap= h > node that handles the packet and just single step through until you see > where the packet goes.. > > > kdb would give you a decent idea but a second machine (or a virtual > machine) with kgdb would really show you what's going on. > > -- > CU, > Victor Gamov > > From owner-freebsd-net@FreeBSD.ORG Mon Dec 9 16:31:18 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0E9D3A7; Mon, 9 Dec 2013 16:31:18 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 92DDC18E8; Mon, 9 Dec 2013 16:31:18 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6C9A5B91E; Mon, 9 Dec 2013 11:31:17 -0500 (EST) From: John Baldwin To: "Justin T. Gibbs" , Roger Pau =?utf-8?q?Monn=C3=A9?= Subject: Re: Defaults for if_capenable and detecting user initiated changes Date: Fri, 6 Dec 2013 11:53:08 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <0E13D481-9D6D-4B52-A5AD-B671BF3A85AF@scsiguy.com> <201312031213.41677.jhb@freebsd.org> <526A243B-7B66-45BD-9B45-3BFB04F1E16D@scsiguy.com> In-Reply-To: <526A243B-7B66-45BD-9B45-3BFB04F1E16D@scsiguy.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201312061153.08202.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 09 Dec 2013 11:31:17 -0500 (EST) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 16:31:18 -0000 On Friday, December 06, 2013 11:25:48 am Justin T. Gibbs wrote: > On Dec 3, 2013, at 10:13 AM, John Baldwin wrote: >=20 > > On Wednesday, November 27, 2013 12:59:08 pm Justin T. Gibbs wrote: > >> Hi net, > >>=20 > >> I=E2=80=99m reviewing a patch from Roger Pau Monn=C3=A9 for the Xen ne= tfront driver. The=20 > > goal of the change is to avoid disturbing the user=E2=80=99s settings f= or the=20 > > interface just because the backend device has changed or the connection= to the=20 > > backend was reset. I=E2=80=99ve attached the latest version of the pat= ch. > >>=20 > >> The current patch leaves the interface settings alone if they can be=20 > > supported by the newly attached backend. What would be ideal is to ena= ble=20 > > capabilities that default to being enabled if they were not explicitly= =20 > > disabled by the user and can be supported by the new backend. Unfortun= ately,=20 > > I don=E2=80=99t think the if_capenable and if_capabilities fields are d= escriptive=20 > > enough to deal with an interface whose capabilities can change at runti= me. =20 > > Just as can be done with link speed, some of these settings need to all= ow an=20 > > =E2=80=9Cauto/default=E2=80=9D setting in addition to on or off. This = would allow the user to=20 > > explicitly disable a capability if needed, but generally allow the syst= em to=20 > > chose the most optimal settings when they are supported. Would this be= =20 > > difficult to add? > >=20 > > Couldn't you maintain this state in the Xen netfront driver's softc? > > You already get the ioctls that track changes to the capenable field, > > so you when a change explicitly disables a capability you can set that > > in a 'forced off' or 'forced on' field. Perhaps more of a 'forced' > > field that you just update by doing: > >=20 > > sc->capforced |=3D (oldcapenable ^ newcapenable) > >=20 > > However, it's not clear to me if you can get the underlying adapters > > initial capenable list. If so, I think capforced should be all you > > need to handle this (though it might be easier if you have separate > > forcedon and forcedoff fields). > >=20 > > --=20 > > John Baldwin >=20 > Certainly this could be done in the Xen driver. The reason I posted my q= uestion, however, was to ask whether this should be more generically=20 tracked by the if layer instead of handled by the underlying driver. Lots = of user interfaces support a =E2=80=9Crestore defaults=E2=80=9D capability = (e.g. for the=20 novice administrator who screws up, or as a step in writing a script/proced= ure that starts by getting to a known state), so I think this is=20 interesting for more than this particular Xen issue. Hmm. In terms of drivers where capenable can change at runtime, I think Xen's netfront is unique in that regard. However, it might be nice to know what the defaults are (basically, what the initial setting of if_capenable is). You could even just cache that when if_attach() is called without needing to change any drivers, just add a new ifnet field that if_attach() sets. =2D-=20 John Baldwin From owner-freebsd-net@FreeBSD.ORG Mon Dec 9 19:37:10 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 373325E1; Mon, 9 Dec 2013 19:37:10 +0000 (UTC) Received: from mail-qe0-x22a.google.com (mail-qe0-x22a.google.com [IPv6:2607:f8b0:400d:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BC2651988; Mon, 9 Dec 2013 19:37:09 +0000 (UTC) Received: by mail-qe0-f42.google.com with SMTP id b4so3312316qen.1 for ; Mon, 09 Dec 2013 11:37:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=El8VPbhSIyg8c51FQdlgpFq5BOoc/pgVy8TjbACYJMc=; b=dc8DH4vbZrYMG4vT7gCy6R+wHsRXDLIm4piY5XR1upMWVPzVS/fNm6WiU7iKDsyU0z fIEsAzDgAIrGYrzSS0K0TAA5Xd5+CYa9hCPmAJLde53gHsNItELThjIWSgjReJwtgXbc pVM18hDhvrcKrE0lbA8S+vQxVB5KV1C483VUf1EsVBxLI62BEr1aF1u+fmEUJ8oNc9JV +xZztlRBGuqok8V+wgnGl3w5DST46BzIafGQFnqf+gIFo7zfKXP+ghHxijZJIILBxePO S//wwc5w1ijtXt6iCFHiX0gvII8DKZaoWqB5vsqJe+dTLSEXwzw1n8LP7KPu5TWrt5jp VIOA== MIME-Version: 1.0 X-Received: by 10.49.116.141 with SMTP id jw13mr36506590qeb.2.1386617828872; Mon, 09 Dec 2013 11:37:08 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.53.200 with HTTP; Mon, 9 Dec 2013 11:37:08 -0800 (PST) In-Reply-To: References: <521B9C2A-EECC-4412-9F68-2235320EF324@lurchi.franken.de> <20131202022338.GA3500@michelle.cdnetworks.com> <20131203021658.GC2981@michelle.cdnetworks.com> <20131205223711.GB55638@funkthat.com> <3576B69E-E943-46E0-83E5-0B2194A44ED0@lurchi.franken.de> <20131206202012.GG55638@funkthat.com> <609C63CD-9332-4EAE-AACE-5B911416DF80@lurchi.franken.de> <9E163DC1-D647-4E19-BE23-44E5DFE2F284@lurchi.franken.de> Date: Mon, 9 Dec 2013 11:37:08 -0800 X-Google-Sender-Auth: YTnOWUyoFdpz37kf8jmPwCBGJBk Message-ID: Subject: Re: A small fix for if_em.c, if_igb.c, if_ixgbe.c From: Adrian Chadd To: Michael Tuexen , John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: Yong-Hyeon Pyun , Jack F Vogel , John-Mark Gurney , "freebsd-net@freebsd.org list" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 19:37:10 -0000 Jack / John - thoughts? -a On 8 December 2013 19:44, Adrian Chadd wrote: > .. I'm saying that we should have if_transmit( )return an error only > on the current packet, and 0 if it was queued. > > We don't have a mechanism to say that a queued packet actually made it > onto the wire. Whether we should is a different discussion. > > Ie, after thinking about this some more, I'd like to: > > * change if_transmit in these drivers to do exactly what you suggest - > it should return an error only if the given packet couldn't be queued. > It shouldn't matter whether it is later transmitted or not - we don't > have a feedback mechanism for that. > * figure out a very specific definition of what xxx_mq_start_locked() > should return - my gut feeling is an error if it couldn't queue a > frame, and 0 if it dispatched a frame to the hardware - and then make > the code match this definition. > > > > -adrian From owner-freebsd-net@FreeBSD.ORG Tue Dec 10 00:22:46 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8FB4745E for ; Tue, 10 Dec 2013 00:22:46 +0000 (UTC) Received: from nm25-vm2.bullet.mail.ne1.yahoo.com (nm25-vm2.bullet.mail.ne1.yahoo.com [98.138.91.213]) by mx1.freebsd.org (Postfix) with SMTP id 504B71F52 for ; Tue, 10 Dec 2013 00:22:46 +0000 (UTC) Received: from [98.138.100.102] by nm25.bullet.mail.ne1.yahoo.com with NNFMP; 10 Dec 2013 00:20:47 -0000 Received: from [98.138.87.9] by tm101.bullet.mail.ne1.yahoo.com with NNFMP; 10 Dec 2013 00:20:47 -0000 Received: from [127.0.0.1] by omp1009.mail.ne1.yahoo.com with NNFMP; 10 Dec 2013 00:20:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 508702.89738.bm@omp1009.mail.ne1.yahoo.com Received: (qmail 57724 invoked by uid 60001); 10 Dec 2013 00:20:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1386634847; bh=h30GFy6UwWp9wm0iXXCv05J2PCYv0v7T0ADXrI7aCRo=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=TUVxdFbrH9Z4n06NY2cDXR8r3hnC/hy6MWb01pK+vWzx24QgjS3aIbeRTY91StybyKjdNphT5DNmIwq6toaqj68jnI2jEceqS25G4PmVT3VQ+lJIuJOFK6CdNFKNVVoEnr1LsopWAYmRu0pHYJVJblP2iMubkAvtzoCa69fDSSQ= 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:Reply-To:Subject:To:MIME-Version:Content-Type; b=2YpZUO68MJQ8RVteI5Kw27to3Gq2cMFhXCVnXnuUIp/Ye7BCQDP+i7Ovverco/kQznuqFwYTJHeFYUTFhzjs0Q1TyuSB+90stwkDOCynT0KPIavRmJeW8pk67Qw4mPo9u4UvHqXddOpR9Pd00j3K6TEkyv/vJGDJlBJlORO7xYk=; X-YMail-OSG: 9y4eTh8VM1mqioBnV1agtEds9IUtr.HgrSqDzqc2siuow.7 995p2AX1id.6F69Ykl0p8cKkakTd1JouXqkEq384KcPWvAH8i4E8VJEM72Wx 4w5DAnJiPMBYEhMZ.sTKdH5wbNP3UHxY._XfvNbTJh2zHPM5ul.CDgP0OnBI B3yVE1F3Yq0izDKOdPLMjUP1c2kc76SMEf2jnrSSHSOJn_dLOVLcINVELEw. EtteazwPM1N7Ax9CruxjmKg0ASJ0AJic57po._ZhgGs_srTUeVJgBHfk8xsN UTb6..v3IONWTzfIMdos626ebtrZFx8d22SyQovkqEKIOI6FPRM45HK5VTbd C64rvgSd7mQ_KTaGlK8.PtLgRSC1dTJjAo8_0MWPgJcibKQ5yqjUJV8CIZ2n 02kMOp0Ssoz0Gg3QhwT6FFMO4Z9IRmKWio5QPwHL4rJtgZwwT2eDCgSSWSI6 sTVgoRHk4N27DepiLegvCGxlxzUvZ3uLttjC3do2XswulX.y8mM9jzr7CozX 0H7JzOXAiJglhzj_gU24wt5qazEw.RawKsS2xb9WuXJxc3eZn7Q8Top6TOEc dMjMBDI2FK7rL1gLgZ_joWAqo Received: from [98.203.118.124] by web121606.mail.ne1.yahoo.com via HTTP; Mon, 09 Dec 2013 16:20:47 PST X-Rocket-MIMEInfo: 002.001, V2h5IGlzIGl0IHRoYXQgZXZlcnkgdGltZSBJIGdldCBhIG5ldyBNQiBpdCBoYXMgeWV0LWFub3RoZXIgaW50ZWwgY29udHJvbGxlciBvbiBpdD8gSG93IGFyZSB5b3Ugc3VwcG9zZWQgdG8gd3JpdGUgZ29vZCBkcml2ZXJzIHRoYXQgc3VwcG9ydCA5MDAwIGRpZmZlcmVudCBjb250cm9sbGVycz8gQXMgbXVjaCBhcyBJIGFwcHJlY2lhdGUgdGhlIHByb2dyZXNzaW9uIG9mIENQVSB0ZWNobm9sb2d5LCB0aGV5CndvdWxkIHNlcnZlIHRoZSBjb21tdW5pdHkgYmV0dGVyIGJ5IG1ha2luZyB1cCB0aGVpciBkYW1uIG0BMAEBAQE- X-Mailer: YahooMailWebService/0.8.169.609 Message-ID: <1386634847.38473.YahooMailNeo@web121606.mail.ne1.yahoo.com> Date: Mon, 9 Dec 2013 16:20:47 -0800 (PST) From: Barney Cordoba Subject: Intel Controllers [Rant] To: "freebsd-net@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Barney Cordoba List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 00:22:46 -0000 Why is it that every time I get a new MB it has yet-another intel controlle= r on it? How are you supposed to write good drivers that support 9000 diffe= rent controllers? As much as I appreciate the progression of CPU technology= , they=0Awould serve the community better by making up their damn minds and= just build 1 or 2 controller for each=A0=0Atarget market.=0A=0ABC From owner-freebsd-net@FreeBSD.ORG Tue Dec 10 08:40:08 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 59F72713; Tue, 10 Dec 2013 08:40:08 +0000 (UTC) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BF4561164; Tue, 10 Dec 2013 08:40:07 +0000 (UTC) Received: by mail-vc0-f174.google.com with SMTP id id10so4252989vcb.5 for ; Tue, 10 Dec 2013 00:40:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Z/FczHGtKCWaoI5B7EYwKdKtwdc0+TS4QOXDKMhhkcQ=; b=qAGrlVpkpybMYZAOQca+yiWW3hpy1akF7JQ8/zYdY0r5FpJIahYzUGLXKQT4fz2uLM N4oMrdEB6P/11vScroVYwxTY/2ykju33oc6GPpuC1X/d3RT/feeKxXj7OPBjmn0vEn27 agCTO/DDbwOFA7OTefj2s5LrUZ/FzsuiCHsETfdvw7UEhski4zctuHGjFkXvuQ83pmsp 88oCGfHBzS9Pn02UzGKGwR90apYVWb5DL6KRKSlIpUFoqj38QtFw6X4SIuooA+udvHeW wRViYyUx41rtrJ3592/UN5CMy1USBjDXalG+Db2LvQ3x5Rnf+NiIwr6wVu8W6BKLsF2t m4Pw== MIME-Version: 1.0 X-Received: by 10.52.160.130 with SMTP id xk2mr201382vdb.24.1386664806799; Tue, 10 Dec 2013 00:40:06 -0800 (PST) Received: by 10.220.155.147 with HTTP; Tue, 10 Dec 2013 00:40:06 -0800 (PST) In-Reply-To: References: <521B9C2A-EECC-4412-9F68-2235320EF324@lurchi.franken.de> <20131202022338.GA3500@michelle.cdnetworks.com> <20131203021658.GC2981@michelle.cdnetworks.com> <20131205223711.GB55638@funkthat.com> <3576B69E-E943-46E0-83E5-0B2194A44ED0@lurchi.franken.de> <20131206202012.GG55638@funkthat.com> <609C63CD-9332-4EAE-AACE-5B911416DF80@lurchi.franken.de> <9E163DC1-D647-4E19-BE23-44E5DFE2F284@lurchi.franken.de> Date: Tue, 10 Dec 2013 00:40:06 -0800 Message-ID: Subject: Re: A small fix for if_em.c, if_igb.c, if_ixgbe.c From: Jack Vogel To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Yong-Hyeon Pyun , John Baldwin , "freebsd-net@freebsd.org list" , John-Mark Gurney , Jack F Vogel , Michael Tuexen X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 08:40:08 -0000 Hey Adrian, Didn't want you to think I was ignoring you, just kind of in the middle of some deadline issues and was not able to give this a lot of cycles. I've been reading the email seeing if some kind of consensus was formed, so far I'm not strongly convinced what's right. Does someone feel there is an urgent need to get this changed? Cheers, Jack On Mon, Dec 9, 2013 at 11:37 AM, Adrian Chadd wrote: > Jack / John - thoughts? > > > -a > > On 8 December 2013 19:44, Adrian Chadd wrote: > > .. I'm saying that we should have if_transmit( )return an error only > > on the current packet, and 0 if it was queued. > > > > We don't have a mechanism to say that a queued packet actually made it > > onto the wire. Whether we should is a different discussion. > > > > Ie, after thinking about this some more, I'd like to: > > > > * change if_transmit in these drivers to do exactly what you suggest - > > it should return an error only if the given packet couldn't be queued. > > It shouldn't matter whether it is later transmitted or not - we don't > > have a feedback mechanism for that. > > * figure out a very specific definition of what xxx_mq_start_locked() > > should return - my gut feeling is an error if it couldn't queue a > > frame, and 0 if it dispatched a frame to the hardware - and then make > > the code match this definition. > > > > > > > > -adrian > From owner-freebsd-net@FreeBSD.ORG Tue Dec 10 09:00: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A6215DC7 for ; Tue, 10 Dec 2013 09:00:40 +0000 (UTC) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 780B013B7 for ; Tue, 10 Dec 2013 09:00:40 +0000 (UTC) Received: by mail-pd0-f172.google.com with SMTP id g10so6957306pdj.3 for ; Tue, 10 Dec 2013 01:00:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=dAb2Fba3RQkrga4E0ZW5HRpByDKDrPo6pAqmsr1pgcw=; b=YKYSp7QLIKO0796QmaD3FNgyRLNIKCCl6l8jZFlHv/7/kzfWUz33DLo20hC5q5x+re 3Efpz2Zlu/nelswCwrzoa5r7FvJGrioi4XVc2n3q6lktpf5zEeWTz1m6xc3Eo6kHE7le pTWQVaxAww9njMd7I7rxldX1q1xrVHRZDO81J+pP+e9dF3xBqigEjUp9R8t9pIud5IhP Xpb2dvZVl+7Of1EBLSJrp2R9Oz1xtpcLxBwtW/aOjTLNhAO7Ty/4lITCzvMxgmggYC6z 21ZnFK0vBb9LwmPV/gpz9lL7Yf22OGxdAC2CQJIn2p2Pu+OSoGOA4ccdlocAGHQ2+WfR /ifg== X-Received: by 10.68.217.194 with SMTP id pa2mr1576221pbc.1.1386666040088; Tue, 10 Dec 2013 01:00:40 -0800 (PST) Received: from [192.168.1.7] (ppp59-167-128-11.static.internode.on.net. [59.167.128.11]) by mx.google.com with ESMTPSA id nn6sm23828324pbc.29.2013.12.10.01.00.38 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Dec 2013 01:00:39 -0800 (PST) Message-ID: <52A6D832.5080500@FreeBSD.org> Date: Tue, 10 Dec 2013 20:00:34 +1100 From: Kubilay Kocak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Thunderbird/26.0 MIME-Version: 1.0 To: Barney Cordoba , "freebsd-net@freebsd.org" Subject: Re: Intel Controllers [Rant] References: <1386634847.38473.YahooMailNeo@web121606.mail.ne1.yahoo.com> In-Reply-To: <1386634847.38473.YahooMailNeo@web121606.mail.ne1.yahoo.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: koobs@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, 10 Dec 2013 09:00:40 -0000 On 10/12/2013 11:20 AM, Barney Cordoba wrote: > Why is it that every time I get a new MB it has yet-another intel controller on it? How are you supposed to write good drivers that support 9000 different controllers? As much as I appreciate the progression of CPU technology, they > would serve the community better by making up their damn minds and just build 1 or 2 controller for each > target market. > > BC > _______________________________________________ > 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" > My view is that the driver of this is non-technical in nature. Business and retail technology consumers are cutthroat, with high expectations and demand for product development, innovation and value. Perception is reality, and new things shout "look! we're doing things". The more pertinent question is: how can we as a project scale to meet the current and future pace of change? A razor sharp focus, clear and public objectives and a shared view of what defines success is not a bad place to start. Proactive and effective resourcing of *prioritised* goals is the aim. Without them, success is a game of chance and accidental at best. Sorry if I was either too literal or too abstract in my response, and thanks for sharing :) Koobs From owner-freebsd-net@FreeBSD.ORG Tue Dec 10 17:47:53 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 90D3CD46 for ; Tue, 10 Dec 2013 17:47:53 +0000 (UTC) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 603BD1098 for ; Tue, 10 Dec 2013 17:47:53 +0000 (UTC) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 0645921BD4 for ; Tue, 10 Dec 2013 12:47:48 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute4.internal (MEProxy); Tue, 10 Dec 2013 12:47:49 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=nGsC6pKaGWKeEmlPrTBNFqD8Sbg=; b=V4N p4ONsY7XT4s4JwVIqeN8EVO2gqjFPl63SEsjPbVUvCT261/kCy70YiXSVfqxWiDO i0h2W7i3FDj9F5yKxhX29VMz3FDvoW3bV8h97aYD+lDYVjVOBjbwnUj/+1Zvbnzs ejoueGsixBYB672U4D23HwYZAwHGCpyN8rjE/kqI= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 19C851A3575; Tue, 10 Dec 2013 12:47:48 -0500 (EST) Message-Id: <1386697668.8944.57916449.7576FC53@webmail.messagingengine.com> X-Sasl-Enc: hglsGrtCya+5IRX9dPbb83VQUrufxzD2hG/hjHS4Lkgr 1386697668 From: Mark Felder To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: MessagingEngine.com Webmail Interface - ajax-605a1389 In-Reply-To: <1386634847.38473.YahooMailNeo@web121606.mail.ne1.yahoo.com> References: <1386634847.38473.YahooMailNeo@web121606.mail.ne1.yahoo.com> Subject: Re: Intel Controllers [Rant] Date: Tue, 10 Dec 2013 11:47:48 -0600 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 17:47:53 -0000 On Mon, Dec 9, 2013, at 18:20, Barney Cordoba wrote: > Why is it that every time I get a new MB it has yet-another intel > controller on it? How are you supposed to write good drivers that support > 9000 different controllers? As much as I appreciate the progression of > CPU technology, they > would serve the community better by making up their damn minds and just > build 1 or 2 controller for each=A0 > target market. >=20 I'm pretty sure an entirely new driver doesn't need to be written for each new controller. I assume like with most things (network cards, wifi chips, etc) it's usually a matter of adding its identifier to the driver code. It might be a foolish idea, but I've wondered for a while why drivers can't pick up a list of IDs from a file on the filesystem which could be distributed by, say, freebsd-update and then new ISOs could be rolled to include them. This probably presents too many layers of complexity and potential security issues, though. :-) From owner-freebsd-net@FreeBSD.ORG Tue Dec 10 18:13:13 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D540C5E7 for ; Tue, 10 Dec 2013 18:13:13 +0000 (UTC) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A3549127B for ; Tue, 10 Dec 2013 18:13:13 +0000 (UTC) Received: by mail-ig0-f174.google.com with SMTP id hk11so2634355igb.1 for ; Tue, 10 Dec 2013 10:13:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=a+TnKPDeNSIqtcXdmhqPw3aAt+zwT3oU0G+2iITBq+4=; b=BaySzKzE+K2tjnJ52JbKkk7Q6Qa1z8fUEJbuG3AieqMAGBTui0Lw6YYfyho6UAc0Rc h1lkiOS9gBnHCTy/1Sv9HGdCsmEx2V+5VkqU0rbHgd5Tzh0EbUVbhqCqAgi/QLmA/WMA 7/hJASZ1a0VIWmNg9ugwYuuuCMC5WiDtSXZyQ8Zh/F1D8x/ZH2aP4+y6tjFUlGbsrTpE mTtB/mexyJf/Ycp6PLZ79lD3Lphws0zJIfVQqBSP9hTtEln0wyN9HlyRm+QYRRLR0XTU jSO3LdSRwf64jiMqI3yLEpwf9edtBQ171oiXwMSpSwl5T4q0qqYBPK96LlHiJn97nD42 QBkA== X-Gm-Message-State: ALoCoQkLJ+0jzgqmtOXBVHrexHGSptfLilUkaiJwebzYnHx50ldHdm4fPCuDGjwwJ3kQizubkWha MIME-Version: 1.0 X-Received: by 10.50.129.39 with SMTP id nt7mr21398323igb.13.1386699187161; Tue, 10 Dec 2013 10:13:07 -0800 (PST) Received: by 10.50.57.230 with HTTP; Tue, 10 Dec 2013 10:13:07 -0800 (PST) In-Reply-To: <1386697668.8944.57916449.7576FC53@webmail.messagingengine.com> References: <1386634847.38473.YahooMailNeo@web121606.mail.ne1.yahoo.com> <1386697668.8944.57916449.7576FC53@webmail.messagingengine.com> Date: Tue, 10 Dec 2013 12:13:07 -0600 Message-ID: Subject: Re: Intel Controllers [Rant] From: Jim Thompson To: Mark Felder Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 18:13:13 -0000 On Tue, Dec 10, 2013 at 11:47 AM, Mark Felder wrote: > On Mon, Dec 9, 2013, at 18:20, Barney Cordoba wrote: >> Why is it that every time I get a new MB it has yet-another intel >> controller on it? How are you supposed to write good drivers that support >> 9000 different controllers? As much as I appreciate the progression of >> CPU technology, they >> would serve the community better by making up their damn minds and just >> build 1 or 2 controller for each >> target market. >> > > I'm pretty sure an entirely new driver doesn't need to be written for > each new controller. I assume like with most things (network cards, wifi > chips, etc) it's usually a matter of adding its identifier to the driver > code. It goes beyond that. In the simplest case, then yes, things are as you say. But chips have bugs, which require work-arounds, or other slightly strange stuff. Case(s) in-point: The 82575 assigns queues using vectors via a bitmask The Intel 82576 chip uses a table that essentially consists of 2 columns with 8 rows. The ordering is column-major (like Fortran arrays). On 82580 and newer adapters the scheme is similar to 82576, however instead of ordering column-major, the ordering is row-major (like C or Pascal). These chips are all supported via the igb driver. Some parts supported by the igb driver use MSI-X interrupts, others don't. On i350, i354, i210, and i211, loopback VLAN packets have the tag byte-swapped. The list of issues is by no means limited to the above. Jim From owner-freebsd-net@FreeBSD.ORG Tue Dec 10 18:17:15 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 53B5D878 for ; Tue, 10 Dec 2013 18:17:15 +0000 (UTC) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0CA5A12B7 for ; Tue, 10 Dec 2013 18:17:14 +0000 (UTC) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 2BD2D21FAC for ; Tue, 10 Dec 2013 13:17:04 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Tue, 10 Dec 2013 13:17:04 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=MWy vHusU1h59xl45gvxdTC2R0A8=; b=kUiKkZwP4pYWMcgZI7K2i/apJzpFpSMssjv 4XN5Fk+65MhTBAQD9buqrq5Yj+pKta7Kr8KYVtETfoPUjIUqTpvWHg+g14YjedLn RQubr5i0pq8R08RJfIRwiZA+d7RyyrUTTJFf6JahA03IxS3FeXAfiHwoOOKAsxKq 0F9u20lM= X-Sasl-enc: D+lfaUoZ0Ocnl28UierEILVekZjaRok2yS4kp3PR9Avn 1386699423 Received: from [172.16.1.145] (unknown [68.117.126.78]) by mail.messagingengine.com (Postfix) with ESMTPA id A3855C00E95; Tue, 10 Dec 2013 13:17:03 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_5727BAE7-DC4F-4F9B-87DB-043030333DD2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: Intel Controllers [Rant] From: Mark Felder In-Reply-To: Date: Tue, 10 Dec 2013 12:16:57 -0600 Message-Id: <7BE40656-3BF7-4D16-9E8F-392E612093D1@FreeBSD.org> References: <1386634847.38473.YahooMailNeo@web121606.mail.ne1.yahoo.com> <1386697668.8944.57916449.7576FC53@webmail.messagingengine.com> To: Jim Thompson X-Mailer: Apple Mail (2.1822) Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 18:17:15 -0000 --Apple-Mail=_5727BAE7-DC4F-4F9B-87DB-043030333DD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Dec 10, 2013, at 12:13, Jim Thompson wrote: > On Tue, Dec 10, 2013 at 11:47 AM, Mark Felder = wrote: >> On Mon, Dec 9, 2013, at 18:20, Barney Cordoba wrote: >>> Why is it that every time I get a new MB it has yet-another intel >>> controller on it? How are you supposed to write good drivers that = support >>> 9000 different controllers? As much as I appreciate the progression = of >>> CPU technology, they >>> would serve the community better by making up their damn minds and = just >>> build 1 or 2 controller for each >>> target market. >>>=20 >>=20 >> I'm pretty sure an entirely new driver doesn't need to be written for >> each new controller. I assume like with most things (network cards, = wifi >> chips, etc) it's usually a matter of adding its identifier to the = driver >> code. >=20 > It goes beyond that. In the simplest case, then yes, things are as = you say. >=20 > But chips have bugs, which require work-arounds, or other slightly > strange stuff. >=20 > Case(s) in-point: >=20 > The 82575 assigns queues using vectors via a bitmask > The Intel 82576 chip uses a table that essentially consists of 2 > columns with 8 rows. The ordering is column-major (like Fortran > arrays). > On 82580 and newer adapters the scheme is similar to 82576, however > instead of ordering column-major, the ordering is row-major (like C or > Pascal). >=20 > These chips are all supported via the igb driver. >=20 > Some parts supported by the igb driver use MSI-X interrupts, others = don't. >=20 > On i350, i354, i210, and i211, loopback VLAN packets have the tag = byte-swapped. >=20 > The list of issues is by no means limited to the above. >=20 > Jim That sounds tedious. Thanks to those of you that tirelessly hack away at = these quirks. When I first replied to this post I thought I was reading another list = and the discussion was about disk controllers which don't seem to be so = troublesome --Apple-Mail=_5727BAE7-DC4F-4F9B-87DB-043030333DD2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSp1qaAAoJEJg7ZFAfE+JSrX0H/jg1HSvzGskZDft8HyRapXIY zmSFuvcU879kBg+i1nSZV+TtUtIPiu0XHSkK5OmgHXa1hkoe2KXiG4UicYZI13hJ k3xz238iZo5h7NiB7hydJxVp6gK/R7Ksnb92gu8+c8aup1kT3/GHq5g9S/AosvAi pRkh2BpVfDpXZpCEkinqgfXA9E2UXU2hDDlxraosrCMGMXZySMIwUiFlvaCKVD5R DqkjL2KPHsIzgtC8LrTApwcQVDeCWUTBuvDNLbyJZP71hvsCQG44xUfKydQd2ORD 5zktEGnbtRs/D3R5oThb2TckepYy6xwbnqrvLeHBP6Ia2Hd0YvLquPUBWRay26s= =5b9e -----END PGP SIGNATURE----- --Apple-Mail=_5727BAE7-DC4F-4F9B-87DB-043030333DD2-- From owner-freebsd-net@FreeBSD.ORG Wed Dec 11 00:50:27 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 97741564 for ; Wed, 11 Dec 2013 00:50:27 +0000 (UTC) Received: from ns1.jnielsen.net (secure.freebsdsolutions.net [69.55.234.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 794A1105C for ; Wed, 11 Dec 2013 00:50:27 +0000 (UTC) Received: from [10.10.1.198] (office.betterlinux.com [199.58.199.60]) (authenticated bits=0) by ns1.jnielsen.net (8.14.4/8.14.4) with ESMTP id rBB0oNhb000488 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 10 Dec 2013 19:50:24 -0500 (EST) (envelope-from lists@jnielsen.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: How to forward UDP packets to another port and get responses with port translation? From: John Nielsen In-Reply-To: <529D053D.8050700@rawbw.com> Date: Tue, 10 Dec 2013 17:51:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <529D053D.8050700@rawbw.com> To: Yuri X-Mailer: Apple Mail (2.1822) X-DCC-sonic.net-Metrics: ns1.jnielsen.net 1156; Body=2 Fuz1=2 Fuz2=2 X-Virus-Scanned: clamav-milter 0.97.8 at ns1.jnielsen.net X-Virus-Status: Clean Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 00:50:27 -0000 On Dec 2, 2013, at 3:10 PM, Yuri wrote: > I would like to translate the port in all DNS requests, so that the = server works on the different port (ex. 1053) on the same net and the = client works on the original port 53. >=20 > I am thinking about two approaches: > * forward packets into the server: > ipfw add 200 fwd 192.168.10.1,1053 udp from 192.168.10.0/24 to = 192.168.10.1 53 > The problem with routing responses is that natd(8) doesn't allow to = change the source port, only the source address. There is -alias_address = option but no -alias_port option. >=20 > * divert and natd(8): > natd -port 8668 -interface tap0 -redirect_port udp 192.168.10.1:1053 = 53 > $IPF 200 divert natd udp from 192.168.10.0/24 to 192.168.10.1 53 via = tap0 keep-state >=20 > In both cases reply packets have the source port 1053, and it isn't = clear how to make it 53. > It seems that divert only passes to natd(8) packets from one = direction, and not from the other. >=20 > Is there a way to properly translate the ports back and forth in such = simple UDP communication? A single nat instance with redirect_port _should_ do what you are asking = for; in the above it looks like the responses are bypassing the nat. Here's an untested off-the-top-of-my head snippet (using libalias rather = than natd): ipfw nat 100 config ip 192.168.10.1 redirect_port udp 192.168.10.1:1053 = 53 ipfw add 100 nat 100 ip4 from 192.168.10.0/24 to 192.168.10.1 53 ipfw add 200 nat 100 ip4 from 192.168.10.1 1053 to 192.168.10.0/24 Hope that points you in the right direction. JN From owner-freebsd-net@FreeBSD.ORG Wed Dec 11 04:11:41 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 228EBD44; Wed, 11 Dec 2013 04:11:41 +0000 (UTC) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A57AC10A9; Wed, 11 Dec 2013 04:11:40 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id w5so4406083qac.13 for ; Tue, 10 Dec 2013 20:11:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=SLBr3LGofGn1KIxIctp3mP4zdDXVxsPKvdV6S2uTgpw=; b=fSmke5xLmducRAmpymgyIczduMtGs2RR5kjoLKKtSzck6RDbGymb2TtlcXOwjVoY9o DELOCW7OX6ApszgrM8ztK0+7IOJLWI5LEacIvK2MWZKZgV7pUeFYu2TVaZjW+w1K+P5P ICmeS85rsnVZaUakNNSQkRsITG/UPQIHWjdoVJYJM3Tnkjj8GYAH633vF3dofoO0D6rY QTnk/BU4jGqy56gid/N/JR+Jc/29OzZNRHV0TBAhjqvUNu+akitZRUjQzYzpXhg+D6Ap D6UfhuKBixqtP2YlALQBTFXrQl83fc2W87VLdKelWqCbcXVtEGnCg0WAOHJbJ7MrGSdb eKMQ== MIME-Version: 1.0 X-Received: by 10.224.80.129 with SMTP id t1mr162289103qak.95.1386735099825; Tue, 10 Dec 2013 20:11:39 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.53.200 with HTTP; Tue, 10 Dec 2013 20:11:39 -0800 (PST) In-Reply-To: References: <521B9C2A-EECC-4412-9F68-2235320EF324@lurchi.franken.de> <20131202022338.GA3500@michelle.cdnetworks.com> <20131203021658.GC2981@michelle.cdnetworks.com> <20131205223711.GB55638@funkthat.com> <3576B69E-E943-46E0-83E5-0B2194A44ED0@lurchi.franken.de> <20131206202012.GG55638@funkthat.com> <609C63CD-9332-4EAE-AACE-5B911416DF80@lurchi.franken.de> <9E163DC1-D647-4E19-BE23-44E5DFE2F284@lurchi.franken.de> Date: Tue, 10 Dec 2013 20:11:39 -0800 X-Google-Sender-Auth: yv6YQYNHAzOXo41ejA7vm30Tn_s Message-ID: Subject: Re: A small fix for if_em.c, if_igb.c, if_ixgbe.c From: Adrian Chadd To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Cc: Yong-Hyeon Pyun , John Baldwin , "freebsd-net@freebsd.org list" , John-Mark Gurney , Jack F Vogel , Michael Tuexen X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 04:11:41 -0000 Cool, no worries. -a On 10 December 2013 00:40, Jack Vogel wrote: > Hey Adrian, > > Didn't want you to think I was ignoring you, just kind of in the middle of > some deadline issues and was not able to give this a lot of cycles. > > I've been reading the email seeing if some kind of consensus was formed, > so far I'm not strongly convinced what's right. Does someone feel there is > an urgent need to get this changed? > > Cheers, > > Jack > > > > On Mon, Dec 9, 2013 at 11:37 AM, Adrian Chadd wrote: >> >> Jack / John - thoughts? >> >> >> -a >> >> On 8 December 2013 19:44, Adrian Chadd wrote: >> > .. I'm saying that we should have if_transmit( )return an error only >> > on the current packet, and 0 if it was queued. >> > >> > We don't have a mechanism to say that a queued packet actually made it >> > onto the wire. Whether we should is a different discussion. >> > >> > Ie, after thinking about this some more, I'd like to: >> > >> > * change if_transmit in these drivers to do exactly what you suggest - >> > it should return an error only if the given packet couldn't be queued. >> > It shouldn't matter whether it is later transmitted or not - we don't >> > have a feedback mechanism for that. >> > * figure out a very specific definition of what xxx_mq_start_locked() >> > should return - my gut feeling is an error if it couldn't queue a >> > frame, and 0 if it dispatched a frame to the hardware - and then make >> > the code match this definition. >> > >> > >> > >> > -adrian > > From owner-freebsd-net@FreeBSD.ORG Wed Dec 11 06:23:50 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BE9E5AFF for ; Wed, 11 Dec 2013 06:23:50 +0000 (UTC) Received: from elf.hq.norma.perm.ru (mail.norma.perm.ru [128.127.144.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 358151AF7 for ; Wed, 11 Dec 2013 06:23:49 +0000 (UTC) Received: from bsdrookie.norma.com. (bsdrookie.norma.com [192.168.7.71]) by elf.hq.norma.perm.ru (8.14.5/8.14.5) with ESMTP id rBB6NN8k044256 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 11 Dec 2013 12:23:24 +0600 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <52A804DB.8060402@norma.perm.ru> Date: Wed, 11 Dec 2013 12:23:23 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130709 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: ipsec: a weird guess Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [192.168.3.10]); Wed, 11 Dec 2013 12:23:24 +0600 (YEKT) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 06:23:50 -0000 Hi. I have two CARP'ed routers servicing gre/ipsec tunnels to another FreeBSD/i386, running 8.2-STABLE (since November 2011). 22 days ago I upgraded their ipsec peer to FreeBSD 10.0-BETA1/amd64. Two days ago I upgraded one of their DNS (yeah, it gets weirder) peers from 10.0-CURRENT/amd64 (March 2013) to 10.0-BETA1/amd64. And (finally) yesterday I started getting "panic: double fault" on both target routers. Like 4-5 minutes from start. One goes down, another get in, and goes down too. I know that technical mailing lists get a lots of crazy e-mails, and this sounds like another one, but in the past I was reporting at least two major ipsec issues (and they were fixed), so I'm not that crazy. These double faults are repeatable on both routers (they boot in and go down), first I thought that may be they both got a power outage, and bgfsck is causing panic, and so on - but panics stopped when I switched off ipsec and let the clear gre run. Now they are working. I upgraded one to 9.2-RELEASE-p2/i386, but this didn't help (same double fault). Is it worth reporting ? Double fault panic is similar to ones that can be found in google (only these rocket science numbers are different). I'm pretty sure it will go away after upgrading to 10.0/amd64. If someone would tell me that story I'd say "it's crazy and impossible" too. Thanks. Eugene. From owner-freebsd-net@FreeBSD.ORG Wed Dec 11 11:43:47 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D320BD0 for ; Wed, 11 Dec 2013 11:43:47 +0000 (UTC) Received: from cg6-p07-ob.rzone.de (cg6-p07-ob.rzone.de [IPv6:2a01:238:20a:202:5317::1]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B67471D8B for ; Wed, 11 Dec 2013 11:43:46 +0000 (UTC) X-RZG-CLASS-ID: cg07 Received: from magynato.store ([192.168.43.181]) by josoe.store (RZmta 32.17 OK) with ESMTP id 004e52pBBBSZmge for ; Wed, 11 Dec 2013 12:28:35 +0100 (CET) Received: (from Unknown UID 156611@localhost) by post.webmailer.de (8.13.7/8.13.7) id rBBBSZls007248; Wed, 11 Dec 2013 11:28:35 GMT Date: Wed, 11 Dec 2013 11:28:35 GMT Message-Id: <201312111128.rBBBSZls007248@post.webmailer.de> To: freebsd-net@freebsd.org Subject: Business From: Marissa Van Wiele MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-RZG-SCRIPT: :eD1KIhHmKqiFwrrxS/sX0alUXHwC++qwqlgAYXdZ4DukQGX6TsB3gRNP0/pKMKeNRbTY+NkWzUezgIdArpaaK08iD5MaKsmchgdoGR2htlGGleCGb5t3wC9t3wzTLhlYHHxofYKVzMMEnQZZIkRPkk71m9gAInNK2UQdHh1vlhd7DT1RcmfpsMUe2ILcGObTaNI2CqobO7Q0SGU= X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: marissavanwiele@yahoo.co.jp List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 11:43:47 -0000 Good Day, I am Marissa Van Wiele From United Kingdom. I have been a close friend and lawyer to Boris Berezovsky the former Russian self-made billionaire that went exile in UK and was later found dead in his house in he UK March 23/2013. Read link for more info about my client. http://www.businessweek.com/articles/2013-04-04/the-mysterious-death-of-russian-oligarch-boris-berezovsky We were together three days before his death, it has brought pains to everyone around the globe that knew him very well, he was a GOOD Man. Contact me through my Private Email:marissavanwiele@yahoo.co.jp What I intend to discuss with you will be of great benefit to both of us. Regards, Marissa Van Wiele From owner-freebsd-net@FreeBSD.ORG Wed Dec 11 16:22:11 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 511F6752 for ; Wed, 11 Dec 2013 16:22:11 +0000 (UTC) Received: from smtp.alterapraxis.com (unknown [101.164.33.212]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 90DBA1ADA for ; Wed, 11 Dec 2013 16:22:10 +0000 (UTC) Received: from smtp.alterapraxis.com (tony [127.0.0.1]) by smtp.alterapraxis.com (Postfix) with ESMTP id 200336331AA for ; Thu, 12 Dec 2013 03:10:45 +1100 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alterapraxis.com; s=alterapraxis; t=1386778245; bh=yan5tFHge/uOW/9SKQNN0pL/wwsb2ml0n5zmnl7F0t4=; h=Date:From:To:Subject:In-Reply-To:References; b=SDGLDPcGgg9ethafXqJMSh33vcBs5jZWvUTUzIaRuyrh42Fs9vn5PouerAVktKzEQ zn10kXJkdUs9J9U5UXPMQDGX61gZ9lqXbJLeW7TDjbQksu8vukL3lD2Vg5/6qPZB5n yYYhM+R8WihMgJNbBK2a3tHSFJEOZa63PDQk9fxs= Received: from [127.0.0.1] (localhost [127.0.0.1]) (using SSLv3 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: eocallaghan@alterapraxis.com) by smtp.alterapraxis.com (Postfix) with ESMTPSA id BB3FE6331A9 for ; Thu, 12 Dec 2013 03:10:44 +1100 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alterapraxis.com; s=alterapraxis; t=1386778244; bh=yan5tFHge/uOW/9SKQNN0pL/wwsb2ml0n5zmnl7F0t4=; h=Date:From:To:Subject:In-Reply-To:References; b=kgcf/nkHEKw0s87o/VACY182mBZrQM7IjNMdJQDLkSMQC5UezehXNz5B+qBGWb+PO Ix2prXrv/+z3JVzaUcUG7T2opqv4MfDRvCscfuV7terzzFxOCcH3S/9mADsZYg4JQW vp1MDVEeA0q1K3QkRnqJ/JfTT205Bxbq0vLKcUN0= Date: Thu, 12 Dec 2013 03:14:40 +1100 From: Edward O'Callaghan To: freebsd-net@freebsd.org Subject: Re: Intel Controllers [Rant] Message-ID: <20131212031440.692889f7.eocallaghan@alterapraxis.com> In-Reply-To: <7BE40656-3BF7-4D16-9E8F-392E612093D1@FreeBSD.org> References: <1386634847.38473.YahooMailNeo@web121606.mail.ne1.yahoo.com> <1386697668.8944.57916449.7576FC53@webmail.messagingengine.com> <7BE40656-3BF7-4D16-9E8F-392E612093D1@FreeBSD.org> Organization: Altera Praxis Pty Ltd Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA512; boundary="Sig_/5+okA/p+KM91IgnO+zNPrCT"; protocol="application/pgp-signature" X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 16:22:11 -0000 --Sig_/5+okA/p+KM91IgnO+zNPrCT Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 10 Dec 2013 12:16:57 -0600 Mark Felder wrote: >=20 > On Dec 10, 2013, at 12:13, Jim Thompson wrote: >=20 > > On Tue, Dec 10, 2013 at 11:47 AM, Mark Felder > > wrote: > >> On Mon, Dec 9, 2013, at 18:20, Barney Cordoba wrote: > >>> Why is it that every time I get a new MB it has yet-another intel > >>> controller on it? How are you supposed to write good drivers that > >>> support 9000 different controllers? As much as I appreciate the > >>> progression of CPU technology, they > >>> would serve the community better by making up their damn minds > >>> and just build 1 or 2 controller for each > >>> target market. > >>>=20 > >>=20 > >> I'm pretty sure an entirely new driver doesn't need to be written > >> for each new controller. I assume like with most things (network > >> cards, wifi chips, etc) it's usually a matter of adding its > >> identifier to the driver code. > >=20 > > It goes beyond that. In the simplest case, then yes, things are > > as you say. > >=20 > > But chips have bugs, which require work-arounds, or other slightly > > strange stuff. > >=20 > > Case(s) in-point: > >=20 > > The 82575 assigns queues using vectors via a bitmask > > The Intel 82576 chip uses a table that essentially consists of 2 > > columns with 8 rows. The ordering is column-major (like Fortran > > arrays). > > On 82580 and newer adapters the scheme is similar to 82576, however > > instead of ordering column-major, the ordering is row-major (like C > > or Pascal). > >=20 > > These chips are all supported via the igb driver. > >=20 > > Some parts supported by the igb driver use MSI-X interrupts, others > > don't. > >=20 > > On i350, i354, i210, and i211, loopback VLAN packets have the tag > > byte-swapped. > >=20 > > The list of issues is by no means limited to the above. > >=20 > > Jim >=20 > That sounds tedious. Thanks to those of you that tirelessly hack away > at these quirks. >=20 > When I first replied to this post I thought I was reading another > list and the discussion was about disk controllers which don't seem > to be so troublesome >=20 >=20 Another thing that can happen, given some hw rev. is that you in one rev. if you write values into registers in the wrong order you can actually get the hardware into undocumented states. This ends badly, typically locking up the hardware requiring soft-resets, although on occasion that may not even be sufficient ! Other times you may need to wait some time after banging on a register, typically overly long periods with Intel gear. In some cases you can actually irreparable damage the hw just because you did not wait and/or order some register twiddling correctly O_o Basically x86 sucks. Both Sun, IBM & Sgi designed things correctly with things like PROM's. The Intel UEFI firmware attempts to replicate these late 80's, early 90's ideas and fails horribly. The only hope aside from IBM POWER has been left with ARM, however that is quickly becoming a fragmented mess.. Cheers, --=20 ______________________________________________________________________ Edward O'Callaghan, Director and Principal consultant. https://www.alterapraxis.com | eocallaghan@alterapraxis.com Altera Praxis Pty Ltd, // Discretions in cybersecurity ACN 165 424 064. // reconnaissance and adversary mitigation. ______________________________________________________________________ --Sig_/5+okA/p+KM91IgnO+zNPrCT Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJSqI91AAoJENeyf/ug44dtlB4QALvVa+vD2qu+zdPZRvF/2C3E ct91P/N4MFseK8oBaCRGkelMj1gNgVIe8CHVZNSg8arknDAD+1hTmi09WiWM/147 j2mlX7JPoNS9+YPkxmROORNefNPlyiTs2YYVZmQ/kXyYVGOkbQhQM2wfD/xYVSn5 666mNhGxT5pLHYKNkQPaARC7hZDzBfcJbb6IikvD2kmMa8uYPuIocAf0L7btTXgB pwNYJmNJWPPF35tDQN73c07D85JDComJeX25EC2DTtL62yVRHCFVSkz5nkVUcNsh V/F3Ywnt0f6EStdTqQet4KWnSvsgx0RYxghsGgJ9MuPeEPu/Qq41MH7s0/HjWgxN YT8NAi1N0fuO7IGAszkHRD9Zz2IEwPHbNNYoXkcaVsUfFqpUu9Kw7gE9iI0LO1wC JSaNBTWDVieN0csU6VB1ILeQZetaQURxlwHbx0u0Y3SbRWsWLzM0e3XMeTmVrQ6y wGI+Vyp9irg4GRqfAE9fWfYSmyfVlFm6daKOsUsE3/WGy0lkvmsB6i7I07NIJw5z gxGB+HWih8CWSo4O7fzDPkSBhG9tTqrNvSQz/cO//hGNCcDAZlhFb5kKZeWz/Q+W ap+yn6eZ0ZDQBCvhnR1filVwRhLapQN20Z672Kyz0XJkSDjpkS0VhkCpxDAT7BEZ tnPOI7oGx0LtI+S6ujdY =tnGM -----END PGP SIGNATURE----- --Sig_/5+okA/p+KM91IgnO+zNPrCT-- From owner-freebsd-net@FreeBSD.ORG Wed Dec 11 20:14:35 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9CFC5C1B for ; Wed, 11 Dec 2013 20:14:35 +0000 (UTC) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 598F91378 for ; Wed, 11 Dec 2013 20:14:35 +0000 (UTC) Received: by mail-qc0-f174.google.com with SMTP id n7so5557249qcx.33 for ; Wed, 11 Dec 2013 12:14:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Lm3OQIAvXWS21hMW4d5No1sCTzPVMVN3USpNwBA46C8=; b=0+eNXgtT1CvKwB3ejoxZHzj5QXYQ5zN72JQMQ9mINJ8+W5hmG3cNmm+kg+xObHV4iL u7CMTGhQc8NGwUt3vL5yrOqSv9SsZcMMXazD/bp2MJ4T9aTKqr0J00kDHg51xCyNWtO3 AB7FC3aHIqq+7UMObC/a6u4TSTVPIbRoAMvOfWB3Hk6ROesZ/91BWJzCcdsJU4SsdMxS iUulgxwx5bRWOvdZSd8TNuVeZ77mq5wmb+vRwBicX6M5AlyNdcwn6v5NGXOnJgZUW/5Q r50DCPik2N+7iDL6qb7T1U3owVhqFokxhZOfckD3eCuLj+cBPTWvWQ5u/r/cWIaKOWtg Rl2g== MIME-Version: 1.0 X-Received: by 10.224.80.129 with SMTP id t1mr5996715qak.95.1386792874421; Wed, 11 Dec 2013 12:14:34 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.53.200 with HTTP; Wed, 11 Dec 2013 12:14:34 -0800 (PST) In-Reply-To: <20131212031440.692889f7.eocallaghan@alterapraxis.com> References: <1386634847.38473.YahooMailNeo@web121606.mail.ne1.yahoo.com> <1386697668.8944.57916449.7576FC53@webmail.messagingengine.com> <7BE40656-3BF7-4D16-9E8F-392E612093D1@FreeBSD.org> <20131212031440.692889f7.eocallaghan@alterapraxis.com> Date: Wed, 11 Dec 2013 12:14:34 -0800 X-Google-Sender-Auth: 4FBfIVfeRYIqMetkX_XuGqGKEVs Message-ID: Subject: Re: Intel Controllers [Rant] From: Adrian Chadd To: "Edward O'Callaghan" Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 20:14:35 -0000 Current hardware for the most part gets rushed out to meet marketing schedules and marketing requirements. A lot of the time there are bugs that can't be fixed and are pushed out until the next chip run. Some bugs can be fixed by just changes to a final metal layer. Some bugs can be fixed by PROM mask bit changes that twiddle various internal bits in the chip (eg disabling/enabling function specific registers.) Some bugs require a full re-spin of the mask set. All of these happen at schedules that we consumers don't see. That's why you'll see this kind of seemingly schizophrenic behaviour. There may be one controller chip under the hood for a large number of silicon revisions but with features enabled/disabled, bugs fixed/reintroduced, etc. The irony is this - if they wanted to make perfect(er) chips, they'd end up spending so long and dumping so much money into it that it'd be unprofitable. Remember, CPUs are perfect(ish!) because we spend a lot more on them per chip than most ethernet controller chips, which I bet are measured in unit costs of a small number of dollars to begin with for the high end chips, and fractions of a dollar for what goes into laptops.. 2c, -adrian From owner-freebsd-net@FreeBSD.ORG Thu Dec 12 05:17:21 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E356BB3 for ; Thu, 12 Dec 2013 05:17:21 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BD4F61AF2 for ; Thu, 12 Dec 2013 05:17:20 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id m15so7262870wgh.1 for ; Wed, 11 Dec 2013 21:17:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=CMzZ/0+KK3ek8SeJ7jmb3fv51vlKUYWNUwTHEpa8jjQ=; b=QnDibydJTuHkwIOUzMME32xCmInQSIdtidRX+s56UyffO8IME9YN8BiZq/9D3tftwM v/KGLxjO0vXPJsUwFOFiJ9CeWhs477q372l/P84YZhLN1m9Ma8k94jiypyVjS0xZeLv+ Ji8s/Rs73sBJGzKCtRkwkPC1R/LmDlCXuLSZaz91OayiaxqFJJzg6vjV45GVFdwWColt zPRBAnZMkPSN0e9SHgUG0YSav1u3ma1gjQvd65FAPWn+qprRH6yQ8EesQeC72k8woVUG yl0V2/bSSRlu2+LTce7vXf+bw5E/viarVZvFbJG9VryjVQ+BjHugChPfnX8g/RAWXBtr Mlhg== X-Received: by 10.194.121.133 with SMTP id lk5mr280497wjb.77.1386825438463; Wed, 11 Dec 2013 21:17:18 -0800 (PST) MIME-Version: 1.0 Sender: s.khanchi@gmail.com Received: by 10.194.236.4 with HTTP; Wed, 11 Dec 2013 21:16:58 -0800 (PST) From: h bagade Date: Thu, 12 Dec 2013 08:46:58 +0330 X-Google-Sender-Auth: PXgXUWwbrgo6R-OIfb6T7JaAmLU Message-ID: Subject: Unable to attach physical interfaces to netmap vale switch To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 12 Dec 2013 05:17:21 -0000 Hi all, I've tried to attach my physical interfaces to vale using vale-ctl -a em1 and encountered the error: bdg_ctl [74] Unable to attach em1 to the bridge But I can bridge em0 and em1 using netmap bridge! I think if there is problem with registering the interface so I should not be able to bridge them but I can. What's missing here? From owner-freebsd-net@FreeBSD.ORG Thu Dec 12 05:32:58 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D834C188 for ; Thu, 12 Dec 2013 05:32:58 +0000 (UTC) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 76E861D33 for ; Thu, 12 Dec 2013 05:32:57 +0000 (UTC) Received: from mail.hotmail.com (col0-wss1-s3.col0.hotmail.com [157.56.23.10]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id F245127814E; Thu, 12 Dec 2013 14:32:54 +0900 (JST) Received: from BAY176-W25 ([157.56.23.7]) by col0-wss1-s3.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Dec 2013 21:32:52 -0800 X-TMN: [kOFS9Ltq0N9HXFVzhW3DbIixlHuhmxtJ] Message-ID: From: Michio Honda To: h bagade , "freebsd-net@freebsd.org" Subject: RE: Unable to attach physical interfaces to netmap vale switch Date: Thu, 12 Dec 2013 14:32:52 +0900 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 12 Dec 2013 05:32:52.0948 (UTC) FILETIME=[9A7DC140:01CEF6FB] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 12 Dec 2013 05:32:59 -0000 Hi=2C The behavior definitely seems a bug. Can you explain your OS (Linux or Free= BSD) and the way you installed netmap (downloaded from http://info.iet.unip= i.it/~luigi/netmap/ or one in FreeBSD10 or 11)? Cheers=2C- Michio > From: bagadeh@gmail.com > Date: Thu=2C 12 Dec 2013 08:46:58 +0330 > Subject: Unable to attach physical interfaces to netmap vale switch > To: freebsd-net@freebsd.org >=20 > Hi all=2C >=20 > I've tried to attach my physical interfaces to vale using > vale-ctl -a em1 > and encountered the error: > bdg_ctl [74] Unable to attach em1 to the bridge >=20 > But I can bridge em0 and em1 using netmap bridge! > I think if there is problem with registering the interface so I should no= t > be able to bridge them but I can. What's missing here? > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe=2C send any mail to "freebsd-net-unsubscribe@freebsd.org" >=20 = From owner-freebsd-net@FreeBSD.ORG Thu Dec 12 05:45:55 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1CC80353 for ; Thu, 12 Dec 2013 05:45:55 +0000 (UTC) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A85F51DCE for ; Thu, 12 Dec 2013 05:45:54 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id a1so7289130wgh.11 for ; Wed, 11 Dec 2013 21:45:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=hWyzhiW2WsVN7MFf7N0KvX2UhcNbTK32ZcjtUw3Fc1M=; b=VnUlM20SuqdiQ9eZhtU7nMN5e7Z/CaF4PI1JAgoD02gXVzaGA90NkIxG0WkkyclsMF 3WGV5XtvjAazZWS9p85B/04ximfG1xGwP/S2NRyQpK3yy87soF9iPxZgLP2H+K598ue+ j4tyfYBXRBQCwTvDL/Efbzpiwo9QbqwGR83sScL7FsfgxzHR8pnDWkLVjoQZhkQtMBvi 1y92YszLQ1gkEQl2wNaVdh/ELe/gPpc929e+h4BkXBsvvsKc/tsCs8O7+0M1HDQPRJh0 PsTHps2YVKmpBiWLer0WUaO2i5OgmpZIjM6j9SYVBP1dJ2s9H9Us5NLXgJG9d+tiDmgy blPw== X-Received: by 10.180.76.112 with SMTP id j16mr10111254wiw.32.1386827153050; Wed, 11 Dec 2013 21:45:53 -0800 (PST) MIME-Version: 1.0 Sender: s.khanchi@gmail.com Received: by 10.194.236.4 with HTTP; Wed, 11 Dec 2013 21:45:32 -0800 (PST) In-Reply-To: References: From: h bagade Date: Thu, 12 Dec 2013 09:15:32 +0330 X-Google-Sender-Auth: n-LfEn5MWJ9P6vCAOphw8A32QiE Message-ID: Subject: Re: Unable to attach physical interfaces to netmap vale switch To: Michio Honda Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 12 Dec 2013 05:45:55 -0000 On Thu, Dec 12, 2013 at 9:02 AM, Michio Honda wrote: > Hi, > > The behavior definitely seems a bug. Can you explain your OS (Linux > or FreeBSD) and the way you installed netmap (downloaded from > http://info.iet.unipi.it/~luigi/netmap/ or one in FreeBSD10 or 11)? > > Cheers, > - Michio > I'm using FreeBSD 10.0-BETA3. I've just added the device netmap option to kernel and compile it. From owner-freebsd-net@FreeBSD.ORG Thu Dec 12 10:59:25 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4BB6EA5E for ; Thu, 12 Dec 2013 10:59:25 +0000 (UTC) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1813F1382 for ; Thu, 12 Dec 2013 10:59:24 +0000 (UTC) Received: from [192.168.1.52] (FL1-122-135-85-157.tky.mesh.ad.jp [122.135.85.157]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 0493829C00A; Thu, 12 Dec 2013 19:59:23 +0900 (JST) Subject: Re: Unable to attach physical interfaces to netmap vale switch Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michio Honda In-Reply-To: Date: Thu, 12 Dec 2013 19:59:23 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <834132FA-5EEA-454F-AAD8-96D21EE0F834@sfc.wide.ad.jp> References: To: h bagade X-Mailer: Apple Mail (2.1283) Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 12 Dec 2013 10:59:25 -0000 OK, the problem you are facing is not reproducable in the=20 upstream code (I'm testing with VMware Fusion that emulates the=20 e1000 driver for guest). Can you send me tarball of the sys/dev/netmap directory, if you=20 have difficulty to upgrade your kernel? Since the code path relating to your problem is relatively simple, I would figure out the problem. Cheers, - Michio On Dec 12, 2013, at 2:45 PM, h bagade wrote: > On Thu, Dec 12, 2013 at 9:02 AM, Michio Honda = wrote: >=20 >> Hi, >>=20 >> The behavior definitely seems a bug. Can you explain your OS (Linux >> or FreeBSD) and the way you installed netmap (downloaded from >> http://info.iet.unipi.it/~luigi/netmap/ or one in FreeBSD10 or 11)? >>=20 >> Cheers, >> - Michio >>=20 >=20 > I'm using FreeBSD 10.0-BETA3. I've just added the device netmap option = to > kernel and compile it. > _______________________________________________ > 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 Thu Dec 12 18:02:40 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46C0B82E for ; Thu, 12 Dec 2013 18:02:40 +0000 (UTC) Received: from mail-oa0-x244.google.com (mail-oa0-x244.google.com [IPv6:2607:f8b0:4003:c02::244]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1276118A8 for ; Thu, 12 Dec 2013 18:02:40 +0000 (UTC) Received: by mail-oa0-f68.google.com with SMTP id h16so208724oag.7 for ; Thu, 12 Dec 2013 10:02:39 -0800 (PST) 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=PmlDkdAEcHcw3mrHhzREMqJLVTPJMV1H9bD75KkGb8Y=; b=FzQIkPwsUuirjvznUxL6bzOIpydoTveC56SAGu73AREtaMCx4MXOE9/k9BwgipswUa Dv6+sEvu6vXNE3q9s7SUdQqiZJeA3a7U16GXEaS4151eakTU97ko4p/3SDg1GgpOw/HB 5DSsDESZgwPzzfTyXWdvdswhLbiJdFBjupvsCUvS9MyAqgGRfSVbnSljP5JSFRJjH0Lg bIgxDkVwHliKEwX+p9VIH75w37PPTbrD16UsMNnkUo66ubeX4+Ery6yVfJQI1PLZDhSM oxcI2yDS42EmqqQZubRlII+riWm0zxKjTp/THF5bYQzNCpOLOdPs5GFLU+eRqk3j4cFh EJfg== MIME-Version: 1.0 X-Received: by 10.60.44.193 with SMTP id g1mr6479808oem.47.1386871359229; Thu, 12 Dec 2013 10:02:39 -0800 (PST) Received: by 10.76.160.69 with HTTP; Thu, 12 Dec 2013 10:02:39 -0800 (PST) Date: Thu, 12 Dec 2013 23:32:39 +0530 Message-ID: Subject: Netmap support for Virtual network driver From: Thirunavukarasu S To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 12 Dec 2013 18:02:40 -0000 Hi I am running a Virtual Linux machine on Hyper-v Microsoft Hypervisor. I am using netvsc drivers provided by Microsoft for virtual interfaces. Now I would like to add Netmap support for netvsc driver, after coming to know about its wide advantages. Does Netmap support for Microsoft Hyper-v Network drivers is already in place. or could you help in integrating netmap support in our netvsc drivers. Thanks Thiru. From owner-freebsd-net@FreeBSD.ORG Thu Dec 12 19:24:37 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 36472B1F for ; Thu, 12 Dec 2013 19:24:37 +0000 (UTC) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A0CE71FFC for ; Thu, 12 Dec 2013 19:24:36 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id ec20so669198lab.15 for ; Thu, 12 Dec 2013 11:24:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8TIwt9p/PiERo2zfxTziXcECec2nMr4g7l48K1mUdmc=; b=A1YgRyPLHKAPJFjBmiUvgLy42vai0PYyo+goa8mDnNKa66h8GOnPASkrLymV6UGL6G UR1vt5nBc4UrlslTvpriQ5YHTpZCiS6NMcMywlOd1+BaS8+j4ZNl9w+FQfaqh0IjCISr Q9QlLD5c1HyqLlcGkYB1yXFTtql9wC49qOXiiiOcRlR0y0g7/CK8hcm1gAXQZO5exePr vLc/+rHzBFVp+BoAIAAjxVCeWNcmz2lHq4RtMWgv1VfXDHyX/8JpIEfb0oWW7RPgMOTf 68dZvSTnZDE6qqfEM6d5hs4gn57KHjkHazScQhGhQFSgsCSIWfY6lXaCdO9sKQgWauxl B1ZA== MIME-Version: 1.0 X-Received: by 10.152.21.74 with SMTP id t10mr4167593lae.65.1386876274515; Thu, 12 Dec 2013 11:24:34 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.175.180 with HTTP; Thu, 12 Dec 2013 11:24:34 -0800 (PST) In-Reply-To: References: Date: Thu, 12 Dec 2013 20:24:34 +0100 X-Google-Sender-Auth: sFCMuTeDl4VXmrYRZGtXSArLuss Message-ID: Subject: Re: Netmap support for Virtual network driver From: Luigi Rizzo To: Thirunavukarasu S Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 12 Dec 2013 19:24:37 -0000 On Thu, Dec 12, 2013 at 7:02 PM, Thirunavukarasu S wrote: > Hi > > I am running a Virtual Linux machine on Hyper-v Microsoft Hypervisor. > > I am using netvsc drivers provided by Microsoft for virtual interfaces. > > Now I would like to add Netmap support for netvsc driver, after coming to > know about its wide advantages. > > Does Netmap support for Microsoft Hyper-v Network drivers is already in > place. > > or could you help in integrating netmap support in our netvsc drivers. > we can definitely help with the integration as long as you have the hyperv drivers for the guest in source format another option might be to use the e1000 emulation in hyperv. but in any case don't hold your breath for performance, because chances are that the network I/O path in the hypervisor (hyperv in this case) is not able to sustain the data rates that netmap can generate. See the paper at this link to see what we did for QEMU/KVM http://info.iet.unipi.it/~luigi/papers/20130903-rizzo-ancs.pdf to make it run at netmap speeds cheers luigi > > > Thanks > Thiru. > _______________________________________________ > 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 Fri Dec 13 15:48:21 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 589D8B18 for ; Fri, 13 Dec 2013 15:48:21 +0000 (UTC) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0822D1387 for ; Fri, 13 Dec 2013 15:48:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15442; q=dns/txt; s=iport; t=1386949701; x=1388159301; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rWXCxlf3xzRL0LPnUohwaFrwR1L2Ntv4/yXWJpXdndQ=; b=WGUEvkS+4IYHY7ykuQSL0nBa+2b733H1ly8GQOaeShOrAt0eV7hiiwvO GtA3ytoZdXH+osNA1cdZCsVev6vR3X3aK8ouSwPSZcFn4sGa6w+AnFcTy uUoW4US9s+o6Az7RPeuqKBML4Cmcsl3iqtR3NJEE0qOi9pbzYxkvLebmP 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgHAPYrq1KtJV2b/2dsb2JhbABZFoIwRDhVsAyIA06BIxZ0giUBAQECAgEBASohIAsQAgEIEQMBAgsdBx8CBgEJARQJCAIECAYBBAEHFQSHTwMRDcN1DYcKF40CgUIBAR4gEQYBBoMdgRMEjliGb2SDG4sqA4U3gyptgQQ5 X-IronPort-AV: E=Sophos;i="4.95,479,1384300800"; d="scan'208,217";a="6604286" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP; 13 Dec 2013 15:48:19 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rBDFmJNt020094 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Dec 2013 15:48:19 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.234]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Fri, 13 Dec 2013 09:48:18 -0600 From: "Thirunavukarasu Sengalvarayan -X (tsengalv - HCL TECHNOLOGIES LIMITED at Cisco)" To: "rizzo@iet.unipi.it" Subject: RE: Netmap support for Virtual network driver Thread-Topic: Netmap support for Virtual network driver Thread-Index: AQHO9/dAqTEOXnSetUSeuf+Drq+Rk5pSBvew Date: Fri, 13 Dec 2013 15:48:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-Auto-Response-Suppress: DR, OOF, AutoReply X-MS-TNEF-Correlator: x-originating-ip: [10.77.138.163] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "waas-dev-hyperv\(mailer list\)" , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 15:48:21 -0000 (Continuing with below mail thread.) Hi Luigi, Thanks a lot for your quick response. Yes we have the source base for hyper-v network driver. Could you please provide us the patch for Netmap support in Hyper-v Network= drivers. Hyper-v has two kinds of NIC, emulated and Synthetic. In general emulated network drivers are relatively slow when compared to Sy= nthetic network drivers. Hence we planned to use synthetic network drivers(netvsc). You have pointed that we could use e1000 emulation as another option. Which driver would be better in terms of performance, Netmap with emulation= driver or Netmap with synthetic driver? Thanks Thiru. ---------- Forwarded message ---------- From: Luigi Rizzo > Date: Fri, Dec 13, 2013 at 12:54 AM Subject: Re: Netmap support for Virtual network driver To: Thirunavukarasu S > Cc: "freebsd-net@freebsd.org" > On Thu, Dec 12, 2013 at 7:02 PM, Thirunavukarasu S > wrote: Hi I am running a Virtual Linux machine on Hyper-v Microsoft Hypervisor. I am using netvsc drivers provided by Microsoft for virtual interfaces. Now I would like to add Netmap support for netvsc driver, after coming to know about its wide advantages. Does Netmap support for Microsoft Hyper-v Network drivers is already in place. or could you help in integrating netmap support in our netvsc drivers. we can definitely help with the integration as long as you have the hyperv drivers for the guest in source format another option might be to use the e1000 emulation in hyperv. but in any case don't hold your breath for performance, because chances are that the network I/O path in the hypervisor (hyperv in this case) is not able to sustain the data rates that netmap can generate. See the paper at this link to see what we did for QEMU/KVM http://info.iet.unipi.it/~luigi/papers/20130903-rizzo-ancs.pdf to make it run at netmap speeds cheers luigi Thanks Thiru. _______________________________________________ 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. d= i 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 Fri Dec 13 17:02:55 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17C196A0 for ; Fri, 13 Dec 2013 17:02:55 +0000 (UTC) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7E481195F for ; Fri, 13 Dec 2013 17:02:54 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id er20so1596919lab.36 for ; Fri, 13 Dec 2013 09:02:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=1KqJeCi40LPtnP+ZMWgCrHnDq0NYwzPwqL9ZBQMJ++c=; b=rpYjq2BHLrjzbuSFMJMzpIM0jVAdLSGNq4ElBeQv29wqhCviKNzUbDpTvN+q1FTFtO 3e5R3YoyGPOOgPphh+eSo/XKM2ITuK2GhTFLW6eb+TLeWzMwlnzDBfyZRBbq0+MJ9+Is 4dR4solnVkSJFJYDqvH/OE5tI66RFhGlvluJFMN/JoPqmru8j5jNpJ03y/1NWKuJRprX CmDRVEXNUTvK0qlV8b6JeYPluedP2zwcTxIZIKHJe+3YGqXBQtlKnXtk/MiU5QTK2EKF zW/h6xRfln0Lqo6zAiY44Tif6nOLAQOf4eVHcAGqZ8+KUupzxT4tw1cCXvZPOULwn+bO AIcg== MIME-Version: 1.0 X-Received: by 10.152.197.35 with SMTP id ir3mr2155875lac.54.1386954172540; Fri, 13 Dec 2013 09:02:52 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.175.180 with HTTP; Fri, 13 Dec 2013 09:02:52 -0800 (PST) In-Reply-To: References: Date: Fri, 13 Dec 2013 18:02:52 +0100 X-Google-Sender-Auth: 6HwIwz7k5Ho2JWU2iAmi-PbaLDg Message-ID: Subject: Re: Netmap support for Virtual network driver From: Luigi Rizzo To: "Thirunavukarasu Sengalvarayan -X (tsengalv - HCL TECHNOLOGIES LIMITED at Cisco)" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "waas-dev-hyperv\(mailer list\)" , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 17:02:55 -0000 On Fri, Dec 13, 2013 at 4:48 PM, Thirunavukarasu Sengalvarayan -X (tsengalv - HCL TECHNOLOGIES LIMITED at Cisco) wrote: > (Continuing with below mail thread.) > > > > Hi Luigi, > > > > Thanks a lot for your quick response. > > Yes we have the source base for hyper-v network driver. > > Could you please provide us the patch for Netmap support in Hyper-v > Network drivers. > sorry i meant that if you send us the guest driver sources we can try to add netmap support to them. > Hyper-v has two kinds of NIC, emulated and Synthetic. > > In general emulated network drivers are relatively slow when compared to > Synthetic network drivers. > Hence we planned to use synthetic network drivers(netvsc). > > You have pointed that we could use e1000 emulation as another option. > > Which driver would be better in terms of performance, Netmap with > emulation driver or Netmap with synthetic driver? > > > it all depends on your usage pattern, on how bad is the hypervisor at emulating the e1000, and especially how slow is the network backend (virtual switch) used. In general netmap operates in batches and especially for the receive side it overcomes some of the limitation of emulation, often leaving the virtual switch as the bottlenecks. In the paper we referenced we elaborate further. in practice, i'd suggest to start with e1000 emulation and see what kind of performance you are getting, and post the numbers so i can tell whether it is worthwhile trying to use a modified synthetic driver. cheers luigi > Thanks > > Thiru. > > > > ---------- Forwarded message ---------- > From: *Luigi Rizzo* > Date: Fri, Dec 13, 2013 at 12:54 AM > Subject: Re: Netmap support for Virtual network driver > To: Thirunavukarasu S > Cc: "freebsd-net@freebsd.org" > > > > > > On Thu, Dec 12, 2013 at 7:02 PM, Thirunavukarasu S > wrote: > > Hi > > I am running a Virtual Linux machine on Hyper-v Microsoft Hypervisor. > > I am using netvsc drivers provided by Microsoft for virtual interfaces. > > Now I would like to add Netmap support for netvsc driver, after coming to > know about its wide advantages. > > Does Netmap support for Microsoft Hyper-v Network drivers is already in > place. > > or could you help in integrating netmap support in our netvsc drivers. > > > > we can definitely help with the integration > > as long as you have the hyperv > > drivers for the guest in source format > > > > another option might be to use the e1000 emulation > > in hyperv. > > > > but in any case don't hold your breath for performance, > > because chances are that the network I/O path in the > > hypervisor (hyperv in this case) is not able to > > sustain the data rates that netmap can generate. > > > > See the paper at this link to see what we did for QEMU/KVM > > > > http://info.iet.unipi.it/~luigi/papers/20130903-rizzo-ancs.pdf > > > > > > to make it run at netmap speeds > > > > cheers > > luigi > > > > Thanks > Thiru. > _______________________________________________ > 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) > -----------------------------------------+------------------------------- > > > -- -----------------------------------------+------------------------------- 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 Fri Dec 13 17:32:11 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 356F01D6 for ; Fri, 13 Dec 2013 17:32:11 +0000 (UTC) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A4C011CB5 for ; Fri, 13 Dec 2013 17:32:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28004; q=dns/txt; s=iport; t=1386955930; x=1388165530; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=t4mE0Ksg+K0GyaB8lozeTxL8QtoGH0kdV3XdAWem3+8=; b=mi86h/hMP8wc/e/OIlZLA5jT10ihHfLgRq0WfNyX1Cdmel4YymwQpkVZ /JUtAdZrrrdO7FtLQ1oey7Ko0zI+pR1Oq65aNlv27xM3RejdJ/6yw2aFw qoiMCqebEhpYgT4Nlv7AcUPvv5UfLa4xyUryjwearpILJVGrjiNCHYGwc k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgHAJ5Dq1KtJV2d/2dsb2JhbABZFoIwRDhVsAyIA06BJRZ0giUBAQECAgEBASohIAsQAgEIEQMBAQELFgEGBx8CBgEJARQJCAIECAYBBAEHFQSHTwMRDcN+DYcKF40CgTsHAQEeIBEGAQaDHYETBI5Yhm9kgxuLKgOFN4MqbXsJFyI X-IronPort-AV: E=Sophos;i="4.95,480,1384300800"; d="scan'208,217";a="6624484" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-7.cisco.com with ESMTP; 13 Dec 2013 17:32:08 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rBDHW8Jq018882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Dec 2013 17:32:08 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.234]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Fri, 13 Dec 2013 11:32:08 -0600 From: "Thirunavukarasu Sengalvarayan -X (tsengalv - HCL TECHNOLOGIES LIMITED at Cisco)" To: Luigi Rizzo Subject: RE: Netmap support for Virtual network driver Thread-Topic: Netmap support for Virtual network driver Thread-Index: AQHO9/dAqTEOXnSetUSeuf+Drq+Rk5pSBvewgAC4AQD//5/isA== Date: Fri, 13 Dec 2013 17:32:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-Auto-Response-Suppress: DR, OOF, AutoReply X-MS-TNEF-Correlator: x-originating-ip: [10.77.138.163] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "waas-dev-hyperv\(mailer list\)" , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 17:32:11 -0000 Hi Luigi, Hyper-v Driver code is part of Linux kernel code now. I could see it from linux kernel version 3.3. The below link gives you hype= r-v driver code in latest kernel version. http://lxr.free-electrons.com/source/drivers/net/hyperv/ If you don't have the latest kernel code, please let me know I will send th= e hyper-v driver code from it. Thanks Thiru. From: rizzo.unipi@gmail.com [mailto:rizzo.unipi@gmail.com] On Behalf Of Lui= gi Rizzo Sent: Friday, December 13, 2013 10:33 PM To: Thirunavukarasu Sengalvarayan -X (tsengalv - HCL TECHNOLOGIES LIMITED a= t Cisco) Cc: waas-dev-hyperv(mailer list); net@freebsd.org Subject: Re: Netmap support for Virtual network driver On Fri, Dec 13, 2013 at 4:48 PM, Thirunavukarasu Sengalvarayan -X (tsengalv= - HCL TECHNOLOGIES LIMITED at Cisco) > wrote: (Continuing with below mail thread.) Hi Luigi, Thanks a lot for your quick response. Yes we have the source base for hyper-v network driver. Could you please provide us the patch for Netmap support in Hyper-v Network= drivers. sorry i meant that if you send us the guest driver sources we can try to add netmap support to them. Hyper-v has two kinds of NIC, emulated and Synthetic. In general emulated network drivers are relatively slow when compared to Sy= nthetic network drivers. Hence we planned to use synthetic network drivers(netvsc). You have pointed that we could use e1000 emulation as another option. Which driver would be better in terms of performance, Netmap with emulation= driver or Netmap with synthetic driver? it all depends on your usage pattern, on how bad is the hypervisor at emulating the e1000, and especially how slow is the network backend (virtual switch) used. In general netmap operates in batches and especially for the receive side it overcomes some of the limitation of emulation, often leaving the virtual switch as the bottlenecks. In the paper we referenced we elaborate further. in practice, i'd suggest to start with e1000 emulation and see what kind of performance you are getting, and post the numbers so i can tell whether it is worthwhile trying to use a modified synthetic driver. cheers luigi Thanks Thiru. ---------- Forwarded message ---------- From: Luigi Rizzo > Date: Fri, Dec 13, 2013 at 12:54 AM Subject: Re: Netmap support for Virtual network driver To: Thirunavukarasu S > Cc: "freebsd-net@freebsd.org" > On Thu, Dec 12, 2013 at 7:02 PM, Thirunavukarasu S > wrote: Hi I am running a Virtual Linux machine on Hyper-v Microsoft Hypervisor. I am using netvsc drivers provided by Microsoft for virtual interfaces. Now I would like to add Netmap support for netvsc driver, after coming to know about its wide advantages. Does Netmap support for Microsoft Hyper-v Network drivers is already in place. or could you help in integrating netmap support in our netvsc drivers. we can definitely help with the integration as long as you have the hyperv drivers for the guest in source format another option might be to use the e1000 emulation in hyperv. but in any case don't hold your breath for performance, because chances are that the network I/O path in the hypervisor (hyperv in this case) is not able to sustain the data rates that netmap can generate. See the paper at this link to see what we did for QEMU/KVM http://info.iet.unipi.it/~luigi/papers/20130903-rizzo-ancs.pdf to make it run at netmap speeds cheers luigi Thanks Thiru. _______________________________________________ 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. d= i Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotis= alvi 2 Mobile +39-338-6809875 . 56122 PISA= (Italy) -----------------------------------------+------------------------------- -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. d= i 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 Fri Dec 13 20:57:46 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 69D1CD72; Fri, 13 Dec 2013 20:57:46 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 402351CCA; Fri, 13 Dec 2013 20:57:46 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1D269B9A3; Fri, 13 Dec 2013 15:57:45 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: A small fix for if_em.c, if_igb.c, if_ixgbe.c Date: Fri, 13 Dec 2013 13:26:28 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <521B9C2A-EECC-4412-9F68-2235320EF324@lurchi.franken.de> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201312131326.28952.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 13 Dec 2013 15:57:45 -0500 (EST) Cc: Yong-Hyeon Pyun , Michael Tuexen , Adrian Chadd , Jack F Vogel , John-Mark Gurney X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 20:57:46 -0000 On Monday, December 09, 2013 2:37:08 pm Adrian Chadd wrote: > Jack / John - thoughts? Note that if_start has always worked the way if_transmit would work with the err = 0 change. All the other drivers in the tree are already giving you an error if an earlier packet in the IFQ fails to transmit, and it's been that way for decades. If you decide to make if_transmit precise (only return an error if the specific packet fails), the corresponding change for if_start() drivers would be to never return an error ever. It's not clear to me what the impact of that would be. However, the current patch to return 0 in the drbr_putback case would at least restore things to the previous status quo from the past few decades for both if_start() and if_transmit() drivers. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri Dec 13 21:31:07 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 278786A; Fri, 13 Dec 2013 21:31:07 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id E147A1FB4; Fri, 13 Dec 2013 21:31:06 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 87A437300A; Fri, 13 Dec 2013 22:24:30 +0100 (CET) Date: Fri, 13 Dec 2013 22:24:30 +0100 From: Luigi Rizzo To: net@freebsd.org Subject: IFF_DRV_OACTIVE handling in *_stop() for intel nic drivers ? Message-ID: <20131213212430.GA80282@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) Cc: jfv@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 21:31:07 -0000 I am trying to make sense of what is the intended handling of if_drv_flags in the *_stop() and *_init() routines for the intel nic drivers and i see three different patterns (below). I think the correct one is ixgbe.c which leaves IFF_DRV_OACTIVE alone, although one could argue that IFF_DRV_OACTIVE should be cleaned up just in case (as done in if_lem.c). What really seems wrong is setting the flag in the _stop() function as it is done in if_em.c and if_igb.c . So which one should we pick ? cheers luigi if_lem.c lem_stop() ... /* Tell the stack that the interface is no longer active */ ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); lem_init_locked() ... (near the end) ifp->if_drv_flags |= IFF_DRV_RUNNING; ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; if_em.c em_stop() ... /* Tell the stack that the interface is no longer active */ ifp->if_drv_flags &= ~IFF_DRV_RUNNING; ifp->if_drv_flags |= IFF_DRV_OACTIVE; em_init_locked() ... (near the end) /* Set the interface as ACTIVE */ ifp->if_drv_flags |= IFF_DRV_RUNNING; ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; if_igb.c igb_stop() ... /* Tell the stack that the interface is no longer active */ ifp->if_drv_flags &= ~IFF_DRV_RUNNING; ifp->if_drv_flags |= IFF_DRV_OACTIVE; igb_init_locked() ... (near the end) ifp->if_drv_flags |= IFF_DRV_RUNNING; ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; ixgbe.c ixgbe_stop() ... /* Let the stack know...*/ ifp->if_drv_flags &= ~IFF_DRV_RUNNING; ixgbe_init_locked() ... (at the very end) /* Now inform the stack we're ready */ ifp->if_drv_flags |= IFF_DRV_RUNNING; From owner-freebsd-net@FreeBSD.ORG Fri Dec 13 21:51:20 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 45576F8B; Fri, 13 Dec 2013 21:51:20 +0000 (UTC) Received: from mail-qe0-x236.google.com (mail-qe0-x236.google.com [IPv6:2607:f8b0:400d:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D21801157; Fri, 13 Dec 2013 21:51:19 +0000 (UTC) Received: by mail-qe0-f54.google.com with SMTP id cy11so2084560qeb.41 for ; Fri, 13 Dec 2013 13:51:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=tXs7giMQt1djVpqLahZ8x6pOU8qkU2TmqwC0AsB4zYA=; b=0mzruVXqdOaqoHAMMkJAExZlfDBDn/CTde3eC/OLRnOEVUX7G9CJA8Li0vG4es2X9e Qz1M8TxZRJFMFuAxFl99GFjh4oVqQSGCYiU2O5bNKxkNHQNVJ224ulpxORUECtSOKnua S6bsuoGSps6hiRGvnR/HrsULS5KxEtJqJiCeuzpArOZE0stalAvcmuLdfUk/NsUpz0sq T8I9ZNKJWp/x8pPJ5nFqlOSWgRfTwYegm6NtXfWVD5xrmdPBCUUsUiiY2a4AVaG3LJD+ POr5yZ+1coYK/AFEFRhV0tWnq8X/0eayJhifUzCZ2zpwO3f3BECW9Mq6xUCCP3kIYaFf 1cmg== MIME-Version: 1.0 X-Received: by 10.224.24.131 with SMTP id v3mr8878132qab.48.1386971478892; Fri, 13 Dec 2013 13:51:18 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.53.200 with HTTP; Fri, 13 Dec 2013 13:51:18 -0800 (PST) In-Reply-To: <201312131326.28952.jhb@freebsd.org> References: <521B9C2A-EECC-4412-9F68-2235320EF324@lurchi.franken.de> <201312131326.28952.jhb@freebsd.org> Date: Fri, 13 Dec 2013 13:51:18 -0800 X-Google-Sender-Auth: wauKSqR0z6ROP6rHujrBPWd2_Q0 Message-ID: Subject: Re: A small fix for if_em.c, if_igb.c, if_ixgbe.c From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: Yong-Hyeon Pyun , FreeBSD Net , John-Mark Gurney , Jack F Vogel , Michael Tuexen X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 21:51:20 -0000 On 13 December 2013 10:26, John Baldwin wrote: > On Monday, December 09, 2013 2:37:08 pm Adrian Chadd wrote: >> Jack / John - thoughts? > > Note that if_start has always worked the way if_transmit would work with the > err = 0 change. All the other drivers in the tree are already giving you an > error if an earlier packet in the IFQ fails to transmit, and it's been that > way for decades. If you decide to make if_transmit precise (only return an > error if the specific packet fails), the corresponding change for if_start() > drivers would be to never return an error ever. Right. If we want some kind of sane network behaviour moving forward we .. well, we have to define it as being sane. :-) IMHO if_start()'s API should've been: * queue something to the ifnet queue - fail it we can't queue it * call if_start() to start trying to transmit something - a failure is not that the queued frame failed, but the driver is unable to dequeue frames. Anyone using if_start() failing as "the frame i just queued failed to transmit" is broken and well, we should just replace it with if_transmit(). > It's not clear to me what the impact of that would be. However, the current > patch to return 0 in the drbr_putback case would at least restore things to > the previous status quo from the past few decades for both if_start() and > if_transmit() drivers. I believe the most correct return behaviour from if_transmit() is "the frame was successfully queued to the driver; it's now up to the driver to eventually send the frame." If the driver does direct dispatch then it'll error out if it couldn't queue the frame to the hardware TX descriptor ring/queue/blah. If the driver does its own queuing then it's up to the driver itself to fail on the hardware transmit function and then retry it when appropriate. It shouldn't be dropping frames during normal transmit unless there's some kind of policy in place to do so - and yes, this is a separate discussion to have with andre and rrs. -adrian From owner-freebsd-net@FreeBSD.ORG Fri Dec 13 21:52:45 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95306F9; Fri, 13 Dec 2013 21:52:45 +0000 (UTC) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 442E81170; Fri, 13 Dec 2013 21:52:45 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id j5so1207471qaq.14 for ; Fri, 13 Dec 2013 13:52:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=nwi2xysP+AaPzZd6A2D1DacmW5GmBVPEBslIwcLN4sk=; b=kNSwebv1n7DtXvKtOBeyYAAbquo4JehcxpT6AaChO7NhKNximH5VGYPqn6ibrTcf+v iOReZG3POPh+IkZ4akNOe4v5ytndan55SDBHGnSCn1ORtm21DuValmhcb3oiQqilIiyi MlR2v8O2uCWaoOFDdN1d6PRwYuA++4u0KPc17Hz8vlGjJ4J/Nuqma6L6h8u80vHkMZx5 EeRb7txyPx6yP17x3/R8j2gze88h19pvn3MYrJc6XHf+k5I+8X2Pw8hfuvVEBNXq31w/ ri30a1zlFu5n0Naa0j4rY4mBK477gPj0pVqZvzWG3MewAwfM7kNnVGEOi1BZz/3LKfrD JmpA== MIME-Version: 1.0 X-Received: by 10.224.89.73 with SMTP id d9mr8814196qam.5.1386971564414; Fri, 13 Dec 2013 13:52:44 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.53.200 with HTTP; Fri, 13 Dec 2013 13:52:44 -0800 (PST) In-Reply-To: <20131213212430.GA80282@onelab2.iet.unipi.it> References: <20131213212430.GA80282@onelab2.iet.unipi.it> Date: Fri, 13 Dec 2013 13:52:44 -0800 X-Google-Sender-Auth: 7PmzL_AOrB2iBaP2CBWLSlebWyo Message-ID: Subject: Re: IFF_DRV_OACTIVE handling in *_stop() for intel nic drivers ? From: Adrian Chadd To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Cc: Jack F Vogel , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 21:52:45 -0000 ... OACTIVE by design is racy. We should just not be using it in newer drivers. I think the correct thing to do is to just plain ignore setting it ever. -a On 13 December 2013 13:24, Luigi Rizzo wrote: > I am trying to make sense of what is the intended handling of > if_drv_flags in the *_stop() and *_init() routines for the > intel nic drivers and i see three different patterns (below). > I think the correct one is ixgbe.c which leaves IFF_DRV_OACTIVE alone, > although one could argue that IFF_DRV_OACTIVE should be cleaned > up just in case (as done in if_lem.c). > What really seems wrong is setting the flag in the _stop() > function as it is done in if_em.c and if_igb.c . > > So which one should we pick ? > > cheers > luigi > > if_lem.c > lem_stop() > ... > /* Tell the stack that the interface is no longer active */ > ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); > > lem_init_locked() > ... (near the end) > ifp->if_drv_flags |= IFF_DRV_RUNNING; > ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; > > > if_em.c > em_stop() > ... > /* Tell the stack that the interface is no longer active */ > ifp->if_drv_flags &= ~IFF_DRV_RUNNING; > ifp->if_drv_flags |= IFF_DRV_OACTIVE; > > em_init_locked() > ... (near the end) > /* Set the interface as ACTIVE */ > ifp->if_drv_flags |= IFF_DRV_RUNNING; > ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; > > if_igb.c > igb_stop() > ... > /* Tell the stack that the interface is no longer active */ > ifp->if_drv_flags &= ~IFF_DRV_RUNNING; > ifp->if_drv_flags |= IFF_DRV_OACTIVE; > > igb_init_locked() > ... (near the end) > ifp->if_drv_flags |= IFF_DRV_RUNNING; > ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; > > ixgbe.c > ixgbe_stop() > ... > /* Let the stack know...*/ > ifp->if_drv_flags &= ~IFF_DRV_RUNNING; > > ixgbe_init_locked() > ... (at the very end) > /* Now inform the stack we're ready */ > ifp->if_drv_flags |= IFF_DRV_RUNNING; > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Dec 13 22:17:36 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1B8411D; Fri, 13 Dec 2013 22:17:36 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 76C1F130C; Fri, 13 Dec 2013 22:17:36 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6DAE1B96C; Fri, 13 Dec 2013 17:17:35 -0500 (EST) From: John Baldwin To: Adrian Chadd Subject: Re: A small fix for if_em.c, if_igb.c, if_ixgbe.c Date: Fri, 13 Dec 2013 17:17:10 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <521B9C2A-EECC-4412-9F68-2235320EF324@lurchi.franken.de> <201312131326.28952.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201312131717.10863.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 13 Dec 2013 17:17:35 -0500 (EST) Cc: Yong-Hyeon Pyun , FreeBSD Net , John-Mark Gurney , Jack F Vogel , Michael Tuexen X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 22:17:36 -0000 On Friday, December 13, 2013 4:51:18 pm Adrian Chadd wrote: > On 13 December 2013 10:26, John Baldwin wrote: > > On Monday, December 09, 2013 2:37:08 pm Adrian Chadd wrote: > >> Jack / John - thoughts? > > > > Note that if_start has always worked the way if_transmit would work with the > > err = 0 change. All the other drivers in the tree are already giving you an > > error if an earlier packet in the IFQ fails to transmit, and it's been that > > way for decades. If you decide to make if_transmit precise (only return an > > error if the specific packet fails), the corresponding change for if_start() > > drivers would be to never return an error ever. > > Right. If we want some kind of sane network behaviour moving forward > we .. well, we have to define it as being sane. :-) > > IMHO if_start()'s API should've been: > > * queue something to the ifnet queue - fail it we can't queue it > * call if_start() to start trying to transmit something - a failure is > not that the queued frame failed, but the driver is unable to dequeue > frames. > > Anyone using if_start() failing as "the frame i just queued failed to > transmit" is broken and well, we should just replace it with > if_transmit(). Hmm, I was a bit wrong. Driver if_start routines return void, so they only failed if the IFQ filled up completely. In that case, I think it is fine to move forward with what you want (only return an error for failures involving the packet passed to if_transmit), but I don't think we should hange if_transmit drivers to just always return 0. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Sat Dec 14 01:20:19 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 177C0AEE; Sat, 14 Dec 2013 01:20:19 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id CD423128D; Sat, 14 Dec 2013 01:20:18 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id A47C47300A; Sat, 14 Dec 2013 02:23:08 +0100 (CET) Date: Sat, 14 Dec 2013 02:23:08 +0100 From: Luigi Rizzo To: Mike Karels Subject: Re: IFF_DRV_OACTIVE handling in *_stop() for intel nic drivers ? Message-ID: <20131214012308.GB82745@onelab2.iet.unipi.it> References: <201312140008.rBE08tnO062920@mail.karels.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201312140008.rBE08tnO062920@mail.karels.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Jack F Vogel , Adrian Chadd , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Dec 2013 01:20:19 -0000 On Fri, Dec 13, 2013 at 06:08:55PM -0600, Mike Karels wrote: > > ... OACTIVE by design is racy. We should just not be using it in newer drivers. > > > I think the correct thing to do is to just plain ignore setting it ever. > > I agree; OACTIVE is totally obsolete for drivers that use if_transmit, > and not particularly useful for other drivers. It might be time to remove > OACTIVE, or define it to be 0. (And I added the original IFF_OACTIVE). ok thanks for the clarification luigi From owner-freebsd-net@FreeBSD.ORG Sat Dec 14 05:04:58 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 775DDE91 for ; Sat, 14 Dec 2013 05:04:58 +0000 (UTC) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 44C4416C0 for ; Sat, 14 Dec 2013 05:04:58 +0000 (UTC) Received: by mail-oa0-f53.google.com with SMTP id m1so3039602oag.12 for ; Fri, 13 Dec 2013 21:04:57 -0800 (PST) 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=kl/0b3vzUbj1TE9U+5smN2hdv7LqOSz/AGsaGm6vO/w=; b=abTXphmDTHwoAEPlUIYGwQWwo7G3k9Jdq3oaQSy+Ditj98e50DYYXQbVSbl8D2tGh/ mXuYlrxB/Tsw7W0ZxgJwxEmIS1Wb4bKUwI/jwQPzO8ZyrOjcWUhMuPbNPcrc76cCrPqH Dz9wAF95tUFYWvMUjGLyPvDUZREkS8jodpDzmWr+RdBOmiSX4tRooPo4mRpslsAtBAEw OPAsCpaaELbtvtNuwY9CCn4wIGWckTvrN3Zyqtl1dW6zR3NmF/+8hKh6WwD2gamuuQSz ClNXL31l4tkcbHuEKWL7I57eXrM6GLjmvFlonHDI4V8cPQs5MSBaPhCNLNPNXfeoqU0m SjZw== MIME-Version: 1.0 X-Received: by 10.60.51.102 with SMTP id j6mr4230404oeo.6.1386997497483; Fri, 13 Dec 2013 21:04:57 -0800 (PST) Received: by 10.76.158.225 with HTTP; Fri, 13 Dec 2013 21:04:57 -0800 (PST) Date: Sat, 14 Dec 2013 00:04:57 -0500 Message-ID: Subject: buf_ring in HEAD is racy From: Ryan Stone To: freebsd-net Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Dec 2013 05:04:58 -0000 I am seeing spurious output packet drops that appear to be due to insufficient memory barriers in buf_ring. I believe that this is the scenario that I am seeing: 1) The buf_ring is empty, br_prod_head = br_cons_head = 0 2) Thread 1 attempts to enqueue an mbuf on the buf_ring. It fetches br_prod_head (0) into a local variable called prod_head 3) Thread 2 enqueues an mbuf on the buf_ring. The sequence of events is essentially: Thread 2 claims an index in the ring and atomically sets br_prod_head (say to 1) Thread 2 sets br_ring[1] = mbuf; Thread 2 does a full memory barrier Thread 2 updates br_prod_tail to 1 4) Thread 2 dequeues the packet from the buf_ring using the single-consumer interface. The sequence of events is essentialy: Thread 2 checks whether queue is empty (br_cons_head == br_prod_tail), this is false Thread 2 sets br_cons_head to 1 Thread 2 grabs the mbuf from br_ring[1] Thread 2 sets br_cons_tail to 1 5) Thread 1, which is still attempting to enqueue an mbuf on the ring. fetches br_cons_tail (1) into a local variable called cons_tail. It sees cons_tail == 1 but prod_head == 0 and concludes that the ring is full and drops the packet (incrementing br_drops unatomically, I might add) I can reproduce several drops per minute by configuring the ixgbe driver to use only 1 queue and then sending traffic from concurrent 8 iperf processes. (You will need this hacky patch to even see the drops with netstat, though: http://people.freebsd.org/~rstone/patches/ixgbe_br_drops.diff) I am investigating fixing buf_ring by using acquire/release semantics rather than load/store barriers. However, I note that this will apparently be the second attempt to fix buf_ring, and I'm seriously questioning whether this is worth the effort compared to the simplicity of using a mutex. I'm not even convinced that a correct lockless implementation will even be a performance win, given the number of memory barriers that will apparently be necessary. From owner-freebsd-net@FreeBSD.ORG Sat Dec 14 21:31:58 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D155DDB for ; Sat, 14 Dec 2013 21:31:58 +0000 (UTC) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BEB611051 for ; Sat, 14 Dec 2013 21:31:57 +0000 (UTC) Received: by mail-vb0-f50.google.com with SMTP id w18so2192638vbj.23 for ; Sat, 14 Dec 2013 13:31:56 -0800 (PST) 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=AyM9m+7n3/7OxKIlMTQ4Lfl2/7bO084t+BITYjYG6dc=; b=ybiwshmUhcA6eVWy39gl7azbz7JvaxXgdW/fxyQzqH7Q5C+HqWahYjI7M7ZIx42G78 bWBvhkvgPNdGaeIISkhFTTyiZ9n9s04ak02ErOgWMaM6U8JxqWB8aiaT6qZJPH4y5HHg 0nbc7XDHSnaCD+bVrEY9ScX/Vsp6AUdYxiIdyBq2X9VICEdeJdOhnBevM3nQV2CsI69Z l6TG/skzxfK1t5M50Oyn/DHenhXf8bS4dSFc2dh1Z7lasX1Omrm24jTYtxxCCNakos0u OQSGXAeHX5UtElyUDLEJqUlT9/N8IS3YkcZx2qyqDpNgAXOCDi94UEzHOTyxVqSUSI/j dkjg== MIME-Version: 1.0 X-Received: by 10.220.57.195 with SMTP id d3mr3619423vch.15.1387056716558; Sat, 14 Dec 2013 13:31:56 -0800 (PST) Received: by 10.52.180.130 with HTTP; Sat, 14 Dec 2013 13:31:56 -0800 (PST) Date: Sat, 14 Dec 2013 16:31:56 -0500 Message-ID: Subject: Re: RTL8111/8168B NIC & FreeBSD From: David Rufino To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Dec 2013 21:31:58 -0000 Hello, I'm having similar problems using an onboard RTL 8168B NIC. I noticed there were some recent changes to the re0 driver, so I tried -STABLE (r258961). The device is detected but can't send or receive packets. Interestingly it doesn't work in Debian wheezy, but does work fine in Windows 7 with latest drivers. I'm happy to assist in any way. Here's some relevant debugging information pciconf -l -v re0@pci0:1:0:0: class=0x020000 card=0x81161019 chip=0x816810ec rev=0x0c hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class = network subclass = ethernet re0: port 0xe000-0xe0ff mem 0xfea00000-0xfea00fff,0xd0800000-0xd0803fff irq 32 at device 0.0 on pci1 re0: Using 1 MSI-X message re0: ASPM disabled re0: Chip rev. 0x4c000000 re0: MAC rev. 0x00000000 miibus0: on re0 re0: Ethernet address: 74:27:ea:d3:de:5a Thanks!, David > > Hello, > > we are trying to install FreeBSD on a computer that uses the NIC mentioned > above. The NIC is running under linux without problems, which we've tested > for several days transferring several GB of data. From owner-freebsd-net@FreeBSD.ORG Sat Dec 14 22:01:53 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 24D7924A for ; Sat, 14 Dec 2013 22:01:53 +0000 (UTC) Received: from nm19-vm5.bullet.mail.ne1.yahoo.com (nm19-vm5.bullet.mail.ne1.yahoo.com [98.138.91.241]) by mx1.freebsd.org (Postfix) with SMTP id CA49E11D1 for ; Sat, 14 Dec 2013 22:01:52 +0000 (UTC) Received: from [98.138.226.177] by nm19.bullet.mail.ne1.yahoo.com with NNFMP; 14 Dec 2013 21:58:40 -0000 Received: from [98.138.226.133] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 14 Dec 2013 21:58:40 -0000 Received: from [127.0.0.1] by smtp220.mail.ne1.yahoo.com with NNFMP; 14 Dec 2013 21:58:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1387058320; bh=9y4djfmYsn37YiCYZHhjPSR3SkAnotokXPvBx7ESEuI=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=guhNOK8aC1mi9WMr+7eCJO2YL8wqE1Ny8ml8GKvxjvmgNnY+eXTMta8zBGztwoWR+4MRZFGV7rmQd9V9pHFbo35SEf7tq8QDuPS9OZGWzE6pI3SRV4v/hJsB84B+x9Z9vR8hWrMtAg22ZLt8pBGMaNcOFnb/4+b2hzzvoyfZgms= X-Yahoo-Newman-Id: 286214.51215.bm@smtp220.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: YU3sLtEVM1kpwXAajwhKsG1pD0oaC6C9wKXyMSczF5ZGUJ8 nKhV6xQSER5tzds.vOLT7n_XuhYKbK9vAldHtnLa3fSEqL_UU29HUv4qYOSa iZu__ZH710h_OtyEFv6mzsGm_PR5i3n8qqicGq5mjI9QWcQXsvRmEJ40rq7I YywnLwFy34QMQJe5hSyiuQuW5XA8cTrBL5S7vABFy97o6mrVek855hTvtqVm 3Q8kCyFqUKJjoRliKXkufZ1wArK7hOPFBifmBmFAWOWKLndvA9zunQqNG7p6 GNaW0PKw7RnUFQN_w5vlK7SlnQ7Ax9Ul87MrQFalwTWL.mKTNpWumkb5xpgG PsgrTF3tPucelVd2rBWVXjj.kIR_e4yCOWO3XoEJYZIinMVg.Dp1wrRM.nyp AX7kZ7fi1PE7lZHlmXqO1MBGj3Kb7.YJvSPBSp9ADefW5vyUV4rucsgrXib6 3DBiP9D4dmzz6MLBM7.MZ1bVRExcgvg0kCSgECxVh82Z1BAmwQdcmeNJoCzb ya_d_G2c5kNqLN3p4tkPUEXOjuwyOIbwmexNt6EOyUo0rc13G.nR9fTEltJA bFA4- X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- X-Rocket-Received: from [192.168.254.211] (scott4long@168.103.85.57 with plain [98.138.105.21]) by smtp220.mail.ne1.yahoo.com with SMTP; 14 Dec 2013 13:58:40 -0800 PST Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: buf_ring in HEAD is racy From: Scott Long In-Reply-To: Date: Sat, 14 Dec 2013 14:58:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2002669A-DDE0-470A-A558-F812EA5D59F0@yahoo.com> References: To: Ryan Stone X-Mailer: Apple Mail (2.1822) Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Dec 2013 22:01:53 -0000 We see regular buf_ring drops at Netflix as well, but had always assumed = that it was because we were overfilling the ring. I=92ll take a closer = look now. Scott On Dec 13, 2013, at 10:04 PM, Ryan Stone wrote: > I am seeing spurious output packet drops that appear to be due to > insufficient memory barriers in buf_ring. I believe that this is the > scenario that I am seeing: >=20 > 1) The buf_ring is empty, br_prod_head =3D br_cons_head =3D 0 > 2) Thread 1 attempts to enqueue an mbuf on the buf_ring. It fetches > br_prod_head (0) into a local variable called prod_head > 3) Thread 2 enqueues an mbuf on the buf_ring. The sequence of events > is essentially: >=20 > Thread 2 claims an index in the ring and atomically sets br_prod_head = (say to 1) > Thread 2 sets br_ring[1] =3D mbuf; > Thread 2 does a full memory barrier > Thread 2 updates br_prod_tail to 1 >=20 > 4) Thread 2 dequeues the packet from the buf_ring using the > single-consumer interface. The sequence of events is essentialy: >=20 > Thread 2 checks whether queue is empty (br_cons_head =3D=3D = br_prod_tail), > this is false > Thread 2 sets br_cons_head to 1 > Thread 2 grabs the mbuf from br_ring[1] > Thread 2 sets br_cons_tail to 1 >=20 > 5) Thread 1, which is still attempting to enqueue an mbuf on the ring. > fetches br_cons_tail (1) into a local variable called cons_tail. It > sees cons_tail =3D=3D 1 but prod_head =3D=3D 0 and concludes that the = ring is > full and drops the packet (incrementing br_drops unatomically, I might > add) >=20 >=20 > I can reproduce several drops per minute by configuring the ixgbe > driver to use only 1 queue and then sending traffic from concurrent 8 > iperf processes. (You will need this hacky patch to even see the > drops with netstat, though: > http://people.freebsd.org/~rstone/patches/ixgbe_br_drops.diff) >=20 > I am investigating fixing buf_ring by using acquire/release semantics > rather than load/store barriers. However, I note that this will > apparently be the second attempt to fix buf_ring, and I'm seriously > questioning whether this is worth the effort compared to the > simplicity of using a mutex. I'm not even convinced that a correct > lockless implementation will even be a performance win, given the > number of memory barriers that will apparently be necessary. > _______________________________________________ > 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"