From owner-freebsd-net@FreeBSD.ORG Sun Sep 14 06:10:17 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06EA5B35; Sun, 14 Sep 2014 06:10:17 +0000 (UTC) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA7F5B3D; Sun, 14 Sep 2014 06:10:16 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id f12so2599566qad.14 for ; Sat, 13 Sep 2014 23:10:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ABZD4he02bJ/6yREz5ohVS3Wh2zuJ4ie6OJ4GcwUMN8=; b=HAbvjQahITiKR8ffsv4TKRDzWmed+nIVtIvRv2FeF9Xugy9Lic6lFD0EwQXxTqPNuQ aDg8sQ90qZhVH/T3FYLnxlj6affnIgF0+EDPyZeqtyzDGME5LjcNkmQCzSDLTw8FFbQq NOg3jzta4nXC4OBDd7sVA5tYDj0aaZp2Ynlm8viMKBpDTMewxyDOvuX62/3nlciAG/mp Po/m3oJ2J08qJDgtKJLjaFao+Mj6mKrA/JFux8OQF4qfijwF3y68ewJGTF8KIU3DFdzS RGm1bwQR3sHlO4b3SdLDR6mS7gm10lqvL+PfUPueOKHaP7xuSKdCToPYSF9ZO/o0qsN7 GwtA== MIME-Version: 1.0 X-Received: by 10.140.82.71 with SMTP id g65mr26590147qgd.75.1410675015824; Sat, 13 Sep 2014 23:10:15 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.39.139 with HTTP; Sat, 13 Sep 2014 23:10:15 -0700 (PDT) In-Reply-To: References: Date: Sat, 13 Sep 2014 23:10:15 -0700 X-Google-Sender-Auth: UzRmF5Jhk_yJKOAiLpiPYaCd8eo Message-ID: Subject: Re: [igb] add DROP_EN to each RX queue config if TX flow control is disabled From: Adrian Chadd To: Eric Joyner Content-Type: text/plain; charset=UTF-8 Cc: Jack F Vogel , FreeBSD Net , "Joyner, Eric" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 14 Sep 2014 06:10:17 -0000 On 13 September 2014 13:09, Eric Joyner wrote: > This looks good to me. The only comment I have is that according to the I350 > datasheet, DROP_EN is already set on all the queues but 0 by default, but I > haven't checked for the other adapters covered by igb. Right, but the igb_initialize_receive_units() function actually overrides the queue SRRCTL; it doesn't do a read-modify-write of what the initial defaults are. -a From owner-freebsd-net@FreeBSD.ORG Sun Sep 14 15:13:24 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EAF6314 for ; Sun, 14 Sep 2014 15:13:24 +0000 (UTC) Received: from m15-114.126.com (m15-114.126.com [220.181.15.114]) by mx1.freebsd.org (Postfix) with ESMTP id 402A9125 for ; Sun, 14 Sep 2014 15:13:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com; s=s110527; h=From:Subject:Date:Message-ID:MIME-Version; bh=7w2/i c5j0FRLrBJ+oXV75afyzhO81N5AtlCFEXagd8A=; b=Ri4YgXK5Dfg4bVvetOS9k LdxczzKFUFawvlQ4RrRT5YE1uvhgpDBgxcFCouoEbeQIvh8jX8QMX7cKAq8apQpv hqr6116+qXTI3NWFQpc8P5NwKP9RRX7Yzb30PL0LsMVpuUnlg2CfZLhdOLzr4AAb xuNyUcJr69luZ7HC+StmKw= Received: from dshPC (unknown [219.237.227.113]) by smtp7 (Coremail) with SMTP id DsmowEAZrGNjqRVUFU0sBw--.13786S2; Sun, 14 Sep 2014 22:42:45 +0800 (CST) From: "dongshan" To: Subject: netmap BUG found on big endian machine Date: Sun, 14 Sep 2014 22:42:43 +0800 Message-ID: <001e01cfd02a$255cb430$70161c90$@126.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac/QKCuwLScJOIFfS+OmrWeJcWdYQg== Content-Language: zh-cn X-CM-TRANSID: DsmowEAZrGNjqRVUFU0sBw--.13786S2 X-Coremail-Antispam: 1Uf129KBjvdXoW7GF1rur47KF1Uuw4xKw43GFg_yoW3GFg_WF ykArW8ury3Cwn7W3929rWFq3WDKry0qw1rCrW5Xr4jk34UGa4kuFZayr9Igw48Za15Kr15 Gwn8Wa1Fvr1fujkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUvcSsGvfC2KfnxnUUI43ZEXa7IU1i0etUUUUU== X-Originating-IP: [219.237.227.113] X-CM-SenderInfo: 5wkrztxv1d0warsqlqqrswhudrp/1tbi1gYHxU0vOJamDwAAs3 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 14 Sep 2014 15:13:25 -0000 Hi,=20 =20 I have tested netmap on freescale PowerPC board, it is a big = endian machine, when I test the example app pkt-gen=A3=AC I found one bug, = really it is bug of netmap souce code. The commit id is = =A1=B0d39c4411a2129926d262f9faffacaf876392c7cd=A1=B1, the bug locates in =A1=B0netmap_mem2.c, netmap_mem_rings_create()=A1=B1, you = should use=20 =A1=B0*(uint32_t *)(uintptr_t)&ring->nr_buf_size =3D NETMAP_BDG_BUF_SIZE(na->nm_mem);=A1=B1 substituting =A1=B0*(uint16_t *)(uintptr_t)&ring->nr_buf_size =3D NETMAP_BDG_BUF_SIZE(na->nm_mem);=A1=B1 Because the outcome of big endian and little endian is different. = I guess the source code is written and tested on intel arch machine. But = it is true it can=A1=AFt run big endian machine directly. =20 =20 Best regards, Dongshan =20 From owner-freebsd-net@FreeBSD.ORG Sun Sep 14 16:30:06 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D81364F; Sun, 14 Sep 2014 16:30:06 +0000 (UTC) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 1033C9A7; Sun, 14 Sep 2014 16:30:05 +0000 (UTC) Received: from Toshi.lariat.net (IDENT:ppp1000.lariat.net@localhost [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id KAA29705; Sun, 14 Sep 2014 10:29:58 -0600 (MDT) Message-Id: <201409141629.KAA29705@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 13 Sep 2014 19:13:44 -0600 To: questions@freebsd.org, net@freebsd.org From: Brett Glass Subject: jme interface bounces up and down, up and down.... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 14 Sep 2014 16:30:06 -0000 Everyone: I just installed FreeBSD 10.0-RELEASE on an Asus EeeBox B202 (which comes with Linux). This particular version of the product comes with a JMicron gigabit Ethernet adapter that uses the jme(4) driver. Because it only has one port and I need several, I've set it up with multiple VLANs, which are trunked out to a little Netgear VLAN switch. Unfortunately, the interface is bouncing up and down every few minutes: Sep 13 12:44:44 testbed kernel: jme0: link state changed to UP Sep 13 12:44:44 testbed kernel: jme0_1: link state changed to UP Sep 13 12:44:44 testbed kernel: jme0_2: link state changed to UP Sep 13 12:44:44 testbed kernel: jme0_3: link state changed to UP Sep 13 12:50:04 testbed kernel: jme0: link state changed to DOWN Sep 13 12:50:04 testbed kernel: jme0_1: link state changed to DOWN Sep 13 12:50:04 testbed kernel: jme0_2: link state changed to DOWN Sep 13 12:50:04 testbed kernel: jme0_3: link state changed to DOWN Sep 13 12:50:43 testbed kernel: jme0: link state changed to UP ... The problem didn't seem to occur with the bundled Linux distro. Has anyone else seen this problem? Know of a fix? --Brett Glass From owner-freebsd-net@FreeBSD.ORG Sun Sep 14 16:42:44 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 793129BB for ; Sun, 14 Sep 2014 16:42:44 +0000 (UTC) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A4A6B29 for ; Sun, 14 Sep 2014 16:42:44 +0000 (UTC) Received: by mail-qa0-f52.google.com with SMTP id m5so2813917qaj.39 for ; Sun, 14 Sep 2014 09:42:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=y0qgT4rfb4s9jL1bFLvm/2uSp2tx8H7CEhwpTixpXHQ=; b=pLYp3ceTa/9uSmuiiST7G92QQ6AwM/NFhjs9RYihZDJKQ7WSI9zvd8bnGi18bnzYne Ly3fYsVbklqP39jPeWwYy8kD+U8NyOQRzuGZFmE8bvAlAiJTN2BzatA0TJ/ySMfIFE6d GgC/VT+tJ6zh0EQZK0MQ3kG9IrgUlHgozJtu8+wojzoCkuapXI73OnIBNCHDNOi9y1p0 2vTF26cwwnZ573ENn+QNUDgzdFJJW15RhD8JQ6se9WCOEeTKWgKQygwXutulnifXBfBn NTUGnZHr1eficyq+rZyfQ0KEDG2dVPGN9Gb7XLKTCi6/1EpxF/94OO4oSHjW3y8tXW26 ZupQ== MIME-Version: 1.0 X-Received: by 10.224.75.73 with SMTP id x9mr29994719qaj.63.1410712962800; Sun, 14 Sep 2014 09:42:42 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.39.139 with HTTP; Sun, 14 Sep 2014 09:42:42 -0700 (PDT) In-Reply-To: <001e01cfd02a$255cb430$70161c90$@126.com> References: <001e01cfd02a$255cb430$70161c90$@126.com> Date: Sun, 14 Sep 2014 09:42:42 -0700 X-Google-Sender-Auth: YL_Ttmv83xYRoeJsg0NphllX9MU Message-ID: Subject: Re: netmap BUG found on big endian machine From: Adrian Chadd To: dongshan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 14 Sep 2014 16:42:44 -0000 Hi! Good catch! Would you mind filing a bug so we don't forget? http://bugs.freebsd.org/submit/ Thanks! -a On 14 September 2014 07:42, dongshan wrote: > Hi, > > > > I have tested netmap on freescale PowerPC board, it is a big endia= n > machine, when I test the example app pkt-gen=EF=BC=8C I found one bug, re= ally it is > bug of netmap souce code. > > The commit id is =E2=80=9Cd39c4411a2129926d262f9faffacaf876392c7cd= =E2=80=9D, the > bug locates in =E2=80=9Cnetmap_mem2.c, netmap_mem_rings_create()=E2=80=9D= , you should use > > =E2=80=9C*(uint32_t *)(uintptr_t)&ring->nr_buf_size =3D > NETMAP_BDG_BUF_SIZE(na->nm_mem);=E2=80=9D substituting > > =E2=80=9C*(uint16_t *)(uintptr_t)&ring->nr_buf_size =3D > NETMAP_BDG_BUF_SIZE(na->nm_mem);=E2=80=9D > > Because the outcome of big endian and little endian is different. = I > guess the source code is written and tested on intel arch machine. But it= is > true it can=E2=80=99t run big endian machine directly. > > > > > > Best regards, > > Dongshan > > > > _______________________________________________ > 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 Sep 14 20:02:40 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B7F4B67 for ; Sun, 14 Sep 2014 20:02:40 +0000 (UTC) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 81FC0FDA for ; Sun, 14 Sep 2014 20:02:39 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id tr6so3592315ieb.27 for ; Sun, 14 Sep 2014 13:02:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=chFDo26fs1SZyvXLcLf3d2SJuzpqJJ1+BqQiBEvSP1U=; b=XoIE1sC8SpXThbk3nfk2fbhi2ewAQdiInt4B4Iw6d+DejiuWUvITdvuJ8g3ZSvtBuG t4ZxKbACUPJRpriT+einaGKCmVqsElqIMzc0Xm/4OMMR1KFA8bOcMDpV3+RoWmytQMfQ GSxvut9B4ZHzv26ofx+Swc4uT0VbYM0Sn8cRdVSXMJVk082jMJj7gjooAgpROhHRleTp l0awu8metB0lBjnNicrn+c0BH93yyMoOxyuK1CMFfgx0N4pZsDOKI0eYfiwAahmrWf0/ fwyY2DM4TWxHJqvC/WY63oTXSHuPUG4gag0JS48YUaQJjeEYU6OATO0AQ2PSgpnFZiwU 4RpQ== X-Gm-Message-State: ALoCoQkVK/YX3oel1VijmeiPQBUpg9xB/7CDcXOtjiqPkf+vb25absz+/yYwhsQ7XMAcfLM9+feo X-Received: by 10.50.62.50 with SMTP id v18mr6359537igr.21.1410724540503; Sun, 14 Sep 2014 12:55:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.29.20 with HTTP; Sun, 14 Sep 2014 12:55:20 -0700 (PDT) X-Originating-IP: [72.177.8.109] In-Reply-To: References: From: Bryan Venteicher Date: Sun, 14 Sep 2014 14:55:20 -0500 Message-ID: Subject: Re: Performance problem with slow link behind fast gateway To: mailinglists@debank.tv Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 14 Sep 2014 20:02:40 -0000 Hi, On Tue, Sep 9, 2014 at 4:42 PM, wrote: > All, > > I'm seeing some performance problems with a slowish VPN connection behind > a fast gateway, the setup looks like this: > > |----------------------------------| > |-----------------------------| > |client (zandbak) (DSL connection)| ---- 'VPN tunnel' ----- |Gateway > (vps) using NAT on 1G|------ 'Internet' > |----------------------------------| > |-----------------------------| > > > Transfers from the gateway to the client are reasonably fast (easily > within usable range for me): > root@zandbak:/usr/home/rob # scp rob@gateway:test_file ./ > test_file > 100% 10MB 445.2KB/s 00:23 > > > Transfers from the internet to the gateway are fast: > root@vps:/usr/home/rob # fetch -4 "http://149.20.53.23/pub/ > FreeBSD/releases/amd64/amd64/ISO-IMAGES/10.0/FreeBSD-10.0- > RELEASE-amd64-bootonly.iso" > FreeBSD-10.0-RELEASE-amd64-bootonly.iso 100% of 209 MB 10 MBps > 00m20s > > > But transfers from the client to the internet through the tunnel are > showing a very degraded connection speed, the speed jumps up and down but > averages at around 20kBps: > root@zandbak:/usr/home/rob # fetch "http://149.20.53.23/pub/ > FreeBSD/ISO-IMAGES-amd64/10.0/FreeBSD-10.0-RELEASE-amd64-bootonly.iso" > FreeBSD-10.0-RELEASE-amd64-bootonly.iso 0% of 209 MB 8275 Bps > 07h27m > > > I've tried to eliminate some variables: > -VPN: tinc as a L2 VPN and openVPN as a L3 VPN, results are the same > -NAT: pf and ipfw, results are the same > > I suspect that there's a problem with the fast link receiving too much > data and once the buffers are full dropping packets although I'm not sure > if this is actually the problem. > My question is: how can I debug this issue? > > > =E2=80=8BOn the vtnet0 interface in your KVM VM=E2=80=8B, disable checksum = offloading. What KVM/QEMU VirtIO provides as the "checksum" in situation likes this does not work well with what FreeBSD expects. Fixing this has been on my todo list for awhile, but it is a moderate amount of work to fix this, and touches many places in the stack. I have plans to do mbuf related work later this year, and was planning to finally fix this issue as well. > > Below some system information, I can supply more info if needed > > Thanks! > Rob Evers > > > > System info: > Gateway: This is a VPS on KVM > > root@vps:/usr/home/rob # uname -a > FreeBSD vps.debank.tv 10.0-STABLE FreeBSD 10.0-STABLE #5 r268727M: Wed > Jul 16 13:17:24 NZST 2014 root@vps.debank.tv:/usr/obj/usr/src/sys/GEN= ERIC > amd64 > > root@vps:/usr/home/rob # ifconfig vtnet0 > vtnet0: flags=3D8843 metric 0 mtu > 1500 > options=3D6c00ab HWCSUM,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6> > ether 00:16:3c:55:17:b9 > inet 192.227.xxx.xxx netmask 0xffffff00 broadcast 192.227.xxx.xxx > inet6 fe80::216:3cff:fe55:17b9%vtnet0 prefixlen 64 scopeid 0x1 > nd6 options=3D21 > media: Ethernet 10Gbase-T > status: active > > > root@vps:/usr/home/rob # ifconfig tap0 > tap0: flags=3D8843 metric 0 mtu 1= 500 > options=3D80000 > ether 00:bd:61:01:00:00 > inet6 fd7c:3e16:580b:4ccf::50 prefixlen 64 > inet6 fe80::2bd:61ff:fe01:0%tap0 prefixlen 64 scopeid 0x4 > inet 172.16.143.50 netmask 0xffffff00 broadcast 172.16.143.255 > nd6 options=3D61 > media: Ethernet autoselect > status: active > Opened by PID 61485 > > > Client: This is a VM on bhyve > > root@zandbak:/usr/home/rob # uname -a > FreeBSD zandbak 10.0-RELEASE-p7 FreeBSD 10.0-RELEASE-p7 #0: Tue Jul 8 > 06:37:44 UTC 2014 root@amd64-builder.daemonology.net:/usr/obj/usr/src= /sys/GENERIC > amd64 > > root@zandbak:/usr/home/rob # ifconfig vtnet0 > vtnet0: flags=3D8943 metr= ic > 0 mtu 1500 > options=3D80028 > ether 52:54:00:13:fd:78 > inet 192.168.1.129 netmask 0xffffff00 broadcast 192.168.1.255 > inet6 fe80::5054:ff:fe13:fd78%vtnet0 prefixlen 64 scopeid 0x1 > nd6 options=3D29 > media: Ethernet 10Gbase-T > status: active > > root@zandbak:/usr/home/rob # ifconfig tap0 > tap0: flags=3D8843 metric 0 mtu 1= 500 > options=3D80000 > ether 00:bd:3d:94:05:00 > inet 172.16.143.55 netmask 0xffffff00 broadcast 172.16.143.255 > nd6 options=3D29 > media: Ethernet autoselect > status: active > Opened by PID 1411 > > > > _______________________________________________ > 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 Sep 14 20:51:34 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D82A85F for ; Sun, 14 Sep 2014 20:51:34 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [67.212.89.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D6E4F6A6 for ; Sun, 14 Sep 2014 20:51:33 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) by mail.bsdinfo.com.br (Postfix) with ESMTP id 61E17139CC for ; Sun, 14 Sep 2014 17:51:30 -0300 (BRT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsdinfo.com.br; h=content-transfer-encoding:content-type:content-type :in-reply-to:references:subject:subject:to:mime-version :user-agent:from:from:date:date:message-id; s=dkim; t= 1410727889; x=1411591890; bh=Q+B+9JWqbJEj3oIcP229bEHWsJfSw3gVZ3u XSR6M5X0=; b=YIAqa1BwaEKD0AFeQecykMomOZnuVdndRcEO0qdonlsRW1S5CzV 04o+FxkoPKpfpP1ciZR0rtEW69XyUFxk/hzvSXR3I4hJSN7pvkhsJULJGnE3N2aL Qps3vgJY3VmXJ5Z6mPIlgk3DT213xPmrQnSji+njVv35w9bqsnWJ1Tvo= X-Virus-Scanned: amavisd-new at mail.bsdinfo.com.br Received: from mail.bsdinfo.com.br ([127.0.0.1]) by mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbSFykV1LzxW for ; Sun, 14 Sep 2014 17:51:29 -0300 (BRT) Received: from [192.168.8.105] (unknown [186.193.61.3]) by mail.bsdinfo.com.br (Postfix) with ESMTPSA id A9CB8139C9; Sun, 14 Sep 2014 17:51:26 -0300 (BRT) Message-ID: <5415FFC9.2000307@bsdinfo.com.br> Date: Sun, 14 Sep 2014 17:51:21 -0300 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: ixgbe CRITICAL: ECC ERROR!! Please Reboot!! References: <5408F23C.2030309@bsdinfo.com.br> <54091607.9010100@bsdinfo.com.br> <5409CA44.8070203@bsdinfo.com.br> <540A1A3E.2040306@bsdinfo.com.br> <540A8200.5010404@bsdinfo.com.br> <540DFAE3.8070001@bsdinfo.com.br> <002001cfcba0$4812c7f0$d83857d0$@videon-znojmo.cz> <540E547C.9030703@bsdinfo.com.br> <54105EB1.4050607@bsdinfo.com.br> In-Reply-To: <54105EB1.4050607@bsdinfo.com.br> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Jack F Vogel , FreeBSD Net , Eric Joyner , =?windows-1252?Q?=22Ing=2E_Ale=9A_Nechv=E1tal=22?= X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 14 Sep 2014 20:51:34 -0000 On 10/09/2014 11:22, Marcelo Gondim wrote: > On 09/09/2014 01:06, Adrian Chadd wrote: >> Hi, >> >> A bunch of us spent a whole bunch of time on the driver before and >> after 10.0-REL happened to squish a number of ixgbe hanging and out of >> order bugs. >> >> Please update. :) >> >> >> -a >> > > Dear > > Yesterday performed the following tasks: > > - I removed the front door of the rack in the datacenter. > - I increased by 100% the speed of the fans. > - I removed the dust filter that was in front of the server, letting > air circulate more easily. > > I'll wait a few days to see if the crashes will stop. > > Thanks to everyone and if the problem happens again, I'll let you > know. :) > > Cheers, Dear, It happened again the locking interface. :( Even making the above improvements, the problem to happen again. Could be a mismatch between the X520-SR2 interface and Datacom switch that uses XFP module? We exchanged the SFP+ 850nmmodule for 1310nmand yet the problem continued. Very strange! When traffic passing through ix0 is greater than 2.2Gbps, after a certain time the interface stops sending and receiving packets. Simply just do a ifconfig down and ifconfig upto return to work. With less traffic, the interface does not latch. Is there any command I can run to give more technical details for you? # uname -a FreeBSD rt01.xxxxxxxx.br 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #14 r271309: Tue Sep 9 09:50:36 BRT 2014 root@rt01.xxxxxxxxx.br:/usr/obj/usr/src/sys/GONDIM amd64 Cheers, From owner-freebsd-net@FreeBSD.ORG Mon Sep 15 06:08:31 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2601CEB0; Mon, 15 Sep 2014 06:08:31 +0000 (UTC) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EA788E18; Mon, 15 Sep 2014 06:08:30 +0000 (UTC) Received: by mail-pd0-f173.google.com with SMTP id ft15so5460449pdb.32 for ; Sun, 14 Sep 2014 23:08:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=ifUKvEKArAla8oEsnZJ0bQmsTVb7q2PX/VcO1BpN0bM=; b=An0QuMvov3RLrQ7EsLFBFAxSNzloDITpqlAFQFNXAnkDnzlhuyaOAEWGeLDPct2RsE 2s4jJ0C0j4cuGXA1S1wN36gH9UIX+reGABVuNldioUcdovYKWAA1/FUusM/wO4gYLuBo u19atWN5Hf4qKrjN2uTEowosicVyKZBYM9HQZE2Ae5IXIYOUJydN8kaFddBT61Mtwf8X XGKJ4+x9CHvFB1ddmvDsYNNufLVrAL4pKJ6kRv72UcyryusFqB687nnGFQ36n2TZPtpN wqM2FqhlbqklPAY2IToOoqP6CbKzS3kjRrJQfxOyAtlgZF2yFwp8Qu/AWEegiOnGoMJU yFVA== X-Received: by 10.66.141.197 with SMTP id rq5mr2218516pab.124.1410761310549; Sun, 14 Sep 2014 23:08:30 -0700 (PDT) Received: from pyunyh@gmail.com ([106.247.248.2]) by mx.google.com with ESMTPSA id qy10sm10285421pbb.47.2014.09.14.23.08.26 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 14 Sep 2014 23:08:29 -0700 (PDT) From: Yonghyeon PYUN X-Google-Original-From: "Yonghyeon PYUN" Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 15 Sep 2014 15:08:19 +0900 Date: Mon, 15 Sep 2014 15:08:19 +0900 To: Brett Glass Subject: Re: jme interface bounces up and down, up and down.... Message-ID: <20140915060819.GA967@michelle.fasterthan.com> Reply-To: pyunyh@gmail.com References: <201409141629.KAA29705@mail.lariat.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201409141629.KAA29705@mail.lariat.net> User-Agent: Mutt/1.4.2.3i Cc: questions@freebsd.org, net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Sep 2014 06:08:31 -0000 On Sat, Sep 13, 2014 at 07:13:44PM -0600, Brett Glass wrote: > Everyone: > > I just installed FreeBSD 10.0-RELEASE on an Asus EeeBox B202 (which > comes with Linux). This particular version of the product comes > with a JMicron gigabit Ethernet adapter that uses the jme(4) > driver. Because it only has one port and I need several, I've set > it up with multiple VLANs, which are trunked out to a little > Netgear VLAN switch. > > Unfortunately, the interface is bouncing up and down every few minutes: > > Sep 13 12:44:44 testbed kernel: jme0: link state changed to UP > Sep 13 12:44:44 testbed kernel: jme0_1: link state changed to > UP > Sep 13 12:44:44 testbed kernel: jme0_2: link state changed to > UP > Sep 13 12:44:44 testbed kernel: jme0_3: link state changed to > UP > Sep 13 12:50:04 testbed kernel: jme0: link state changed to > DOWN > Sep 13 12:50:04 testbed kernel: jme0_1: link state > changed to DOWN > Sep 13 12:50:04 testbed kernel: jme0_2: link state > changed to DOWN > Sep 13 12:50:04 testbed kernel: jme0_3: link state > changed to DOWN > Sep 13 12:50:43 testbed kernel: jme0: link state changed to UP > ... > > The problem didn't seem to occur with the bundled Linux distro. Has > anyone else seen this problem? Know of a fix? > Would you show me the output of dmesg(jme(4) and jmphy(4) only) to know exact chip revision? From owner-freebsd-net@FreeBSD.ORG Mon Sep 15 07:50:31 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C869BD6 for ; Mon, 15 Sep 2014 07:50:31 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D9D75A99 for ; Mon, 15 Sep 2014 07:50:30 +0000 (UTC) Received: from mandree.no-ip.org ([78.48.23.37]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MLunc-1XQ77p3Ydw-007myM for ; Mon, 15 Sep 2014 09:50:21 +0200 Received: from [IPv6:::1] (localhost6.localdomain6 [IPv6:::1]) by apollo.emma.line.org (Postfix) with ESMTP id 0A18A23CF97 for ; Mon, 15 Sep 2014 09:50:21 +0200 (CEST) Message-ID: <54169A3C.2090402@gmx.de> Date: Mon, 15 Sep 2014 09:50:20 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: netmap BUG found on big endian machine References: <001e01cfd02a$255cb430$70161c90$@126.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:xXOYTeAwqQug4XXGn0zeCE2/491TihUu/HB22s7EhC+k9fLoKfY xUpTtIVEMHaGieEPuhQWyI8CBWnGn/Ks9sudNA3yjHg57LJSEUEQj9+AzvNyXaQtpPiTNRi ZiV1ISsK3+CGaIJGpp/pJGtbfORE9keuXAiwmHd+YhVD621TLsCjpBqlxmlynFv4EOFAinQ KMvmD5NiqknmCW0cO7NbA== X-UI-Out-Filterresults: notjunk:1; X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Sep 2014 07:50:31 -0000 Am 14.09.2014 um 18:42 schrieb Adrian Chadd: > Hi! > > Good catch! > > Would you mind filing a bug so we don't forget? > > http://bugs.freebsd.org/submit/ The proposed fix, while it might fix the immediate issue, might still not fix pointer aliasing. Perhaps there needs to be some struct or union defined and used to avoid the aliasing. From owner-freebsd-net@FreeBSD.ORG Mon Sep 15 08:00:12 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 687DAE4F for ; Mon, 15 Sep 2014 08:00:12 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3D4C4AFB for ; Mon, 15 Sep 2014 08:00:12 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s8F80COF091748 for ; Mon, 15 Sep 2014 08:00:12 GMT (envelope-from bugzilla-noreply@freebsd.org) Message-Id: <201409150800.s8F80COF091748@kenobi.freebsd.org> From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [FreeBSD Bugzilla] Commit Needs MFC MIME-Version: 1.0 X-Bugzilla-Type: whine X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated Date: Mon, 15 Sep 2014 08:00:12 +0000 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Sep 2014 08:00:12 -0000 Hi, You have a bug in the "Needs MFC" state which has not been touched in 7 or more days. This email serves as a reminder that you may want to MFC this bug or marked it as completed. In the event you have a longer MFC timeout you may update this bug with a comment and I won't remind you again for 7 days. This reminder is only sent on Mondays. Please file a bug about concerns you may have. This search was scheduled by eadler@FreeBSD.org. (1 bugs) Bug 183659: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183659 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-net@FreeBSD.org Status: Needs MFC Resolution: Summary: [tcp] TCP stack lock contention with short-lived connections From owner-freebsd-net@FreeBSD.ORG Mon Sep 15 14:44:39 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05615104 for ; Mon, 15 Sep 2014 14:44:39 +0000 (UTC) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B97FFC11 for ; Mon, 15 Sep 2014 14:44:38 +0000 (UTC) Received: by mail-vc0-f177.google.com with SMTP id la4so3508712vcb.36 for ; Mon, 15 Sep 2014 07:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=xHRHj2DVlv5keevHEKY6NC/9519YXFHuGd650RrMFYA=; b=joLagbM75zP/Vgo/s0GalpuuV8oNsAFWPAtjxhM8baTMKhOlCaXvZ7BZ07ub+H+fZH KBsY+drgum78i/fMjX2ECq0ACbCqmr/LFDXyjJRaFF04Fo+lt5IbpArydzfO5tZ008hn AziHfiBRc9tnSzMvgI7U7jD8XZ2YnY9VJRpoYpbpzZZ/vB5rdePqkXSQrQUzJRgo4q7t Eo+ZevuFP/vfL2nFatKK83OQtrJiGUmiiwAQj7BTkAzK0Zu2lTA6QL8M6Zj84uLLB50W JZox8Z8buyXaaJATubl7DmK69v0zPtyE8PHLj6t2FPZkfSFIF8S64CRpQzTrdLRUfOjL fnmA== MIME-Version: 1.0 X-Received: by 10.52.33.231 with SMTP id u7mr19909972vdi.54.1410792277802; Mon, 15 Sep 2014 07:44:37 -0700 (PDT) Received: by 10.220.222.208 with HTTP; Mon, 15 Sep 2014 07:44:37 -0700 (PDT) Date: Mon, 15 Sep 2014 22:44:37 +0800 Message-ID: Subject: Is this a netmap bug? From: To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Sep 2014 14:44:39 -0000 Hi, I wrote a very simple netmap program on FreeBSD 10, run one or more times, kernel crashed. Kernel configuration is GENERIC, only added netmap. The host is VM, running in vmplayer, one nic. How to repeat: 1. log into the system via ssh 2. run one or more times the program in the terminal. Is it a bug? core.txt.0 ---------------------------------------------------------------------------------- bsd10 dumped core - see /var/crash/vmcore.0 Sun Sep 14 05:37:38 CST 2014 FreeBSD bsd10 10.0-RELEASE FreeBSD 10.0-RELEASE #0: Thu Sep 11 02:30:51 CST 2014 root@bsd10:/usr/obj/usr/src/sys/GENERIC amd64 panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x30 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80615062 stack pointer = 0x28:0xfffffe00002a5470 frame pointer = 0x28:0xfffffe00002a5520 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2238 (sshd) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0xffffffff808f5870 at kdb_backtrace+0x60 #1 0xffffffff808bd355 at panic+0x155 #2 0xffffffff80c9c132 at trap_fatal+0x3a2 #3 0xffffffff80c9c409 at trap_pfault+0x2c9 #4 0xffffffff80c9bb96 at trap+0x5e6 #5 0xffffffff80c82e32 at calltrap+0x8 #6 0xffffffff80979cce at ether_output+0x59e #7 0xffffffff809e48d4 at ip_output+0xf14 #8 0xffffffff80a4db74 at tcp_output+0x1684 #9 0xffffffff80a58f31 at tcp_usr_send+0x3c1 #10 0xffffffff8092e135 at sosend_generic+0x465 #11 0xffffffff809135d9 at soo_write+0x49 #12 0xffffffff8090b35a at dofilewrite+0x8a #13 0xffffffff8090b085 at kern_writev+0x65 #14 0xffffffff8090b013 at sys_write+0x63 #15 0xffffffff80c9ca27 at amd64_syscall+0x357 #16 0xffffffff80c8311b at Xfast_syscall+0xfb Uptime: 9h6m25s Dumping 586 out of 2025 MB:..3%..11%..22%..31%..41%..52%..61%..71%..82%..91% Reading symbols from /boot/kernel/uhid.ko.symbols...done. Loaded symbols for /boot/kernel/uhid.ko.symbols #0 doadump (textdump=) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=) at pcpu.h:219 #1 0xffffffff808bcfd0 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0xffffffff808bd394 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:754 #3 0xffffffff80c9c132 in trap_fatal (frame=, eva=) at /usr/src/sys/amd64/amd64/trap.c:882 #4 0xffffffff80c9c409 in trap_pfault (frame=0xfffffe00002a53c0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:699 #5 0xffffffff80c9bb96 in trap (frame=0xfffffe00002a53c0) at /usr/src/sys/amd64/amd64/trap.c:463 #6 0xffffffff80c82e32 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #7 0xffffffff80615062 in netmap_start (ifp=0xfffff800027d8800, m=0xfffff80037766c00) at /usr/src/sys/dev/netmap/netmap.c:2346 #8 0xffffffff80979cce in ether_output (ifp=0xfffff800027d8800, m=0xfffff80037766c00, dst=0xfffffe00002a5774, ro=) at /usr/src/sys/net/if_ethersubr.c:437 #9 0xffffffff809e48d4 in ip_output (m=0xfffff80037766c00, opt=, flags=, imo=, inp=0xfffff80002f76188) at /usr/src/sys/netinet/ip_output.c:635 #10 0xffffffff80a4db74 in tcp_output (tp=0xfffff80002e68c00) at /usr/src/sys/netinet/tcp_output.c:1231 #11 0xffffffff80a58f31 in tcp_usr_send (so=, flags=0, m=0xfffff80002f73400, nam=, control=, td=) at /usr/src/sys/netinet/tcp_usrreq.c:872 #12 0xffffffff8092e135 in sosend_generic (so=0xfffff80002d20000, addr=0x0, uio=0xfffffe00002a5ab0, top=, control=, flags=, td=) at /usr/src/sys/kern/uipc_socket.c:1271 #13 0xffffffff809135d9 in soo_write (fp=, uio=0xfffffe00002a5ab0, active_cred=, flags=, td=) at /usr/src/sys/kern/sys_socket.c:103 #14 0xffffffff8090b35a in dofilewrite (td=0xfffff80037650490, fd=3, fp=0xfffff80002c2a500, auio=0xfffffe00002a5ab0, offset=, flags=0) at file.h:303 #15 0xffffffff8090b085 in kern_writev (td=0xfffff80037650490, fd=3, auio=0xfffffe00002a5ab0) at /usr/src/sys/kern/sys_generic.c:467 #16 0xffffffff8090b013 in sys_write (td=, uap=) at /usr/src/sys/kern/sys_generic.c:382 #17 0xffffffff80c9ca27 in amd64_syscall (td=0xfffff80037650490, traced=0) at subr_syscall.c:134 #18 0xffffffff80c8311b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 #19 0x000000080320f0ca in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) ------------------------------------------------------------------------------------- program: ------------------------------------------------------------------------------------- mmap_size = nmr.nr_memsize; mmap_addr = mmap(0, mmap_size, PROT_WRITE | PROT_READ, MAP_SHARED, fd_netmap, 0); if (mmap_addr == MAP_FAILED) { printf("Can't map %s ring.\n", txifn); return 1; } nmr.nr_version = NETMAP_API; if (ioctl(fd_netmap, NIOCREGIF, &nmr) == -1) { printf("Can't register %s ring.\n", txifn); } printf("go on ......\n"); /* kernel will not crash if sleep for a while */ //sleep(4); munmap(mmap_addr, mmap_size); close(fd_netmap); ----------------------------------------------------------------------------------------------- Thank you, Paul From owner-freebsd-net@FreeBSD.ORG Mon Sep 15 14:47:17 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C8F5031C; Mon, 15 Sep 2014 14:47:17 +0000 (UTC) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 89D5FC45; Mon, 15 Sep 2014 14:47:17 +0000 (UTC) Received: from Toshi.lariat.net (IDENT:ppp1000.lariat.net@localhost [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id IAA08325; Mon, 15 Sep 2014 08:47:12 -0600 (MDT) Message-Id: <201409151447.IAA08325@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 15 Sep 2014 08:19:37 -0600 To: pyunyh@gmail.com From: Brett Glass Subject: Re: jme interface bounces up and down, up and down.... In-Reply-To: <20140915060819.GA967@michelle.fasterthan.com> References: <201409141629.KAA29705@mail.lariat.net> <20140915060819.GA967@michelle.fasterthan.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: questions@freebsd.org, net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Sep 2014 14:47:17 -0000 At 12:08 AM 9/15/2014, Yonghyeon PYUN wrote: >Would you show me the output of dmesg(jme(4) and jmphy(4) only) to >know exact chip revision? Here you are. jme0: port 0xec80-0xecff,0xe800-0xe8ff mem 0xfbffc000-0xfbfff fff irq 18 at device 0.0 on pci1 jme0: MSIX count : 8 jme0: MSI count : 8 jme0: attempting to allocate 1 MSI-X vectors (8 supported) msi: routing MSI-X IRQ 256 to local APIC 0 vector 52 jme0: using IRQ 256 for MSI-X jme0: Using 1 MSIX messages. jme0: PCI device revision : 0x0250 jme0: Chip revision : 0x11 jme0: ethernet hardware address not found in EEPROM. jme0: PHY is at address 1. jme0: Read request size : 512 bytes. jme0: TLP payload size : 128 bytes. miibus0: on jme0 jmphy0: PHY 1 on miibus0 jmphy0: OUI 0x00d831, model 0x0021, rev. 1 jmphy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX -flow-master, auto, auto-flow jme0: bpf attached jme0: Ethernet address: e0:cb:4e:54:23:ac I do not particularly like JMicron chips (their faulty SSD controllers have cost me a lot of time and money), but that's what's on the motherboard of this Asus. So, I need to find a way to make it work. --Brett Glass From owner-freebsd-net@FreeBSD.ORG Mon Sep 15 15:24:09 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4AC8919F; Mon, 15 Sep 2014 15:24:09 +0000 (UTC) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E59B9130; Mon, 15 Sep 2014 15:24:08 +0000 (UTC) Received: by mail-ob0-f170.google.com with SMTP id uy5so2637173obc.1 for ; Mon, 15 Sep 2014 08:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=DlP/13RcYpJk/DQBdbT1nCy2gJKMlkvLy6ah2dvurPw=; b=Nk5b6bmCQ/AiQEgULn0iUcb1viUD4CsCHH93QtUk6sVsDkwhbVtUOSoynP9iYl6ctV 4frSfRgNeveeC7IK//me5jMQfUR6DdDohx9oOoqKlwhGB0Rf3r+97uZ5Mp97uAMNqx/I Ss97SqhKczlfqJv7JyXltRwjOIVJVqfEo5kqRRZHRQxwSflwPk70c/gLRbJaesjWIFe0 RVF9dIx8Rmas0wdQtudszcqI9LVAHAJzSBKfBKFSz1IZn9TUQDCPOdDddda38fgE8T9/ soysDR88/zgZG0rH1/ZQ7tOvKg7wKasBOj/aaQZJjQ5M9XtPeoWemmB+1vH/PR9GsFbZ PPSQ== MIME-Version: 1.0 X-Received: by 10.60.142.165 with SMTP id rx5mr13405140oeb.5.1410794217271; Mon, 15 Sep 2014 08:16:57 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.202.58.196 with HTTP; Mon, 15 Sep 2014 08:16:57 -0700 (PDT) Date: Mon, 15 Sep 2014 17:16:57 +0200 X-Google-Sender-Auth: BvFx9GV_CZdR-X5uX85LvmnQuTI Message-ID: Subject: U3G QDL firmware loader for GOBI2000/HP_UN2420 MiniPCI/USB 3G/GPS From: CeDeROM To: FreeBSD Questions Mailing List , "freebsd-hackers@freebsd.org" , freebsd-net@freebsd.org, "freebsd-usb@FreeBSD.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Sep 2014 15:24:09 -0000 Hello world! :-) I have changed my machine, there is a built-in GOBI2000 / HP UN2420 3G/GPS module installable as MiniPCI card and visible as USB device. I have added its VID/PID to the usbdevs and u3g.c module, so after recompilation it gets recognised by u3g module and apropriate /dev/cuaU* device shows up.. The problem is that device does not store firmware inside non-volatile memory, so user needs to upload it after power-on. I have the firmware files. I can test modem with success after reboot from Win7 which uploads firmware into device. Still, I need to upload the firmware somehow on my FreeBSD. The upload protocol is QDL and /dev/cuaU0 shows up waiting for command. Which utility can I use to upload firmware with QDL? I have seen one post [1] regarding this problem in the past but the QDL utility was not named explicitly. Any hints welcome! :-) Tomek [1] http://lists.freebsd.org/pipermail/freebsd-usb/2010-October/009384.html -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-net@FreeBSD.ORG Mon Sep 15 15:30:42 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EDD78957 for ; Mon, 15 Sep 2014 15:30:42 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id B44C21F9 for ; Mon, 15 Sep 2014 15:30:42 +0000 (UTC) Received: from [127.0.0.1] (nat.in.devexperts.com [89.113.128.63]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 8512B56405 for ; Mon, 15 Sep 2014 19:30:34 +0400 (MSK) Message-ID: <54170619.4040508@FreeBSD.org> Date: Mon, 15 Sep 2014 19:30:33 +0400 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Juniper Secure Access SSL VPN access from FreeBSD? Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Sep 2014 15:30:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 If I want to connect to my workstation at $work, I'm forced to use Juniper Secure Access SSL VPN + rdesktop. I connect to our office JunOS gateway with browser, and run RDesktop from it. But it requires to use supported OS (Windows / MacOS X / Linux), as tunnel is created via binary browser plugin. Is it possible to emulate this on FreeBSD? rdesktop from ports should work as client, as I access standard Windows system, but I need some way to emulate this VPN tunnel. Is it possible? - -- // Lev Serebryakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUFwYZXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePmmoP/2GEqLn27oErPBDChWS2Ygyv a/3vgs9WpN8FbgoZ4rvhDaWzOYkPiqqz+kMq6Ybul4YdUcsRXptXjOkX6857RnsH WxJiHzdzM6ytJrayAgUrdH81cRCp2/FsyEjAs+tlhoEhKMtxaSTcNXMqLXUd+emP YG666kP3tBa5p+VGbjgvICr5PNDiu6xhwdxmWzmGSFW5dhg98aKDZ4a6lpAth31Y 48mydmEM0NuASYznEiv8w+T0llEWlD5iIEJM1KoHfKRSam7eUVFyNFOnPJaeYJ87 7S6Tsi/1hOBJcpmtOrVNx44piRZd2zauB4togPUSh21chWFUmqGT2Dsp/cpEoW4r Tg0LB9Ao/W9fSZIguWwCkerFUhU8YnnIFICG/3aPD1IofeuwEyrt/DypqUpIqWA/ 1GIbQqURdKxf9nstnIq4BAF9dswnh89r7A1tnCP1bNFkqAaj6kdTFrg2vl6/Tkra yH5VJb1oslzjdqEwJXnc27JO6qgFpC1ehxx2xlUA2cSZnGy8hMjRFbsAz3YG11Zv 3HvObAq9idPPQpuCrk0L+TScZpZL6r2GTPVTV+oBX9xyl9eIik8yaxcrfMyamWqn LewzJldV47F4KfEBnwYa0wBBfDLdggF4C/XFQpcuKyIsZB7E9bpeZJeVJAeMP1oL KK89erDVMfnmploX9HJd =Fy+a -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Mon Sep 15 16:02:56 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 195ED798; Mon, 15 Sep 2014 16:02:56 +0000 (UTC) Received: from mail.in-addr.com (mail.in-addr.com [IPv6:2a01:4f8:191:61e8::2525:2525]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D23EA917; Mon, 15 Sep 2014 16:02:55 +0000 (UTC) Received: from gjp by mail.in-addr.com with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XTYjt-0004PP-GM; Mon, 15 Sep 2014 17:02:53 +0100 Date: Mon, 15 Sep 2014 17:02:53 +0100 From: Gary Palmer To: Lev Serebryakov Subject: Re: Juniper Secure Access SSL VPN access from FreeBSD? Message-ID: <20140915160253.GA51285@in-addr.com> References: <54170619.4040508@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54170619.4040508@FreeBSD.org> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on mail.in-addr.com); SAEximRunCond expanded to false Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Sep 2014 16:02:56 -0000 On Mon, Sep 15, 2014 at 07:30:33PM +0400, Lev Serebryakov wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > > If I want to connect to my workstation at $work, I'm forced to use > Juniper Secure Access SSL VPN + rdesktop. I connect to our office > JunOS gateway with browser, and run RDesktop from it. But it requires > to use supported OS (Windows / MacOS X / Linux), as tunnel is created > via binary browser plugin. > > Is it possible to emulate this on FreeBSD? rdesktop from ports should > work as client, as I access standard Windows system, but I need some > way to emulate this VPN tunnel. Is it possible? Did you try any of the results from Google? Search for "juniper ssl vpn open source" (without the quotes) seems to show up some possibilities. Regards, Gary From owner-freebsd-net@FreeBSD.ORG Mon Sep 15 16:12:54 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 628B7B18; Mon, 15 Sep 2014 16:12:54 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 279C0A26; Mon, 15 Sep 2014 16:12:54 +0000 (UTC) Received: from [127.0.0.1] (nat.in.devexperts.com [89.113.128.63]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 5453956405; Mon, 15 Sep 2014 20:12:53 +0400 (MSK) Message-ID: <54171003.3090001@FreeBSD.org> Date: Mon, 15 Sep 2014 20:12:51 +0400 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Gary Palmer Subject: Re: Juniper Secure Access SSL VPN access from FreeBSD? References: <54170619.4040508@FreeBSD.org> <20140915160253.GA51285@in-addr.com> In-Reply-To: <20140915160253.GA51285@in-addr.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Sep 2014 16:12:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 15.09.2014 20:02, Gary Palmer wrote: >> If I want to connect to my workstation at $work, I'm forced to >> use Juniper Secure Access SSL VPN + rdesktop. I connect to our >> office JunOS gateway with browser, and run RDesktop from it. But >> it requires to use supported OS (Windows / MacOS X / Linux), as >> tunnel is created via binary browser plugin. >> >> Is it possible to emulate this on FreeBSD? rdesktop from ports >> should work as client, as I access standard Windows system, but I >> need some way to emulate this VPN tunnel. Is it possible? > > Did you try any of the results from Google? Search for "juniper > ssl vpn open source" (without the quotes) seems to show up some > possibilities. Yep, but all of them based on fact, that it works under Linux. For example, here are script (jvpn.pl), which emulates browser, but it loads Linux-specific share object from browser plugin (libncui.so) and calls Linux binary (ncsvc), and it will not natively work under FreeBSD. Linux emulator is my last resort, but maybe, here are some other ways? - -- // Lev Serebryakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUFxADXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EeP9H4P/Avg5RzBp5FRnxK6DWIVvOst Y/vNPMaAuBB7SAZt8x7mZN/LFdzwjPi68G8xrtxkQhCbiARW5u5eOPhyXToWPwyF wbdwErM1767XqTosX7jke2ZmI6Uq8TWO5QsRtYpYZx6GXTCJzGluhamA6/uw1bf6 7QCO4/LctvgxdzezJKHdh71ZjRNhezuVnCz9oOux2SXXrHPpav0m9gbBPhRCwrSB aRAn4N7Ade/jaRpUhCWGyyulCwrp6T8xSyZjZ5wRoIrDHDkknMYDqdwMz8LyoIiv A9tltI0J6bDSCiOpCPCPPHlD077Xq9/qBvg2UGk39lTKwc5k9fQzdMP7sfnUAs02 BSqc3vIHopnJ7hcC1p13l2N0Wo27mxRXzaTiWNyoeWB1lgE5758xMWusl7XK/QRp UT95Kct2bJWnkP3oEQv1oU1wCuxKGWRaJSBGx3O19FHAdhNBornspeWepfUYTvb+ TwF6bXLNuHo6ckTH+90RlUs1cILCdHkTgLwlOvT9RJd/XTrcuHMrCUZ3uKv+za8T Sm/oyO2zSarMO2KKRaWMleF7iWUM35UylpSRcxh7AdWol//FjdcNIgPQymmYBUGr x2D7VuR8DVFVyL+AufL6APlY6O8A5l2XVhDrE0x8QomARzu6MnNd6NylLw39rZWj jNBvuGFt16ZRxHfHIUOW =mcyT -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Mon Sep 15 16:14:59 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 675E9BFE; Mon, 15 Sep 2014 16:14:59 +0000 (UTC) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D2AF0A4C; Mon, 15 Sep 2014 16:14:58 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id u57so4234506wes.22 for ; Mon, 15 Sep 2014 09:14:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=EDpT3rEeCquGBQlAJkhJIYGGtucyP9FyHRw1Q1I9AUQ=; b=lEvbzYCQ/Y/1t9eDsOZy/pTL/0HiuFhF79Hg1/GVSB0IQXGS2sQmjsAyRfHgO6b7Xt 7priG1oLon0WqiiWWoueSjOckRZpnxWIdjehwghrNzMub689z46dX3/WNTFP/1Q2XuWE yi8I91PWWwNglrLFF1EIwuoEqDAydVoAqLmCopEDvX/gkeb0JRG5124hcjAFQ4xc/Sgw 7g1K2EAhHNdxFhzVuK79CMReYJZytZ7zfQgioZiLq0A+uGnY7BCr8HK/up2WRIFFPlnC 2Ivy+dET6kBydBuWl5GOAyDN/zKoQcoCshu1g+xFZ9ieQ8ubIpkrR9QtI8OmGBzVARyc HP3A== MIME-Version: 1.0 X-Received: by 10.180.206.230 with SMTP id lr6mr24792649wic.82.1410797694338; Mon, 15 Sep 2014 09:14:54 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.194.126.1 with HTTP; Mon, 15 Sep 2014 09:14:54 -0700 (PDT) In-Reply-To: <5414D10E.7020000@FreeBSD.org> References: <5414D10E.7020000@FreeBSD.org> Date: Mon, 15 Sep 2014 10:14:54 -0600 X-Google-Sender-Auth: Hzq8tmQCBDGwqjYbgIaMTI3lboI Message-ID: Subject: Re: if_lagg(4) accounting changes From: Alan Somers To: "Alexander V. Chernikov" Content-Type: text/plain; charset=UTF-8 Cc: "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Sep 2014 16:14:59 -0000 On Sat, Sep 13, 2014 at 5:19 PM, Alexander V. Chernikov wrote: > Hello list. > > I'd like to commit some changes to lagg counters which might be worth > discussion. > > Diff is available at https://reviews.freebsd.org/D781 > Quoting its summary: > > > While counting packets using per-cpu counters might not introduce > any significant overhead at current rates, we do not need to > do such accounting at all. > > lagg in general is pure control-plane interface, its action on > receive should be just to change packet src if pointer. > Its action on transmit should be just selecting output interface > based on flowid. > It should not generate any errors on its own. > > In fact, RX lagg path can be skipped by setting correct ifp inside > NIC driver. TX path should be handled by generic multipath L2 nexthops > inside routing code. > > This is first step for implementing this scenario. > One side effect is that we're now collecting all counters (including > errors) from underlying interfaces. Generally most networking HW vendors > implement this behavior for their equipment and this is really the > reasonable thing to do. Sounds interesting. I'll give it a thorough review soon, but probably not today. -Alan From owner-freebsd-net@FreeBSD.ORG Mon Sep 15 16:20:07 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A3C7EDD4; Mon, 15 Sep 2014 16:20:07 +0000 (UTC) Received: from mail.in-addr.com (mail.in-addr.com [IPv6:2a01:4f8:191:61e8::2525:2525]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 67242ABC; Mon, 15 Sep 2014 16:20:07 +0000 (UTC) Received: from gjp by mail.in-addr.com with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XTZ0X-0004RP-Ij; Mon, 15 Sep 2014 17:20:05 +0100 Date: Mon, 15 Sep 2014 17:20:05 +0100 From: Gary Palmer To: Lev Serebryakov Subject: Re: Juniper Secure Access SSL VPN access from FreeBSD? Message-ID: <20140915162005.GB51285@in-addr.com> References: <54170619.4040508@FreeBSD.org> <20140915160253.GA51285@in-addr.com> <54171003.3090001@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54171003.3090001@FreeBSD.org> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on mail.in-addr.com); SAEximRunCond expanded to false Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Sep 2014 16:20:07 -0000 On Mon, Sep 15, 2014 at 08:12:51PM +0400, Lev Serebryakov wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 15.09.2014 20:02, Gary Palmer wrote: > > >> If I want to connect to my workstation at $work, I'm forced to > >> use Juniper Secure Access SSL VPN + rdesktop. I connect to our > >> office JunOS gateway with browser, and run RDesktop from it. But > >> it requires to use supported OS (Windows / MacOS X / Linux), as > >> tunnel is created via binary browser plugin. > >> > >> Is it possible to emulate this on FreeBSD? rdesktop from ports > >> should work as client, as I access standard Windows system, but I > >> need some way to emulate this VPN tunnel. Is it possible? > > > > Did you try any of the results from Google? Search for "juniper > > ssl vpn open source" (without the quotes) seems to show up some > > possibilities. > Yep, but all of them based on fact, that it works under Linux. For > example, here are script (jvpn.pl), which emulates browser, but it > loads Linux-specific share object from browser plugin (libncui.so) and > calls Linux binary (ncsvc), and it will not natively work under FreeBSD. > > Linux emulator is my last resort, but maybe, here are some other ways? Not that work reliably. I know someone who had to use a Juniper VPN solution and got it working under Linux without any binary plugins, but he went on vacation and when he came back a couple of weeks later he couldn't get it working again and struggled for days before giving up and running Windows in a VM. As best I understand it, it's a standard IPSEC VPN, but getting past the authentication to get to the IPSEC session is the tricky part. Regards, Gary From owner-freebsd-net@FreeBSD.ORG Mon Sep 15 16:46:22 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C371C816 for ; Mon, 15 Sep 2014 16:46:22 +0000 (UTC) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B526DB8 for ; Mon, 15 Sep 2014 16:46:21 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id u10so1250616lbd.13 for ; Mon, 15 Sep 2014 09:46:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=txd29MSzVO/F1AMQy9ZmbIQ1O/ZtKDro95nQVysu0E0=; b=OK2UFaa4tktIIh6PlZ9t0M5ASUCsQFfPNpJ5DF8Nz7EBR/wwZxrgvyI3qO0sFSn2MB RmcJVVq+DPiH8Ev6dLrZVIEQh6Zar0sOlKqQtZuui0bvxSiGPl+QqoE6UOEeN+bSeam9 7xhUMPTYct8iU3dVu7kd9JpM/anVqsdG0gf7dVcjxeHxKKRysztIXtJqfsDX2rgK6SkG 0twJv5xaLC/mdZg/bUvi6TVhWMvARb/Rd9oDxTDOZlkHDNq8iXkqjKGIR3wSZDo5DcFN Cg2goAsdCby/BnENMUk+DmGLe2nZgeQ/6s9VdQXBtENyX2CmbdkbUl3Bpxzo/VodhKEs q4Fg== X-Gm-Message-State: ALoCoQnPYPYFjAsGrmp5PBKWaS67iLAyVs8vSuK/EStTNWqCJXZ7WEWmEfX5rcEbQS9KMY7y/O1F MIME-Version: 1.0 X-Received: by 10.112.52.225 with SMTP id w1mr28587177lbo.44.1410799243354; Mon, 15 Sep 2014 09:40:43 -0700 (PDT) Received: by 10.112.219.106 with HTTP; Mon, 15 Sep 2014 09:40:43 -0700 (PDT) In-Reply-To: <20140915160253.GA51285@in-addr.com> References: <54170619.4040508@FreeBSD.org> <20140915160253.GA51285@in-addr.com> Date: Mon, 15 Sep 2014 18:40:43 +0200 Message-ID: Subject: Re: Juniper Secure Access SSL VPN access from FreeBSD? From: Damien Fleuriot To: Gary Palmer Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , Lev Serebryakov X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Sep 2014 16:46:22 -0000 Isn't the plugin closed-source ? If it is and you have no alternatives, you could try : 1/ install the linux compatibility framework to be able to run linux binaries 2/ install a user agent spoofer to trick the Juniper SA into thinking you're running linux 3/ log in to the SA, launches linux plugin, plugin uses the compatibility framework You might need to install a linux version of chrome or FF to get the plugin to work. On 15 September 2014 18:02, Gary Palmer wrote: > On Mon, Sep 15, 2014 at 07:30:33PM +0400, Lev Serebryakov wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > > > If I want to connect to my workstation at $work, I'm forced to use > > Juniper Secure Access SSL VPN + rdesktop. I connect to our office > > JunOS gateway with browser, and run RDesktop from it. But it requires > > to use supported OS (Windows / MacOS X / Linux), as tunnel is created > > via binary browser plugin. > > > > Is it possible to emulate this on FreeBSD? rdesktop from ports should > > work as client, as I access standard Windows system, but I need some > > way to emulate this VPN tunnel. Is it possible? > > Did you try any of the results from Google? Search for > "juniper ssl vpn open source" (without the quotes) seems to show up > some possibilities. > > Regards, > > Gary > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Sep 15 16:48:47 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E092A2A; Mon, 15 Sep 2014 16:48:47 +0000 (UTC) Received: from mail.in-addr.com (mail.in-addr.com [IPv6:2a01:4f8:191:61e8::2525:2525]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 405A2DE2; Mon, 15 Sep 2014 16:48:47 +0000 (UTC) Received: from gjp by mail.in-addr.com with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XTZSH-0004Uv-HT; Mon, 15 Sep 2014 17:48:45 +0100 Date: Mon, 15 Sep 2014 17:48:45 +0100 From: Gary Palmer To: Lev Serebryakov Subject: Re: Juniper Secure Access SSL VPN access from FreeBSD? Message-ID: <20140915164845.GC51285@in-addr.com> References: <54170619.4040508@FreeBSD.org> <20140915160253.GA51285@in-addr.com> <54171003.3090001@FreeBSD.org> <20140915162005.GB51285@in-addr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140915162005.GB51285@in-addr.com> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on mail.in-addr.com); SAEximRunCond expanded to false Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Sep 2014 16:48:47 -0000 On Mon, Sep 15, 2014 at 05:20:05PM +0100, Gary Palmer wrote: > On Mon, Sep 15, 2014 at 08:12:51PM +0400, Lev Serebryakov wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > On 15.09.2014 20:02, Gary Palmer wrote: > > > > >> If I want to connect to my workstation at $work, I'm forced to > > >> use Juniper Secure Access SSL VPN + rdesktop. I connect to our > > >> office JunOS gateway with browser, and run RDesktop from it. But > > >> it requires to use supported OS (Windows / MacOS X / Linux), as > > >> tunnel is created via binary browser plugin. > > >> > > >> Is it possible to emulate this on FreeBSD? rdesktop from ports > > >> should work as client, as I access standard Windows system, but I > > >> need some way to emulate this VPN tunnel. Is it possible? > > > > > > Did you try any of the results from Google? Search for "juniper > > > ssl vpn open source" (without the quotes) seems to show up some > > > possibilities. > > Yep, but all of them based on fact, that it works under Linux. For > > example, here are script (jvpn.pl), which emulates browser, but it > > loads Linux-specific share object from browser plugin (libncui.so) and > > calls Linux binary (ncsvc), and it will not natively work under FreeBSD. > > > > Linux emulator is my last resort, but maybe, here are some other ways? > > > Not that work reliably. I know someone who had to use a Juniper VPN > solution and got it working under Linux without any binary plugins, > but he went on vacation and when he came back a couple of weeks later > he couldn't get it working again and struggled for days before giving up > and running Windows in a VM. > > As best I understand it, it's a standard IPSEC VPN, but getting past the > authentication to get to the IPSEC session is the tricky part. > > Regards, > > Gary You might want to try https://www.shrew.net/download/ike - it claims to support Juniper secure gateways and runs on FreeBSD. I have no idea if it works or not. Regards, Gary From owner-freebsd-net@FreeBSD.ORG Mon Sep 15 17:22:34 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ABA43601 for ; Mon, 15 Sep 2014 17:22:34 +0000 (UTC) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7A8292F1 for ; Mon, 15 Sep 2014 17:22:33 +0000 (UTC) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.14.7/8.14.7) with ESMTP id s8FH0CCV042914 for ; Mon, 15 Sep 2014 12:00:12 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.16.32.30] (rrcs-50-84-127-134.sw.biz.rr.com [50.84.127.134]) by mail.shrew.net (Postfix) with ESMTPSA id 95FA218B016 for ; Mon, 15 Sep 2014 12:00:03 -0500 (CDT) Message-ID: <54171B47.7080008@shrew.net> Date: Mon, 15 Sep 2014 12:00:55 -0500 From: Matthew Grooms User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Juniper Secure Access SSL VPN access from FreeBSD? References: <54170619.4040508@FreeBSD.org> <20140915160253.GA51285@in-addr.com> <54171003.3090001@FreeBSD.org> <20140915162005.GB51285@in-addr.com> <20140915164845.GC51285@in-addr.com> In-Reply-To: <20140915164845.GC51285@in-addr.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx2.shrew.net [10.24.10.11]); Mon, 15 Sep 2014 12:00:12 -0500 (CDT) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Sep 2014 17:22:34 -0000 On 9/15/2014 11:48 AM, Gary Palmer wrote: > On Mon, Sep 15, 2014 at 05:20:05PM +0100, Gary Palmer wrote: >> On Mon, Sep 15, 2014 at 08:12:51PM +0400, Lev Serebryakov wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA512 >>> >>> On 15.09.2014 20:02, Gary Palmer wrote: >>> >>>>> If I want to connect to my workstation at $work, I'm forced to >>>>> use Juniper Secure Access SSL VPN + rdesktop. I connect to our >>>>> office JunOS gateway with browser, and run RDesktop from it. But >>>>> it requires to use supported OS (Windows / MacOS X / Linux), as >>>>> tunnel is created via binary browser plugin. >>>>> >>>>> Is it possible to emulate this on FreeBSD? rdesktop from ports >>>>> should work as client, as I access standard Windows system, but I >>>>> need some way to emulate this VPN tunnel. Is it possible? >>>> Did you try any of the results from Google? Search for "juniper >>>> ssl vpn open source" (without the quotes) seems to show up some >>>> possibilities. >>> Yep, but all of them based on fact, that it works under Linux. For >>> example, here are script (jvpn.pl), which emulates browser, but it >>> loads Linux-specific share object from browser plugin (libncui.so) and >>> calls Linux binary (ncsvc), and it will not natively work under FreeBSD. >>> >>> Linux emulator is my last resort, but maybe, here are some other ways? >> >> Not that work reliably. I know someone who had to use a Juniper VPN >> solution and got it working under Linux without any binary plugins, >> but he went on vacation and when he came back a couple of weeks later >> he couldn't get it working again and struggled for days before giving up >> and running Windows in a VM. >> >> As best I understand it, it's a standard IPSEC VPN, but getting past the >> authentication to get to the IPSEC session is the tricky part. >> >> Regards, >> >> Gary > You might want to try https://www.shrew.net/download/ike - it claims to > support Juniper secure gateways and runs on FreeBSD. I have no idea if it > works or not. > As I understand it, Juniper has an 'SSL' VPN product that has nothing to do with IPsec. Juniper abandoned it's IPsec based client in favor of it's newer 'SSL' based client some time ago. The Shrew Soft product only supports IPsec based connectivity and is compatible with SSG/SRX systems. Hope this helps, -Matthew From owner-freebsd-net@FreeBSD.ORG Tue Sep 16 05:39:24 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B6F5A44; Tue, 16 Sep 2014 05:39:24 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BA730645; Tue, 16 Sep 2014 05:39:22 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 00DD71FE027; Tue, 16 Sep 2014 07:39:13 +0200 (CEST) Message-ID: <5417CCF6.10204@selasky.org> Date: Tue, 16 Sep 2014 07:39:02 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: CeDeROM , FreeBSD Questions Mailing List , "freebsd-hackers@freebsd.org" , freebsd-net@freebsd.org, "freebsd-usb@FreeBSD.org" Subject: Re: U3G QDL firmware loader for GOBI2000/HP_UN2420 MiniPCI/USB 3G/GPS References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Sep 2014 05:39:24 -0000 On 09/15/14 17:16, CeDeROM wrote: > Hello world! :-) > > I have changed my machine, there is a built-in GOBI2000 / HP UN2420 > 3G/GPS module installable as MiniPCI card and visible as USB device. I > have added its VID/PID to the usbdevs and u3g.c module, so after > recompilation it gets recognised by u3g module and apropriate > /dev/cuaU* device shows up.. > > The problem is that device does not store firmware inside non-volatile > memory, so user needs to upload it after power-on. I have the firmware > files. I can test modem with success after reboot from Win7 which > uploads firmware into device. Still, I need to upload the firmware > somehow on my FreeBSD. > > The upload protocol is QDL and /dev/cuaU0 shows up waiting for > command. Which utility can I use to upload firmware with QDL? I have > seen one post [1] regarding this problem in the past but the QDL > utility was not named explicitly. > > Any hints welcome! :-) > > Tomek > > [1] http://lists.freebsd.org/pipermail/freebsd-usb/2010-October/009384.html > Hi, Maybe you can use some tools to sniff the USB protocol under the other operating system. The protocol is probably not too complicated, and just replay the traffic. --HPS From owner-freebsd-net@FreeBSD.ORG Tue Sep 16 06:59:19 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5C2AF987; Tue, 16 Sep 2014 06:59:19 +0000 (UTC) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F3562D58; Tue, 16 Sep 2014 06:59:18 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id i7so2465120oag.33 for ; Mon, 15 Sep 2014 23:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lp6LCa3ZaznZU93eKYJJovoCzfjfcRjt8eEOaUyrf9U=; b=FQnPSe1AO1a9L2CEvfUVs6LgQ9AFWBsB5smJQINid+DS+XUlAcA5u7n4RGRA8Trcxs AN4GX/AzF6LAaik4mpN9nXzlFxK7MvvIQMJbRAYC52yZUSgzRBwhjhbZWwfqEiY2qT5S pzzlfr/75kdt89ZWCQZzIQlZf85645m0QWx2wccNuX0SMZYq9HSgm1xGYO3IJaeOscW/ sIAD0DMGDTR/CFH3VL9CpEVcsXP/RCMykQZKPUUKuGI9XRsJLoYkE8w69g9x1/1jaZC5 Pl2SsF8EgzCEmDohaFKAsN52GS5AJcRbPdXKIlWIV+fMOT5QxWnOCGR5Nmf7eV0Mb3M6 4v1A== MIME-Version: 1.0 X-Received: by 10.60.175.166 with SMTP id cb6mr9099996oec.64.1410850758091; Mon, 15 Sep 2014 23:59:18 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.202.58.196 with HTTP; Mon, 15 Sep 2014 23:59:18 -0700 (PDT) In-Reply-To: <5417CCF6.10204@selasky.org> References: <5417CCF6.10204@selasky.org> Date: Tue, 16 Sep 2014 08:59:18 +0200 X-Google-Sender-Auth: 5fJ56He3INDiygHWWFUADDPeRN8 Message-ID: Subject: Re: U3G QDL firmware loader for GOBI2000/HP_UN2420 MiniPCI/USB 3G/GPS From: CeDeROM To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , Ruslan Bukin , FreeBSD Questions Mailing List , "freebsd-usb@FreeBSD.org" , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Sep 2014 06:59:19 -0000 On Tue, Sep 16, 2014 at 7:39 AM, Hans Petter Selasky wrote: > On 09/15/14 17:16, CeDeROM wrote: >> Hello world! :-) >> I have changed my machine, there is a built-in GOBI2000 / HP UN2420 >> 3G/GPS module installable as MiniPCI card and visible as USB device. I >> have added its VID/PID to the usbdevs and u3g.c module, so after >> recompilation it gets recognised by u3g module and apropriate >> /dev/cuaU* device shows up.. >> The problem is that device does not store firmware inside non-volatile >> memory, so user needs to upload it after power-on. I have the firmware >> files. I can test modem with success after reboot from Win7 which >> uploads firmware into device. Still, I need to upload the firmware >> somehow on my FreeBSD. >> The upload protocol is QDL and /dev/cuaU0 shows up waiting for >> command. Which utility can I use to upload firmware with QDL? I have >> seen one post [1] regarding this problem in the past but the QDL >> utility was not named explicitly. >> Any hints welcome! :-) >> Tomek >> [1] >> http://lists.freebsd.org/pipermail/freebsd-usb/2010-October/009384.html>> > Hi, > Maybe you can use some tools to sniff the USB protocol under the other > operating system. The protocol is probably not too complicated, and just > replay the traffic. > --HPS I just got the gobi_loader application sources from Ruslan Bukin! I will try it out and when it works fine I will send patches to the FreeBSD base along with my u3g patches, it may come handy for others as well :-) Thank you!! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-net@FreeBSD.ORG Tue Sep 16 08:38:05 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 53AE7B6D; Tue, 16 Sep 2014 08:38:05 +0000 (UTC) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1F9E0947; Tue, 16 Sep 2014 08:38:05 +0000 (UTC) Received: by mail-pa0-f44.google.com with SMTP id kx10so8357771pab.17 for ; Tue, 16 Sep 2014 01:38:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=U5MQzLGn8TpjgYhKOnifjJSUBYGETx31AKJjFjS88B4=; b=B7nGGO05xD+nnIBlZ6UmW3TOOaf9g/0J3yZ2frKKNgG3EDRMvyffehgKG3fjJNLBtP ropMBemn6hV++XpySSqRozJhVn4MuG4e72jIW779L/diKbZEVz5JKBOQ0S3sZoSCFJl6 pFJUm0yWFQfjLF/UnW3OPU2eVXqNiB7GwoJAcHa3gH8RJFgYIiw03hCz8S1Bwjqqr7Ny G/covxW7rUoZJOkUKMDg53PDi8VJc29w0C5UqCc6XRoAzIKIRrMzB//RdpjYycgVsQkl V2KPlb+LcU8YOxkSAWustV2m1ZXbhSmz0zG3n4s0ASsDx6pxYH6dpn4Xiwl7Jtl2azV4 Qj2g== X-Received: by 10.66.243.6 with SMTP id wu6mr12779212pac.157.1410856682477; Tue, 16 Sep 2014 01:38:02 -0700 (PDT) Received: from pyunyh@gmail.com ([106.247.248.2]) by mx.google.com with ESMTPSA id uf6sm13987544pac.16.2014.09.16.01.37.58 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 16 Sep 2014 01:38:01 -0700 (PDT) From: Yonghyeon PYUN X-Google-Original-From: "Yonghyeon PYUN" Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 16 Sep 2014 17:37:49 +0900 Date: Tue, 16 Sep 2014 17:37:49 +0900 To: Brett Glass Subject: Re: jme interface bounces up and down, up and down.... Message-ID: <20140916083749.GA988@michelle.fasterthan.com> Reply-To: pyunyh@gmail.com References: <201409141629.KAA29705@mail.lariat.net> <20140915060819.GA967@michelle.fasterthan.com> <201409151447.IAA08325@mail.lariat.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201409151447.IAA08325@mail.lariat.net> User-Agent: Mutt/1.4.2.3i Cc: questions@freebsd.org, net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Sep 2014 08:38:05 -0000 On Mon, Sep 15, 2014 at 08:19:37AM -0600, Brett Glass wrote: > At 12:08 AM 9/15/2014, Yonghyeon PYUN wrote: > > >Would you show me the output of dmesg(jme(4) and jmphy(4) only) to > >know exact chip revision? > > Here you are. > > jme0: port > 0xec80-0xecff,0xe800-0xe8ff mem 0xfbffc000-0xfbfff > fff irq 18 at device 0.0 on pci1 > jme0: MSIX count : 8 > jme0: MSI count : 8 > jme0: attempting to allocate 1 MSI-X vectors (8 supported) > msi: routing MSI-X IRQ 256 to local APIC 0 vector 52 > jme0: using IRQ 256 for MSI-X > jme0: Using 1 MSIX messages. > jme0: PCI device revision : 0x0250 > jme0: Chip revision : 0x11 ^^^^^^^^^^^^^^^^^^^^^^^^^^ Initially I suspected you might have relatively new JMC25x controller but it seems you have early revision of the controller(JMC250 A2). Early revision of the controller has 1000baseT link establishment issue with 802.3az capable switches. The issue is explained in jme(4) man page. The known workaround is to manually set 100baseTX media. I recall you mentioned Linux had no problems so I wonder Linux was able to establish a 1000baseT link. In theory, the workaround could be implemented in driver but it is layering violation and will have to duplicate lots of work done by mii(4). > jme0: ethernet hardware address not found in EEPROM. > jme0: PHY is at address 1. > jme0: Read request size : 512 bytes. > jme0: TLP payload size : 128 bytes. > miibus0: on jme0 > jmphy0: PHY 1 on miibus0 > jmphy0: OUI 0x00d831, model 0x0021, rev. 1 > jmphy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, > 100baseTX-FDX, 100baseTX-FDX-flow, > 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, > 1000baseT-FDX-flow, 1000baseT-FDX > -flow-master, auto, auto-flow > jme0: bpf attached > jme0: Ethernet address: e0:cb:4e:54:23:ac > > I do not particularly like JMicron chips (their faulty SSD > controllers have cost me a lot of time and money), but that's I don't have experiences with other JMicron products so can't comment on SSD. JMC25x may not be world best gigabit ethernet controller but I was quite satisfied with its high performance and clear documentation and Vendor's support. > what's on the motherboard of this Asus. So, I need to find a way to > make it work. > > --Brett Glass > From owner-freebsd-net@FreeBSD.ORG Tue Sep 16 17:27:15 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3FE93798; Tue, 16 Sep 2014 17:27:15 +0000 (UTC) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id D80BDF6C; Tue, 16 Sep 2014 17:27:14 +0000 (UTC) Received: from Toshi.lariat.net (IDENT:ppp1000.lariat.net@localhost [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id LAA25854; Tue, 16 Sep 2014 11:27:05 -0600 (MDT) Message-Id: <201409161727.LAA25854@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 16 Sep 2014 10:16:40 -0600 To: pyunyh@gmail.com From: Brett Glass Subject: Re: jme interface bounces up and down, up and down.... In-Reply-To: <20140916083749.GA988@michelle.fasterthan.com> References: <201409141629.KAA29705@mail.lariat.net> <20140915060819.GA967@michelle.fasterthan.com> <201409151447.IAA08325@mail.lariat.net> <20140916083749.GA988@michelle.fasterthan.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: questions@freebsd.org, net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Sep 2014 17:27:15 -0000 So, what is the best solution? I cannot throw out the machine, and because I am using a VLAN switch to multiplex the port to three LANs I do not want to reduce the speed to 100 Mbps. Ideas? --Brett Glass At 02:37 AM 9/16/2014, Yonghyeon PYUN wrote: >On Mon, Sep 15, 2014 at 08:19:37AM -0600, Brett Glass wrote: > > At 12:08 AM 9/15/2014, Yonghyeon PYUN wrote: > > > > >Would you show me the output of dmesg(jme(4) and jmphy(4) only) to > > >know exact chip revision? > > > > Here you are. > > > > jme0: port > > 0xec80-0xecff,0xe800-0xe8ff mem 0xfbffc000-0xfbfff > > fff irq 18 at device 0.0 on pci1 > > jme0: MSIX count : 8 > > jme0: MSI count : 8 > > jme0: attempting to allocate 1 MSI-X vectors (8 supported) > > msi: routing MSI-X IRQ 256 to local APIC 0 vector 52 > > jme0: using IRQ 256 for MSI-X > > jme0: Using 1 MSIX messages. > > jme0: PCI device revision : 0x0250 > > jme0: Chip revision : 0x11 > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > >Initially I suspected you might have relatively new JMC25x >controller but it seems you have early revision of the >controller(JMC250 A2). Early revision of the controller has >1000baseT link establishment issue with 802.3az capable switches. >The issue is explained in jme(4) man page. The known workaround is >to manually set 100baseTX media. I recall you mentioned Linux had >no problems so I wonder Linux was able to establish a 1000baseT >link. >In theory, the workaround could be implemented in driver but it >is layering violation and will have to duplicate lots of work done >by mii(4). > > > jme0: ethernet hardware address not found in EEPROM. > > jme0: PHY is at address 1. > > jme0: Read request size : 512 bytes. > > jme0: TLP payload size : 128 bytes. > > miibus0: on jme0 > > jmphy0: PHY 1 on miibus0 > > jmphy0: OUI 0x00d831, model 0x0021, rev. 1 > > jmphy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, > > 100baseTX-FDX, 100baseTX-FDX-flow, > > 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, > > 1000baseT-FDX-flow, 1000baseT-FDX > > -flow-master, auto, auto-flow > > jme0: bpf attached > > jme0: Ethernet address: e0:cb:4e:54:23:ac > > > > I do not particularly like JMicron chips (their faulty SSD > > controllers have cost me a lot of time and money), but that's > >I don't have experiences with other JMicron products so can't >comment on SSD. JMC25x may not be world best gigabit ethernet >controller but I was quite satisfied with its high performance and >clear documentation and Vendor's support. > > > what's on the motherboard of this Asus. So, I need to find a way to > > make it work. > > > > --Brett Glass > > From owner-freebsd-net@FreeBSD.ORG Tue Sep 16 22:48:53 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7204CE43 for ; Tue, 16 Sep 2014 22:48:53 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 51B99900 for ; Tue, 16 Sep 2014 22:48:53 +0000 (UTC) Received: from [192.168.200.200] (unknown [50.136.155.142]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 7990B19413C; Tue, 16 Sep 2014 22:48:52 +0000 (UTC) Subject: Re: Multipath TCP for FreeBSD v0.4 From: Sean Bruno Reply-To: sbruno@freebsd.org To: Nigel Williams In-Reply-To: <540D0741.6030403@swin.edu.au> References: <513CB9AF.3090409@swin.edu.au> <53BF8945.3000802@swin.edu.au> <540D0741.6030403@swin.edu.au> Content-Type: text/plain; charset="us-ascii" Date: Tue, 16 Sep 2014 15:48:51 -0700 Message-ID: <1410907731.1166.13.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Sep 2014 22:48:53 -0000 On Mon, 2014-09-08 at 11:32 +1000, Nigel Williams wrote: > Hi, > > We recently released a new tech report "Design Overview of Multipath TCP > version 0.4 for FreeBSD-11" [1]. The report provides some details on > various aspects of the implementation (session management, data-level > retransmission etc), as of the most recent v0.4 patch [2]. > > cheers, > nigel > > [1] http://caia.swin.edu.au/reports/140822A/CAIA-TR-140822A.pdf > [2] http://caia.swin.edu.au/urp/newtcp/mptcp/tools.html > Nigel: Hi! Are you folks interested in having this patchset incorporated into the main line of FreeBSD? I'm open to putting up a phabricator review for you folks at https://reviews.freebsd.org if that's something you guys want to do? sean > > On 11/07/14 16:50, Nigel Williams wrote: > > Hello all, > > > > A new v0.4 patch is available at [1]. This release is mostly bug-fixes > > and improvements to core functionality (establishing/closing > > connections, retransmissions etc), and also brings the implementation up > > to a more recent version of FreeBSD-HEAD. > > > > The full list of changes and caveats can be found in [2] and [3], but > > briefly: > > - Patched against r265307 of FreeBSD-HEAD. This is prior to some recent > > TCP reassembly memory management changes and the patch will be brought > > up to a newer revision soon (currently working on integrating those > > changes). > > - Added data-level retransmits and subflows can now stall and recover > > (or timeout) during a connection. > > - The path management and packet scheduler are still fairly rudimentary, > > and I haven't yet implemented coupled CC. > > - The patch is still under heavy development so consider this release > > code to be of alpha quality. > > > > This release ties up work that was partially supported by a gift from > > The Cisco University Research Program Fund. Future releases will be > > supported by a grant from the FreeBSD Foundation. > > > > P.S. I will be working on the patch full-time again so updates should be > > a little more frequent from this point onwards. > > > > cheers, > > nigel > > > > [1] http://caia.swin.edu.au/urp/newtcp/mptcp/tools.html > > [2] http://caia.swin.edu.au/urp/newtcp/mptcp/tools/mptcp-changelog-v0.4.txt > > [3] http://caia.swin.edu.au/urp/newtcp/mptcp/tools/mptcp-readme-v0.4.txt > > > > > > > > On 11/03/13 03:49, Lawrence Stewart wrote: > >> Hi all, > >> > >> The CAIA MPTCP team is pleased to announce the initial release of our > >> multipath TCP implementation for FreeBSD 10-CURRENT which is available > >> from [1]. This release contains wire-related protocol code and a lot of > >> core stack infrastructure. It is capable of running regular TCP flows > >> and single or multi-subflow MPTCP flows (with some caveats as documented > >> in the readme [2]). > >> > >> We consider this code to be of alpha quality and plan to release > >> frequent updates going forward as we continue to flesh out additional > >> features and fix the rough edges. > >> > >> That being said, we welcome everyone to start playing with the code and > >> provide feedback, bug reports, fixes, praise and/or abuse ;) > >> > >> The "Multipath TCP for FreeBSD" project team consists of: > >> > >> Nigel Williams: lead R&D engineer > >> Lawrence Stewart: supporting R&D engineer > >> Grenville Armitage: principal investigator & overall project lead > >> > >> Many thanks go to the Cisco University Research Program Fund at > >> Community Foundation Silicon Valley for their support of this work. > >> > >> Have fun with it! > >> > >> Cheers, > >> Lawrence, Nigel & Grenville > >> > >> http://caia.swin.edu.au > >> > >> > >> > >> [1] http://caia.swin.edu.au/urp/newtcp/mptcp/tools.html > >> > >> [2] http://caia.swin.edu.au/urp/newtcp/mptcp/tools/mptcp-readme-v0.1.txt > >> _______________________________________________ > >> freebsd-net@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-net > >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > >> > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Sep 16 22:59:13 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0814F389; Tue, 16 Sep 2014 22:59:13 +0000 (UTC) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3E36E9F1; Tue, 16 Sep 2014 22:59:12 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id b17so758794lan.32 for ; Tue, 16 Sep 2014 15:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mvDUcdcOXZcu47lM6BKdxhiW/G3czwEWEALWZOGIVFs=; b=F5qhr6V7xPX7E/oDMJA5NZIk5+7KXXtaO0m+RoftXJd8dyUFCc8H4aMq8uNLP9gopx IX1Otv7uDEq2pe7WQ3Us3ggyJZUAcAE49XrXVxx4cPf1Zg7/FdGCSRlcjDSGz433IiSg SblaWf5mjgmIc4jg/73/iQKCd5Xstl6qscC/QtyzDNy6qU+RTZ2m6TzMhV8T9U8S59LK NK/cIx3ih74LG70OqU1HuVEzWJg74ECCueBEl9wcrlzz3smIDjWopN+DMwJiLg//Jzii pouUCO7dGSJPpPGPl9zXuCnRjTe9lz6M6/+FPOhbgHiWvmwt5G8P3zmi7r3G/UN6InyR e1EQ== MIME-Version: 1.0 X-Received: by 10.152.28.230 with SMTP id e6mr40494427lah.62.1410908350039; Tue, 16 Sep 2014 15:59:10 -0700 (PDT) Received: by 10.152.22.195 with HTTP; Tue, 16 Sep 2014 15:59:09 -0700 (PDT) In-Reply-To: <1410907731.1166.13.camel@bruno> References: <513CB9AF.3090409@swin.edu.au> <53BF8945.3000802@swin.edu.au> <540D0741.6030403@swin.edu.au> <1410907731.1166.13.camel@bruno> Date: Wed, 17 Sep 2014 08:59:09 +1000 Message-ID: Subject: Re: Multipath TCP for FreeBSD v0.4 From: Outback Dingo To: sbruno@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-net@freebsd.org, Nigel Williams X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Sep 2014 22:59:13 -0000 On Wed, Sep 17, 2014 at 8:48 AM, Sean Bruno wrote: > On Mon, 2014-09-08 at 11:32 +1000, Nigel Williams wrote: > > Hi, > > > > We recently released a new tech report "Design Overview of Multipath TCP > > version 0.4 for FreeBSD-11" [1]. The report provides some details on > > various aspects of the implementation (session management, data-level > > retransmission etc), as of the most recent v0.4 patch [2]. > > > > cheers, > > nigel > > > > [1] http://caia.swin.edu.au/reports/140822A/CAIA-TR-140822A.pdf > > [2] http://caia.swin.edu.au/urp/newtcp/mptcp/tools.html > > > > > Nigel: > > Hi! Are you folks interested in having this patchset incorporated into > the main line of FreeBSD? I'm open to putting up a phabricator review > for you folks at https://reviews.freebsd.org if that's something you > guys want to do? > > Im quite curious why you would want to include something thats been found to be broken and not functional into mainline.... if it was working sure... im sure we would love it. However its been months rolling along to get this patch set out after reporting previous bugs that... well... still remain. Id suggest to clear up and push a functional working implementation, might gather more participants. > sean > > > > > On 11/07/14 16:50, Nigel Williams wrote: > > > Hello all, > > > > > > A new v0.4 patch is available at [1]. This release is mostly bug-fixes > > > and improvements to core functionality (establishing/closing > > > connections, retransmissions etc), and also brings the implementation > up > > > to a more recent version of FreeBSD-HEAD. > > > > > > The full list of changes and caveats can be found in [2] and [3], but > > > briefly: > > > - Patched against r265307 of FreeBSD-HEAD. This is prior to some recent > > > TCP reassembly memory management changes and the patch will be brought > > > up to a newer revision soon (currently working on integrating those > > > changes). > > > - Added data-level retransmits and subflows can now stall and recover > > > (or timeout) during a connection. > > > - The path management and packet scheduler are still fairly > rudimentary, > > > and I haven't yet implemented coupled CC. > > > - The patch is still under heavy development so consider this release > > > code to be of alpha quality. > > > > > > This release ties up work that was partially supported by a gift from > > > The Cisco University Research Program Fund. Future releases will be > > > supported by a grant from the FreeBSD Foundation. > > > > > > P.S. I will be working on the patch full-time again so updates should > be > > > a little more frequent from this point onwards. > > > > > > cheers, > > > nigel > > > > > > [1] http://caia.swin.edu.au/urp/newtcp/mptcp/tools.html > > > [2] > http://caia.swin.edu.au/urp/newtcp/mptcp/tools/mptcp-changelog-v0.4.txt > > > [3] > http://caia.swin.edu.au/urp/newtcp/mptcp/tools/mptcp-readme-v0.4.txt > > > > > > > > > > > > On 11/03/13 03:49, Lawrence Stewart wrote: > > >> Hi all, > > >> > > >> The CAIA MPTCP team is pleased to announce the initial release of our > > >> multipath TCP implementation for FreeBSD 10-CURRENT which is available > > >> from [1]. This release contains wire-related protocol code and a lot > of > > >> core stack infrastructure. It is capable of running regular TCP flows > > >> and single or multi-subflow MPTCP flows (with some caveats as > documented > > >> in the readme [2]). > > >> > > >> We consider this code to be of alpha quality and plan to release > > >> frequent updates going forward as we continue to flesh out additional > > >> features and fix the rough edges. > > >> > > >> That being said, we welcome everyone to start playing with the code > and > > >> provide feedback, bug reports, fixes, praise and/or abuse ;) > > >> > > >> The "Multipath TCP for FreeBSD" project team consists of: > > >> > > >> Nigel Williams: lead R&D engineer > > >> Lawrence Stewart: supporting R&D engineer > > >> Grenville Armitage: principal investigator & overall project > lead > > >> > > >> Many thanks go to the Cisco University Research Program Fund at > > >> Community Foundation Silicon Valley for their support of this work. > > >> > > >> Have fun with it! > > >> > > >> Cheers, > > >> Lawrence, Nigel & Grenville > > >> > > >> http://caia.swin.edu.au > > >> > > >> > > >> > > >> [1] http://caia.swin.edu.au/urp/newtcp/mptcp/tools.html > > >> > > >> [2] > http://caia.swin.edu.au/urp/newtcp/mptcp/tools/mptcp-readme-v0.1.txt > > >> _______________________________________________ > > >> freebsd-net@freebsd.org mailing list > > >> http://lists.freebsd.org/mailman/listinfo/freebsd-net > > >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org > " > > >> > > > _______________________________________________ > > > freebsd-net@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Sep 16 23:23:25 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE6A382B for ; Tue, 16 Sep 2014 23:23:25 +0000 (UTC) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AEAE3C8A for ; Tue, 16 Sep 2014 23:23:25 +0000 (UTC) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by gateway2.nyi.internal (Postfix) with ESMTP id B94C6232F for ; Tue, 16 Sep 2014 19:23:23 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute4.internal (MEProxy); Tue, 16 Sep 2014 19:23:23 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date:in-reply-to :references; s=smtpout; bh=sTwgd8jxtRdHquJI8gg6M6L9Klg=; b=cYRVN MZiU7EdF7OlqUQbXI9+fWvbw0FkqEKH8EzeMSQvAejOdFtVUePZgSRs6W3udBHZP fjZ2a6VEC5snx+NyLcJpmgxEFwrnaUaY7S2l7xcnnIO6FEY63l9KXsPPCFVpSlMS CTd0b5UGfncjzPdRxiin0kW5vXVsqM9wQumJck= Received: by web3.nyi.internal (Postfix, from userid 99) id 7D0D4184C01; Tue, 16 Sep 2014 19:23:23 -0400 (EDT) Message-Id: <1410909803.3848965.168337885.0D680310@webmail.messagingengine.com> X-Sasl-Enc: 8QUh2k4GTKq59dZSbNgoeXSwOiJAoJ9/KoHP1fj5pfIU 1410909803 From: Mark Felder To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-0646565c Subject: Re: Multipath TCP for FreeBSD v0.4 Date: Tue, 16 Sep 2014 18:23:23 -0500 In-Reply-To: References: <513CB9AF.3090409@swin.edu.au> <53BF8945.3000802@swin.edu.au> <540D0741.6030403@swin.edu.au> <1410907731.1166.13.camel@bruno> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Sep 2014 23:23:26 -0000 On Tue, Sep 16, 2014, at 17:59, Outback Dingo wrote: > > > Im quite curious why you would want to include something thats been found > to be broken and not functional > into mainline.... if it was working sure... im sure we would love it. > However its been months rolling along to get > this patch set out after reporting previous bugs that... well... still > remain. Id suggest to clear up and push > a functional working implementation, might gather more participants. > > This kind of response isn't exactly productive. We need to encourage those who are working on new features and find a way to easily provide them with a wide audience of testers. From owner-freebsd-net@FreeBSD.ORG Tue Sep 16 23:51:30 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 491CCCD0; Tue, 16 Sep 2014 23:51:30 +0000 (UTC) Received: from mail.monochrome.org (e.febed1.client.atlantech.net [209.190.254.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B6D4FF3D; Tue, 16 Sep 2014 23:51:27 +0000 (UTC) Received: from [192.168.1.11] ([192.168.1.11]) by mail.monochrome.org (8.14.4/8.14.4) with ESMTP id s8GNYFgD046583; Tue, 16 Sep 2014 19:34:16 -0400 (EDT) (envelope-from chris@monochrome.org) Date: Tue, 16 Sep 2014 19:27:44 -0400 (EDT) From: Chris Hill To: Brett Glass Subject: Re: jme interface bounces up and down, up and down.... In-Reply-To: <201409161727.LAA25854@mail.lariat.net> Message-ID: References: <201409141629.KAA29705@mail.lariat.net> <20140915060819.GA967@michelle.fasterthan.com> <201409151447.IAA08325@mail.lariat.net> <20140916083749.GA988@michelle.fasterthan.com> <201409161727.LAA25854@mail.lariat.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: pyunyh@gmail.com, questions@freebsd.org, net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Sep 2014 23:51:30 -0000 On Tue, 16 Sep 2014, Brett Glass wrote: > So, what is the best solution? I cannot throw out the machine, and > because I am using a VLAN switch to multiplex the port to three LANs > I do not want to reduce the speed to 100 Mbps. Ideas? The man page mentioned says that if "the link partner enabled the IEEE 802.3az Energy Efficient Ethernet feature, the controller will not be able to establish a 1000baseT link." Maybe disable 802.3az on that port, if you can. Just a thought. > > --Brett Glass > > At 02:37 AM 9/16/2014, Yonghyeon PYUN wrote: > >> On Mon, Sep 15, 2014 at 08:19:37AM -0600, Brett Glass wrote: >> > At 12:08 AM 9/15/2014, Yonghyeon PYUN wrote: >> > >> > >Would you show me the output of dmesg(jme(4) and jmphy(4) only) to >> > >know exact chip revision? >> > >> > Here you are. >> > >> > jme0: port >> > 0xec80-0xecff,0xe800-0xe8ff mem 0xfbffc000-0xfbfff >> > fff irq 18 at device 0.0 on pci1 >> > jme0: MSIX count : 8 >> > jme0: MSI count : 8 >> > jme0: attempting to allocate 1 MSI-X vectors (8 supported) >> > msi: routing MSI-X IRQ 256 to local APIC 0 vector 52 >> > jme0: using IRQ 256 for MSI-X >> > jme0: Using 1 MSIX messages. >> > jme0: PCI device revision : 0x0250 >> > jme0: Chip revision : 0x11 >> ^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> Initially I suspected you might have relatively new JMC25x >> controller but it seems you have early revision of the >> controller(JMC250 A2). Early revision of the controller has >> 1000baseT link establishment issue with 802.3az capable switches. >> The issue is explained in jme(4) man page. The known workaround is >> to manually set 100baseTX media. I recall you mentioned Linux had >> no problems so I wonder Linux was able to establish a 1000baseT >> link. >> In theory, the workaround could be implemented in driver but it >> is layering violation and will have to duplicate lots of work done >> by mii(4). >> >> > jme0: ethernet hardware address not found in EEPROM. >> > jme0: PHY is at address 1. >> > jme0: Read request size : 512 bytes. >> > jme0: TLP payload size : 128 bytes. >> > miibus0: on jme0 >> > jmphy0: PHY 1 on miibus0 >> > jmphy0: OUI 0x00d831, model 0x0021, rev. 1 >> > jmphy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, >> > 100baseTX-FDX, 100baseTX-FDX-flow, >> > 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, >> > 1000baseT-FDX-flow, 1000baseT-FDX >> > -flow-master, auto, auto-flow >> > jme0: bpf attached >> > jme0: Ethernet address: e0:cb:4e:54:23:ac >> > >> > I do not particularly like JMicron chips (their faulty SSD >> > controllers have cost me a lot of time and money), but that's >> >> I don't have experiences with other JMicron products so can't >> comment on SSD. JMC25x may not be world best gigabit ethernet >> controller but I was quite satisfied with its high performance and >> clear documentation and Vendor's support. >> >> > what's on the motherboard of this Asus. So, I need to find a way to >> > make it work. >> > >> > --Brett Glass >> > > > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" > -- Chris Hill chris@monochrome.org ** [ Busy Expunging ] From owner-freebsd-net@FreeBSD.ORG Tue Sep 16 23:54:05 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 80AC6DFE; Tue, 16 Sep 2014 23:54:05 +0000 (UTC) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 3D8BEF5D; Tue, 16 Sep 2014 23:54:04 +0000 (UTC) Received: from Toshi.lariat.net (IDENT:ppp1000.lariat.net@localhost [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id RAA00829; Tue, 16 Sep 2014 17:53:55 -0600 (MDT) Message-Id: <201409162353.RAA00829@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 16 Sep 2014 17:53:51 -0600 To: Chris Hill From: Brett Glass Subject: Re: jme interface bounces up and down, up and down.... In-Reply-To: References: <201409141629.KAA29705@mail.lariat.net> <20140915060819.GA967@michelle.fasterthan.com> <201409151447.IAA08325@mail.lariat.net> <20140916083749.GA988@michelle.fasterthan.com> <201409161727.LAA25854@mail.lariat.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: pyunyh@gmail.com, questions@freebsd.org, net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Sep 2014 23:54:05 -0000 At 05:27 PM 9/16/2014, Chris Hill wrote: >On Tue, 16 Sep 2014, Brett Glass wrote: > >>So, what is the best solution? I cannot throw out the machine, and >>because I am using a VLAN switch to multiplex the port to three LANs >>I do not want to reduce the speed to 100 Mbps. Ideas? > >The man page mentioned says that if "the link partner enabled the >IEEE 802.3az Energy Efficient Ethernet feature, the controller >will not be able to establish a 1000baseT link." Maybe disable >802.3az on that port, if you can. Just a thought. It's a Netgear "green" switch, model GS105E. It has no way to disable 802.3az. --Brett From owner-freebsd-net@FreeBSD.ORG Wed Sep 17 00:58:07 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D10FAC7; Wed, 17 Sep 2014 00:58:07 +0000 (UTC) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EC0A2780; Wed, 17 Sep 2014 00:58:06 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id lj1so922223pab.15 for ; Tue, 16 Sep 2014 17:58:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=zzReK7VHVwHNOHu5zrkDoO8QX19EBS3ObU0BBqmWWAY=; b=ZZ6Cs1WCTY9jBQejLrmu/bXO0X9BW4+/Jsltoqj0pBtHBt+OEWVoWamplQx74hm5Mw D7sn4I7F3p3CnLPIdTbXqf82HfrDUQCkAW1HD8+8s+Fkfm7Sh840hQra1y+N2gwQutd/ RcJ8D3NjVTrIogoVZDR3J6/QyrB3ZnKJcqTO07DSZyWoAvrFRaSG8O8/qR37RIPtUFFZ X+ZtTBE2xVxRFJYHpl7bt9Z3PGfmVXxQiHkyb+gvF926vo+3rv3agOrzw95r9ndtxucY MDcFOBDmcxLZ5q7YAiszAD2nQfA+PUhwIbORz1VXuA3diziEA+uYSmS+eFexobHCoMUJ yMUA== X-Received: by 10.68.132.225 with SMTP id ox1mr54408814pbb.99.1410915486460; Tue, 16 Sep 2014 17:58:06 -0700 (PDT) Received: from pyunyh@gmail.com ([106.247.248.2]) by mx.google.com with ESMTPSA id o4sm15208326pdh.56.2014.09.16.17.58.02 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 16 Sep 2014 17:58:05 -0700 (PDT) From: Yonghyeon PYUN X-Google-Original-From: "Yonghyeon PYUN" Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 17 Sep 2014 09:57:53 +0900 Date: Wed, 17 Sep 2014 09:57:53 +0900 To: Brett Glass Subject: Re: jme interface bounces up and down, up and down.... Message-ID: <20140917005753.GA1102@michelle.fasterthan.com> Reply-To: pyunyh@gmail.com References: <201409141629.KAA29705@mail.lariat.net> <20140915060819.GA967@michelle.fasterthan.com> <201409151447.IAA08325@mail.lariat.net> <20140916083749.GA988@michelle.fasterthan.com> <201409161727.LAA25854@mail.lariat.net> <201409162353.RAA00829@mail.lariat.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201409162353.RAA00829@mail.lariat.net> User-Agent: Mutt/1.4.2.3i Cc: questions@freebsd.org, Chris Hill , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Sep 2014 00:58:07 -0000 On Tue, Sep 16, 2014 at 05:53:51PM -0600, Brett Glass wrote: > At 05:27 PM 9/16/2014, Chris Hill wrote: > > >On Tue, 16 Sep 2014, Brett Glass wrote: > > > >>So, what is the best solution? I cannot throw out the machine, and > >>because I am using a VLAN switch to multiplex the port to three LANs > >>I do not want to reduce the speed to 100 Mbps. Ideas? > > > >The man page mentioned says that if "the link partner enabled the > >IEEE 802.3az Energy Efficient Ethernet feature, the controller > >will not be able to establish a 1000baseT link." Maybe disable > >802.3az on that port, if you can. Just a thought. > > It's a Netgear "green" switch, model GS105E. It has no way to disable > 802.3az. > Then, probably the only available option to establish a link against the switch would be using reduced speed(100Mbps) with ifconfig(8). If you can't reduce the speed due to other reasons I'm afraid there is no way to establish a link at this moment. As I said in previous mail, did you check what resolved speed Linux shows? Also it would be good idea to know whether you're really seeing the PHY hardware issue or not. Directly connect the jme(4) to other box without switch and see whether jme(4) can establish a 1000baseT link. > --Brett > From owner-freebsd-net@FreeBSD.ORG Wed Sep 17 01:06:28 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A9E0BC89; Wed, 17 Sep 2014 01:06:28 +0000 (UTC) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 723A2864; Wed, 17 Sep 2014 01:06:28 +0000 (UTC) Received: by mail-pa0-f41.google.com with SMTP id bj1so938738pad.14 for ; Tue, 16 Sep 2014 18:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=D81u4rSFHYDZa0TKVt+TMME4aaA0hbzPOtmcXJeHaY4=; b=BkX69iMAFoo9L0Q9+/sPyEqLH84w1bVwWOhnCop3aPoAFVvpSgZfTX8Ua6EKSKlv69 ZMAbmeS7h8Km9ukl0D9PcTva396aCg/HBKq055G3srZrkPTouab1fYMndPKMKu7ipyb1 rH7QnCSZ32bPoQsjEME1kmOGeKSCqDUNbapeVf7tO1m6SjCZUvc3Rw1yvEb8CQpKAo93 XywURaqNgOR4ho/+yfI1mKVFlBVb56QlJpCk30QH+fMBdfvag4YLmOdWIsfqOQV+5Q2k +y6hAm70eEvU4mlAjvpFZqt8zlekK/BucbVc19x1NycvprJVvlQDj87Y+IbRZb9ApC5P 2Naw== X-Received: by 10.68.103.4 with SMTP id fs4mr55760656pbb.58.1410915987979; Tue, 16 Sep 2014 18:06:27 -0700 (PDT) Received: from pyunyh@gmail.com ([106.247.248.2]) by mx.google.com with ESMTPSA id fl15sm15162566pdb.92.2014.09.16.18.06.23 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 16 Sep 2014 18:06:26 -0700 (PDT) From: Yonghyeon PYUN X-Google-Original-From: "Yonghyeon PYUN" Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 17 Sep 2014 10:06:14 +0900 Date: Wed, 17 Sep 2014 10:06:14 +0900 To: Jim Thompson Subject: Re: jme interface bounces up and down, up and down.... Message-ID: <20140917010614.GB1102@michelle.fasterthan.com> Reply-To: pyunyh@gmail.com References: <201409141629.KAA29705@mail.lariat.net> <20140915060819.GA967@michelle.fasterthan.com> <201409151447.IAA08325@mail.lariat.net> <20140916083749.GA988@michelle.fasterthan.com> <201409161727.LAA25854@mail.lariat.net> <201409162353.RAA00829@mail.lariat.net> <27534E06-CC9B-4A4D-8A7A-9C68ECB760BC@netgate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <27534E06-CC9B-4A4D-8A7A-9C68ECB760BC@netgate.com> User-Agent: Mutt/1.4.2.3i Cc: Brett Glass , questions@freebsd.org, Chris Hill , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Sep 2014 01:06:28 -0000 On Tue, Sep 16, 2014 at 07:59:18PM -0500, Jim Thompson wrote: > > > On Sep 16, 2014, at 6:53 PM, Brett Glass wrote: > > > > At 05:27 PM 9/16/2014, Chris Hill wrote: > > > >> On Tue, 16 Sep 2014, Brett Glass wrote: > >> > >>> So, what is the best solution? I cannot throw out the machine, and > >>> because I am using a VLAN switch to multiplex the port to three LANs > >>> I do not want to reduce the speed to 100 Mbps. Ideas? > >> > >> The man page mentioned says that if "the link partner enabled the IEEE 802.3az Energy Efficient Ethernet feature, the controller will not be able to establish a 1000baseT link." Maybe disable 802.3az on that port, if you can. Just a thought. > > > > It's a Netgear "green" switch, model GS105E. It has no way to disable 802.3az. > > The linux jmebp-1.0.8.5 driver from the JMicron website > > ftp://driver.jmicron.com.tw/Ethernet/Linux/jmebp-1.0.8.5.tar.bz > > provides a workaround for the issue. It adds the delay_time module parameter, which causes the network card to attempt a fall back to 100 mbps after it cannot connect for several seconds (by default 11). With this, link detection “works”, but the connection is 100Mbps. This is likely the reason the "problem didn't seem to occur with the bundled Linux distro.” > I recall the workaround was suggested by the Vendor but I didn't incorporate it into the driver due to other reasons. The end result is the same if users can manually reduce the speed to 100Mbps. From owner-freebsd-net@FreeBSD.ORG Wed Sep 17 01:14:49 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 623B7F78; Wed, 17 Sep 2014 01:14:49 +0000 (UTC) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 1DB51944; Wed, 17 Sep 2014 01:14:48 +0000 (UTC) Received: from Toshi.lariat.net (IDENT:ppp1000.lariat.net@localhost [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id TAA01358; Tue, 16 Sep 2014 19:14:43 -0600 (MDT) Message-Id: <201409170114.TAA01358@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 16 Sep 2014 19:14:32 -0600 To: pyunyh@gmail.com From: Brett Glass Subject: Re: jme interface bounces up and down, up and down.... In-Reply-To: <20140917005753.GA1102@michelle.fasterthan.com> References: <201409141629.KAA29705@mail.lariat.net> <20140915060819.GA967@michelle.fasterthan.com> <201409151447.IAA08325@mail.lariat.net> <20140916083749.GA988@michelle.fasterthan.com> <201409161727.LAA25854@mail.lariat.net> <201409162353.RAA00829@mail.lariat.net> <20140917005753.GA1102@michelle.fasterthan.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: questions@freebsd.org, Chris Hill , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Sep 2014 01:14:49 -0000 At 06:57 PM 9/16/2014, Yonghyeon PYUN wrote: >Then, probably the only available option to establish a link against >the switch would be using reduced speed(100Mbps) with ifconfig(8). >If you can't reduce the speed due to other reasons I'm afraid there >is no way to establish a link at this moment. As I said in previous >mail, did you check what resolved speed Linux shows? I exorcised Linux from the router and replaced it with a little red daemon. ;-) The system has no CD-ROM, but perhaps I can scrounge a USB CD-ROM drive and a live system CD to boot from. >Also it would be good idea to know whether you're really seeing the >PHY hardware issue or not. Directly connect the jme(4) to other >box without switch and see whether jme(4) can establish a 1000baseT >link. Will have to try this as well. In the future, though, I will be wary of buying ANYTHING with hardware from JMicron in it. --Brett Glass From owner-freebsd-net@FreeBSD.ORG Wed Sep 17 01:54:02 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 801BE8A8; Wed, 17 Sep 2014 01:54:02 +0000 (UTC) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 30393C9B; Wed, 17 Sep 2014 01:54:02 +0000 (UTC) Received: by mail-qc0-f170.google.com with SMTP id l6so1150415qcy.1 for ; Tue, 16 Sep 2014 18:54:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/A9DIEVBM0srS/IOVegkh4LDHB6DoaLwsoEmKIatM30=; b=z6a/ycW22VapKABL4/3x+JPa/dLgcMG214p5CvvNFWbYDFRhmWAFVDWKmOJuXHw0NX hypKmcmn0m5t35PYO1FHKVPsL4itZkl+UC+tBmQ2w6YVWe88W604bFkItQ3QGJQW/2tp bJqb/qqCPhUqb0TDz7vYz0c2f3Tjs2pbpb1Av/7u1410I8bQRJ/RSbZbYUsP2q+XLu4k veXdKpUkrtfyXVRRcI3pli+oZJXl4KRapQPuxUd3rQbqZUU902M7EudLO89XDpctUSTM KvLIF0sDSitazW9eA1si0cSwehVtuANPmmBc9lCuuJdteLiUjzgdi3b7ISMUUd87TrL2 jYmA== MIME-Version: 1.0 X-Received: by 10.224.46.133 with SMTP id j5mr24918068qaf.92.1410918840660; Tue, 16 Sep 2014 18:54:00 -0700 (PDT) Sender: hiren.panchasara@gmail.com Received: by 10.96.170.230 with HTTP; Tue, 16 Sep 2014 18:54:00 -0700 (PDT) In-Reply-To: <1410907731.1166.13.camel@bruno> References: <513CB9AF.3090409@swin.edu.au> <53BF8945.3000802@swin.edu.au> <540D0741.6030403@swin.edu.au> <1410907731.1166.13.camel@bruno> Date: Tue, 16 Sep 2014 18:54:00 -0700 X-Google-Sender-Auth: kUjBuSGX-ey2wSHrgkSvwgjlsEw Message-ID: Subject: Re: Multipath TCP for FreeBSD v0.4 From: hiren panchasara To: Sean Bruno Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@freebsd.org" , Nigel Williams X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Sep 2014 01:54:02 -0000 On Tue, Sep 16, 2014 at 3:48 PM, Sean Bruno wrote: > On Mon, 2014-09-08 at 11:32 +1000, Nigel Williams wrote: >> Hi, >> >> We recently released a new tech report "Design Overview of Multipath TCP >> version 0.4 for FreeBSD-11" [1]. The report provides some details on >> various aspects of the implementation (session management, data-level >> retransmission etc), as of the most recent v0.4 patch [2]. >> >> cheers, >> nigel >> >> [1] http://caia.swin.edu.au/reports/140822A/CAIA-TR-140822A.pdf >> [2] http://caia.swin.edu.au/urp/newtcp/mptcp/tools.html >> > > > Nigel: > > Hi! Are you folks interested in having this patchset incorporated into > the main line of FreeBSD? I'm open to putting up a phabricator review > for you folks at https://reviews.freebsd.org if that's something you > guys want to do? > > sean > Sean, We should not move it to phabricator as contributors without freebsd.org email address (like the patch author himself and patch tester Nils) would not be able to comment on the review as phabricator is still read-only for them. my 2 cents. cheers, Hiren From owner-freebsd-net@FreeBSD.ORG Wed Sep 17 02:33:16 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C2F7298; Wed, 17 Sep 2014 02:33:16 +0000 (UTC) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 844AAA6; Wed, 17 Sep 2014 02:33:15 +0000 (UTC) Received: by mail-la0-f51.google.com with SMTP id gi9so981121lab.10 for ; Tue, 16 Sep 2014 19:33:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2unubnqICz1TExGJkRp0vf9/sG/L4nkBQ1Dks4LcTKA=; b=v0VLrzXkEb6QpQvp1HaNEiNNkP2phFF8aG27EmG+CpBF/lvO3D0+1CVdlRpoTDolMQ TsixtpCdytyl5Th3ENyhtNP4mG/tLQOA+I2m0pn6t1AsZV8sK8NwVIJioDaKf96GTzoS sOQj8DzK/B9mShbB55kvwHkd6yrMYT327p0Kw3QyGnnMzr+kEmH/Rghwf7zUED6ZyXUj Ch6FbJ+3pIwujCtlieeh9A1Kw6esbxprm0l+G382AFXk4MAUJiFJWc2LcxySqSP7ZM7Q Ta4Al7yHacxgZJFf8EgSvE6U/CKja4YDgtgt3bQbfaMhUrEV39Ax+tkw6pznGJxZkLFy fyQw== MIME-Version: 1.0 X-Received: by 10.152.4.9 with SMTP id g9mr41681867lag.14.1410921193330; Tue, 16 Sep 2014 19:33:13 -0700 (PDT) Received: by 10.152.22.195 with HTTP; Tue, 16 Sep 2014 19:33:13 -0700 (PDT) In-Reply-To: <1410909803.3848965.168337885.0D680310@webmail.messagingengine.com> References: <513CB9AF.3090409@swin.edu.au> <53BF8945.3000802@swin.edu.au> <540D0741.6030403@swin.edu.au> <1410907731.1166.13.camel@bruno> <1410909803.3848965.168337885.0D680310@webmail.messagingengine.com> Date: Wed, 17 Sep 2014 12:33:13 +1000 Message-ID: Subject: Re: Multipath TCP for FreeBSD v0.4 From: Outback Dingo To: Mark Felder Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Sep 2014 02:33:16 -0000 On Wed, Sep 17, 2014 at 9:23 AM, Mark Felder wrote: > On Tue, Sep 16, 2014, at 17:59, Outback Dingo wrote: > > > > > Im quite curious why you would want to include something thats been found > > to be broken and not functional > > into mainline.... if it was working sure... im sure we would love it. > > However its been months rolling along to get > > this patch set out after reporting previous bugs that... well... still > > remain. Id suggest to clear up and push > > a functional working implementation, might gather more participants. > > > > > > This kind of response isn't exactly productive. We need to encourage > those who are working on new features and find a way to easily provide > them with a wide audience of testers. > Isnt that exactly what i just stated...?? I just didnt see why.. we would want it in mainline... as part of a branch until merged working would be my thoughts... but yes there are issues, and a much wider audience would help smooth out the feature.... and get more eyes on it. Just as I suggested in my previous email. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Sep 17 02:46:19 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3EFC6506 for ; Wed, 17 Sep 2014 02:46:19 +0000 (UTC) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 00734171 for ; Wed, 17 Sep 2014 02:46:18 +0000 (UTC) Received: by mail-ob0-f176.google.com with SMTP id wo20so592683obc.7 for ; Tue, 16 Sep 2014 19:46:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Cg60ckZuHaI+olUuHxarSEaG6jlXUPV+staFa5rZHgo=; b=iMPu9zidK8q/SfGJRtzdoLnSx+e1UPR9GytPmbfTT+I6csGicD7cjOZC0VotLQ8B8b 6oXkf4CxCxp8f9QuTPn5bZ/Y29Ue+2ArhDn2KaI7dKy5cSIHrKEqeF2nbHidaJbToYFz plV349xXwlmKT+4M2zFpJF9KtCeIVRxoYjbI+Y2+I31ytZqWWQhVh/KxwAFwxNv2OZb2 JiU4ziWQbkC+l7Y4vIqamNp4XJW5orLcKYQJnrxXHkEUAgPWvW64e0sJ+V/GxO+zPirk fTbQ66w5Fy+/mUwZ3gx4eNrxjUk+5E4RzvR7+EhW/xUC/Z5BJ7AaIOIiF7iPJflAlkJ2 DERg== X-Gm-Message-State: ALoCoQmlGjQInqFLMNNqws+tZGq+PATbIjRI5dC510Y64bS2FhJxopohyw05uqRfRO/0QJXMpBby X-Received: by 10.60.92.133 with SMTP id cm5mr22848228oeb.12.1410915560639; Tue, 16 Sep 2014 17:59:20 -0700 (PDT) Received: from ?IPv6:2610:160:11:33:3499:d385:ded3:267c? ([2610:160:11:33:3499:d385:ded3:267c]) by mx.google.com with ESMTPSA id x5sm9776319oec.14.2014.09.16.17.59.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Sep 2014 17:59:19 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1974.6\)) Subject: Re: jme interface bounces up and down, up and down.... From: Jim Thompson In-Reply-To: <201409162353.RAA00829@mail.lariat.net> Date: Tue, 16 Sep 2014 19:59:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <27534E06-CC9B-4A4D-8A7A-9C68ECB760BC@netgate.com> References: <201409141629.KAA29705@mail.lariat.net> <20140915060819.GA967@michelle.fasterthan.com> <201409151447.IAA08325@mail.lariat.net> <20140916083749.GA988@michelle.fasterthan.com> <201409161727.LAA25854@mail.lariat.net> <201409162353.RAA00829@mail.lariat.net> To: Brett Glass X-Mailer: Apple Mail (2.1974.6) Cc: pyunyh@gmail.com, questions@freebsd.org, Chris Hill , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Sep 2014 02:46:19 -0000 > On Sep 16, 2014, at 6:53 PM, Brett Glass wrote: >=20 > At 05:27 PM 9/16/2014, Chris Hill wrote: >=20 >> On Tue, 16 Sep 2014, Brett Glass wrote: >>=20 >>> So, what is the best solution? I cannot throw out the machine, and >>> because I am using a VLAN switch to multiplex the port to three LANs >>> I do not want to reduce the speed to 100 Mbps. Ideas? >>=20 >> The man page mentioned says that if "the link partner enabled the = IEEE 802.3az Energy Efficient Ethernet feature, the controller will not = be able to establish a 1000baseT link." Maybe disable 802.3az on that = port, if you can. Just a thought. >=20 > It's a Netgear "green" switch, model GS105E. It has no way to disable = 802.3az. The linux jmebp-1.0.8.5 driver from the JMicron website=20 ftp://driver.jmicron.com.tw/Ethernet/Linux/jmebp-1.0.8.5.tar.bz provides a workaround for the issue. It adds the delay_time module = parameter, which causes the network card to attempt a fall back to 100 = mbps after it cannot connect for several seconds (by default 11). With = this, link detection =E2=80=9Cworks=E2=80=9D, but the connection is = 100Mbps. This is likely the reason the "problem didn't seem to occur = with the bundled Linux distro.=E2=80=9D Jim From owner-freebsd-net@FreeBSD.ORG Wed Sep 17 02:59:00 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C24656C8; Wed, 17 Sep 2014 02:59:00 +0000 (UTC) Received: from gpo4.cc.swin.edu.au (gpo4.cc.swin.edu.au [136.186.1.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5CBCB25E; Wed, 17 Sep 2014 02:58:59 +0000 (UTC) Received: from [136.186.229.154] (nwilliams-laptop.caia.swin.edu.au [136.186.229.154]) by gpo4.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id s8H2wpbx018182; Wed, 17 Sep 2014 12:58:52 +1000 Message-ID: <5418F8E4.8070606@swin.edu.au> Date: Wed, 17 Sep 2014 12:58:44 +1000 From: Nigel Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: sbruno@freebsd.org Subject: Re: Multipath TCP for FreeBSD v0.4 References: <513CB9AF.3090409@swin.edu.au> <53BF8945.3000802@swin.edu.au> <540D0741.6030403@swin.edu.au> <1410907731.1166.13.camel@bruno> In-Reply-To: <1410907731.1166.13.camel@bruno> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Sep 2014 02:59:00 -0000 On 17/09/14 08:48, Sean Bruno wrote: > On Mon, 2014-09-08 at 11:32 +1000, Nigel Williams wrote: >> Hi, >> >> We recently released a new tech report "Design Overview of Multipath TCP >> version 0.4 for FreeBSD-11" [1]. The report provides some details on >> various aspects of the implementation (session management, data-level >> retransmission etc), as of the most recent v0.4 patch [2]. >> >> cheers, >> nigel >> >> [1] http://caia.swin.edu.au/reports/140822A/CAIA-TR-140822A.pdf >> [2] http://caia.swin.edu.au/urp/newtcp/mptcp/tools.html >> > > > Nigel: > > Hi! Are you folks interested in having this patchset incorporated into > the main line of FreeBSD? I'm open to putting up a phabricator review > for you folks at https://reviews.freebsd.org if that's something you > guys want to do? > > sean > Hi Sean, Thanks, but I think it's too early to put it into phabricator. The patch releases thus far are early test previews for those who are interested and perhaps willing to play around with. So in short, it's not production quality and not ready for committing to mainline. I'll continue to announce these patches on the mailing list for the time being. I'm of course open to feedback/suggestions/questions and will provide documentation with each release. cheers, nigel >> >> On 11/07/14 16:50, Nigel Williams wrote: >>> Hello all, >>> >>> A new v0.4 patch is available at [1]. This release is mostly bug-fixes >>> and improvements to core functionality (establishing/closing >>> connections, retransmissions etc), and also brings the implementation up >>> to a more recent version of FreeBSD-HEAD. >>> >>> The full list of changes and caveats can be found in [2] and [3], but >>> briefly: >>> - Patched against r265307 of FreeBSD-HEAD. This is prior to some recent >>> TCP reassembly memory management changes and the patch will be brought >>> up to a newer revision soon (currently working on integrating those >>> changes). >>> - Added data-level retransmits and subflows can now stall and recover >>> (or timeout) during a connection. >>> - The path management and packet scheduler are still fairly rudimentary, >>> and I haven't yet implemented coupled CC. >>> - The patch is still under heavy development so consider this release >>> code to be of alpha quality. >>> >>> This release ties up work that was partially supported by a gift from >>> The Cisco University Research Program Fund. Future releases will be >>> supported by a grant from the FreeBSD Foundation. >>> >>> P.S. I will be working on the patch full-time again so updates should be >>> a little more frequent from this point onwards. >>> >>> cheers, >>> nigel >>> >>> [1] http://caia.swin.edu.au/urp/newtcp/mptcp/tools.html >>> [2] http://caia.swin.edu.au/urp/newtcp/mptcp/tools/mptcp-changelog-v0.4.txt >>> [3] http://caia.swin.edu.au/urp/newtcp/mptcp/tools/mptcp-readme-v0.4.txt >>> >>> >>> >>> On 11/03/13 03:49, Lawrence Stewart wrote: >>>> Hi all, >>>> >>>> The CAIA MPTCP team is pleased to announce the initial release of our >>>> multipath TCP implementation for FreeBSD 10-CURRENT which is available >>>> from [1]. This release contains wire-related protocol code and a lot of >>>> core stack infrastructure. It is capable of running regular TCP flows >>>> and single or multi-subflow MPTCP flows (with some caveats as documented >>>> in the readme [2]). >>>> >>>> We consider this code to be of alpha quality and plan to release >>>> frequent updates going forward as we continue to flesh out additional >>>> features and fix the rough edges. >>>> >>>> That being said, we welcome everyone to start playing with the code and >>>> provide feedback, bug reports, fixes, praise and/or abuse ;) >>>> >>>> The "Multipath TCP for FreeBSD" project team consists of: >>>> >>>> Nigel Williams: lead R&D engineer >>>> Lawrence Stewart: supporting R&D engineer >>>> Grenville Armitage: principal investigator & overall project lead >>>> >>>> Many thanks go to the Cisco University Research Program Fund at >>>> Community Foundation Silicon Valley for their support of this work. >>>> >>>> Have fun with it! >>>> >>>> Cheers, >>>> Lawrence, Nigel & Grenville >>>> >>>> http://caia.swin.edu.au >>>> >>>> >>>> >>>> [1] http://caia.swin.edu.au/urp/newtcp/mptcp/tools.html >>>> >>>> [2] http://caia.swin.edu.au/urp/newtcp/mptcp/tools/mptcp-readme-v0.1.txt >>>> _______________________________________________ >>>> freebsd-net@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>>> >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Wed Sep 17 08:27:40 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0D54361; Wed, 17 Sep 2014 08:27:40 +0000 (UTC) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8EEB1B8A; Wed, 17 Sep 2014 08:27:40 +0000 (UTC) Received: by mail-qa0-f51.google.com with SMTP id i13so1360095qae.10 for ; Wed, 17 Sep 2014 01:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=vH/dz2Jc5qn9K8OwxTiK7TPf3lonjz0KkWOIQmMaFro=; b=KzvJiwald8RwHzMRZjz5lwCdDwSR/gRLrobEX+VrswyvMY9gy+yE2Tvm7cSfN/lUyI Q/+xPlfVPOF7/chp0yVGDwo4cb/q2UrMpQpGrjims3a3q0Q8KmUSlEuxoJ+kEIqQnqFF 7tLmUaF6+TYi12Xuv+QZeMb3CYpdH0YAKpo0tnhKQI1nF8gYQo5V8fXtqinrWQB262Mv KZvJpPpDrapaKGvWdHyTdIjFnkncG6T54+eKJlthR2lcIgBQ/jh/MFOp9PZyhG3sJ4HU 060MFPPi/RHzsP+iv2LTKCioSnZOFo61eLSDAT4T1ScfpJKOt9KHx3d5qNszIF5e8v1e zm6g== MIME-Version: 1.0 X-Received: by 10.229.84.133 with SMTP id j5mr53811723qcl.14.1410942459472; Wed, 17 Sep 2014 01:27:39 -0700 (PDT) Received: by 10.140.104.241 with HTTP; Wed, 17 Sep 2014 01:27:39 -0700 (PDT) Date: Wed, 17 Sep 2014 10:27:39 +0200 Message-ID: Subject: [RFC] Patch to add Software/Generic Segmentation Offload (GSO) support in FreeBSD From: Stefano Garzarella To: freebsd-current , "freebsd-net@freebsd.org" , gnn@neville-neil.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Luigi Rizzo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Sep 2014 08:27:41 -0000 Hi all, I have recently worked, during my master=E2=80=99s thesis with the supervis= ion of Prof. Luigi Rizzo, on a project to add GSO (Generic Segmentation Offload) support in FreeBSD. I will present this project at EuroBSDcon 2014, in Sofia (Bulgaria) on September 28, 2014. Following is a brief description of our project: The use of large frames makes network communication much less demanding for the CPU. Yet, backward compatibility and slow links requires the use of 1500 byte or smaller frames. Modern NICs with hardware TCP segmentation offloading (TSO) address this problem. However, a generic software version (GSO) provided by the OS has reason to exist, for use on paths with no suitable hardware, such as between virtual machines or with older or buggy NICs. Much of the advantage of TSO comes from crossing the network stack only once per (large) segment instead of once per 1500-byte frame. GSO does the same both for segmentation (TCP) and fragmentation (UDP) by doing these operations as late as possible. Ideally, this could be done within the device driver, but that would require modifications to all drivers. A more convenient, similarly effective approach is to segment just before the packet is passed to the driver (in ether_output()). Our preliminary implementation supports TCP and UDP on IPv4/IPv6; it only intercepts packets large than the MTU (others are left unchanged), and only when GSO is marked as enabled for the interface. Segments larger than the MTU are not split in tcp_output(), udp_output(), or ip_output(), but marked with a flag (contained in m_pkthdr.csum_flags), which is processed by ether_output() just before calling the device driver. ether_output(), through gso_dispatch(), splits the large frame as needed, creating headers and possibly doing checksums if not supported by the hardware. In experiments agains an LRO-enabled receiver (otherwise TSO/GSO are ineffective) we have seen the following performance, taken at different clock speeds (because at top speeds the 10G link becomes the bottleneck): Testing enviroment (all with Intel 10Gbit NIC) Sender: FreeBSD 11-CURRENT - CPU i7-870 at 2.93 GHz + Turboboost Receiver: Linux 3.12.8 - CPU i7-3770K at 3.50GHz + Turboboost Benchmark tool: netperf 2.6.0 --- TCP/IPv4 packets (checksum offloading enabled) --- Freq. TSO GSO none Speedup [GHz] [Gbps] [Gbps] [Gbps] GSO-none 2.93 9347 9298 8308 12 % 2.53 9266 9401 6771 39 % 2.00 9408 9294 5499 69 % 1.46 9408 8087 4075 98 % 1.05 9408 5673 2884 97 % 0.45 6760 2206 1244 77 % --- TCP/IPv6 packets (checksum offloading enabled) --- Freq. TSO GSO none Speedup [GHz] [Gbps] [Gbps] [Gbps] GSO-none 2.93 7530 6939 4966 40 % 2.53 5133 7145 4008 78 % 2.00 5965 6331 3152 101 % 1.46 5565 5180 2348 121 % 1.05 8501 3607 1732 108 % 0.45 3665 1505 651 131 % --- UDP/IPv4 packets (9K) --- Freq. GSO none Speedup [GHz] [Gbps] [Gbps] GSO-none 2.93 9440 8084 17 % 2.53 7772 6649 17 % 2.00 6336 5338 19 % 1.46 4748 4014 18 % 1.05 3359 2831 19 % 0.45 1312 1120 17 % --- UDP/IPv6 packets (9K) --- Freq. GSO none Speedup [GHz] [Gbps] [Gbps] GSO-none 2.93 7281 6197 18 % 2.53 5953 5020 19 % 2.00 4804 4048 19 % 1.46 3582 3004 19 % 1.05 2512 2092 20 % 0.45 998 826 21 % We tried to change as little as possible the network stack to add GSO support. To avoid changing API/ABI, we temporarily used spare fields in struct tcpcb (TCP Control Block) and struct ifnet to store some information related to GSO (enabled, max burst size, etc.). The code that performs the segmentation/fragmentation is contained in the file gso.[h|c] in sys/net. We used 4 bit in m_pkthdr.csum_flags (CSUM_GSO_MASK) to encode the packet type (TCP/IPv4, TCP/IPv6, etc) to prevent access to the TCP/IP/Ethernet headers of each packet. In ether_output_frame(), if the packet requires the GSO ((m->m_pkthdr.csum_flags & CSUM_GSO_MASK) !=3D 0), it is segmented or fragmented, and then they are sent to the device driver. At https://github.com/stefano-garzarella/freebsd-gso you can find the kernel patches for FreeBSD-current, FreeBSD 10-stable, FreeBSD 9-stable, a simple application (gso-stats.c) that prints the GSO statistics and picobsd images with GSO support. At https://github.com/stefano-garzarella/freebsd-gso-src you can get the FreeBSD source with GSO patch (various branch for FreeBSD current, 10-stable, 9-stable). Any feedbacks, comments, questions are welcome=E2=80=8B. Thank you very much, Stefano Garzarella ---------------------------------------------------------------------------= --------------------------------- How to use GSO: - Apply the right kernel patch. - To compile the GSO support add =E2=80=98 options GSO ' to your kernel con= fig file and rebuild a kernel. - To manage the GSO parameters there are some sysctls: - net.inet.tcp.gso - GSO enable on TCP communications (!=3D0) - net.inet.udp.gso - GSO enable on UDP communications (!=3D0) - for each interface: - net.gso.dev."ifname=E2=80=9D.max_burst - GSO burst length limit [default: IP_MAXPACKET=3D65535] - net.gso.dev."ifname=E2=80=9D.enable_gso - GSO enable on =E2=80= =9Cifname=E2=80=9D interface (!=3D0) - To show statistics: - make sure that the GSO_STATS macro is defined in sys/net/gso.h - use the simple gso-stats.c application to access the sysctl net.gso.stats that contains the address of the gsostats structure (defined in gso.h) which records the statistics. (compile with -I/path/to/kernel/src/patched/) ---------------------------------------------------------------------------= --------------------------------- --=20 *Stefano Garzarella* stefano.garzarella@gmail.com From owner-freebsd-net@FreeBSD.ORG Wed Sep 17 11:04:05 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6AA2BD01; Wed, 17 Sep 2014 11:04:05 +0000 (UTC) Received: from cu01176b.smtpx.saremail.com (cu01176b.smtpx.saremail.com [195.16.151.151]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 26D02D6C; Wed, 17 Sep 2014 11:04:04 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop04.sare.net (Postfix) with ESMTPSA id DB04A9DC717; Wed, 17 Sep 2014 13:04:00 +0200 (CEST) From: Borja Marcos Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Oce driver fixes Date: Wed, 17 Sep 2014 13:03:59 +0200 Message-Id: To: Stable Stable , freebsd-net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Sep 2014 11:04:05 -0000 Hello, Back in July there was a discussion on -current about serious problems = with the "oce" driver for Emulex 10 GbE cards. Stefano Garzarella supplied a patch that fixed the problems (at least = for me). Is this patch planned to go to -current and -stable, ideally = before 10.1? At least for me, these Emulex cards were virtually unusable until I = applied Stefano's patch. And from his description of the problem (lack = of proper locking) the errors are serious indeed. This is the link to the discussion. I assumed that someone would push = this so that the fixes would be applied to -stable (and hence the = upcoming 10.1) as well, but it hasn't happened. Sorry for my belated = heads up. The discussion is here: http://lists.freebsd.org/pipermail/freebsd-current/2014-July/050972.html and Stefano's message explaining what he saw is this: http://lists.freebsd.org/pipermail/freebsd-current/2014-July/051193.html Thanks! Borja. From owner-freebsd-net@FreeBSD.ORG Wed Sep 17 15:17:32 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04E9D91C for ; Wed, 17 Sep 2014 15:17:32 +0000 (UTC) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 69B84B6F for ; Wed, 17 Sep 2014 15:17:31 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id s18so2106931lam.0 for ; Wed, 17 Sep 2014 08:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=nxXpbaQtgO2vfBhEUse9OZGFrmgJJiHGnths0AvomzU=; b=Fct8qUmCqKVx398vi35+7zBQNA/3XKfrXjsZgcKvJwyUSi/aqkfCP8ogHkcw/5ja7P udcxoBxTLVeWTLwRbeEKBuNDOtig0G08fpWCH+/l96jvy54j7yuPRChCc0qxErHZ5/rH GkLkK+XQIMx4JYzafsyxPvSPZcT01nU4nFqlTCYe9B7Ae+1Z68VuACTK0VCa37e6OpZF 3scQaqgwz+H4Q4SA2UmY1BntleBQ8FUKHzaLyQMIaYThP5MFo6Vksy28oFBqx1blp4lD iV3qsaVig+x693bu0LqR/v06ZCRPx6LUG1VCtCWEBvuavSepZAP5VD47DyueKb5R5kSG gjJg== MIME-Version: 1.0 X-Received: by 10.112.129.228 with SMTP id nz4mr42588884lbb.9.1410967048672; Wed, 17 Sep 2014 08:17:28 -0700 (PDT) Received: by 10.25.15.83 with HTTP; Wed, 17 Sep 2014 08:17:28 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Sep 2014 08:17:28 -0700 Message-ID: Subject: Re: ixgbe IXGBE_LEGACY_TX breaks build (patch/fix included) From: Nick Rogers Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Sep 2014 15:17:32 -0000 On Tue, Aug 26, 2014 at 4:16 PM, Nick Rogers wrote: > > > > On Tue, Aug 26, 2014 at 3:36 PM, Adrian Chadd wrote: > >> Hi, >> >> I'm not surprised the legacy tx path has bitrotted there. >> >> Please file a bug with this - https://bugs.freebsd.org/submit/ - and >> then just keep poking people until it's done. >> > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193053 > Poke. Looking for some triage? > >> Thank! >> >> >> -a >> >> >> On 26 August 2014 13:42, Nick Rogers wrote: >> > Hello, >> > >> > I am trying to get the ixgbe driver + PF/ALTQ working under stable/9. >> > Initially, loading a PF rulset with ALTQ enabled fails on an ix >> interface, >> > reporting "ix0: driver does not support altq". This is similar to the >> > behavior over the last few years when dealing with the igb driver. >> However, >> > I have been using ALTQ + igb with great success by defining >> IGB_LEGACY_TX >> > in the e1000/igb driver code. I noticed that ixgbe has a similar define >> > IXGBE_LEGACY_TX to enable the legacy, non-multiqueue transmit behavior, >> > that also "enables" ALTQ support. >> > >> > After adding the IXGBE_LEGACY_TX define to ixgbe source, building the >> > driver fails with the following compile errors: >> > >> > /usr/src/sys/dev/ixgbe/ixgbe.c: In function 'ixgbe_msix_que': >> > /usr/src/sys/dev/ixgbe/ixgbe.c:1529: error: invalid type argument of >> '->' >> > (have 'struct ifaltq') >> > /usr/src/sys/dev/ixgbe/ixgbe.c:1529: error: invalid type argument of >> '->' >> > (have 'struct ifaltq') >> > /usr/src/sys/dev/ixgbe/ixgbe.c: In function 'ixgbe_local_timer': >> > /usr/src/sys/dev/ixgbe/ixgbe.c:2077: error: 'struct tx_ring' has no >> member >> > named 'txq_task' >> > /usr/src/sys/dev/ixgbe/ixgbe.c: In function >> 'ixgbe_free_transmit_buffers': >> > /usr/src/sys/dev/ixgbe/ixgbe.c:3255: error: 'struct tx_ring' has no >> member >> > named 'br' >> > /usr/src/sys/dev/ixgbe/ixgbe.c:3256: error: 'struct tx_ring' has no >> member >> > named 'br' >> > >> > So it seems that the IXGBE_LEGACY_TX path no longer compiles >> successfully, >> > and perhaps never did? Using e1000 as a reference, fixing the pointer >> > error, and looking at previous revisions of ixgbe.c, I was able to come >> up >> > with the following patch that got the driver to compile while having >> > IXGBE_LEGACY_TX defined. Note that the following svn diff is against >> HEAD, >> > which as far as I can tell contains the same broken IXGBE_LEGACY_TX >> path as >> > stable/9 and stable/10. >> > >> > Index: ixgbe.c >> > =================================================================== >> > --- ixgbe.c (revision 270665) >> > +++ ixgbe.c (working copy) >> > @@ -1543,7 +1543,7 @@ >> > IXGBE_TX_LOCK(txr); >> > ixgbe_txeof(txr); >> > #ifdef IXGBE_LEGACY_TX >> > - if (!IFQ_DRV_IS_EMPTY(ifp->if_snd)) >> > + if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) >> > ixgbe_start_locked(txr, ifp); >> > #else >> > if (!drbr_empty(ifp, txr->br)) >> > @@ -2091,7 +2091,11 @@ >> > (paused == 0)) >> > ++hung; >> > else if (txr->queue_status == IXGBE_QUEUE_WORKING) >> > +#ifndef IXGBE_LEGACY_TX >> > taskqueue_enqueue(que->tq, &txr->txq_task); >> > +#else >> > + taskqueue_enqueue(que->tq, &que->que_task); >> > +#endif >> > } >> > /* Only truely watchdog if all queues show hung */ >> > if (hung == adapter->num_queues) >> > @@ -3327,10 +3331,6 @@ >> > tx_buffer->map = NULL; >> > } >> > } >> > -#ifdef IXGBE_LEGACY_TX >> > - if (txr->br != NULL) >> > - buf_ring_free(txr->br, M_DEVBUF); >> > -#endif >> > if (txr->tx_buffers != NULL) { >> > free(txr->tx_buffers, M_DEVBUF); >> > txr->tx_buffers = NULL; >> > =================================================================== >> > >> > Using a stable/9 kernel with the above patch allowed me to load my PF >> > ruleset on a machine with an ixgbe interface and ALTQ enabled. i.e. I no >> > longer received the "driver does not support altq error". Queueing on >> the >> > ix interface now appears to work as it should. >> > >> > I am hoping someone can help verify my work and perhaps audit and >> correct >> > the IXGBE_LEGACY_TX path currently in the svn tree. >> > >> > Also, FWIW, here is relevant pciconf output for the ixbge card. >> > >> > ix0@pci0:1:0:0: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 >> > hdr=0x00 >> > vendor = 'Intel Corporation' >> > device = '82599EB 10-Gigabit SFI/SFP+ Network Connection' >> > class = network >> > subclass = ethernet >> > cap 01[40] = powerspec 3 supports D0 D3 current D0 >> > cap 05[50] = MSI supports 1 message, 64 bit, vector masks >> > cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled >> > cap 10[a0] = PCI-Express 2 endpoint max data 128(512) link x8(x8) >> > ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected >> > ecap 0003[140] = Serial 1 0023faffff300715 >> > ecap 000e[150] = unknown 1 >> > ecap 0010[160] = unknown 1 >> > ix1@pci0:1:0:1: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 >> > hdr=0x00 >> > vendor = 'Intel Corporation' >> > device = '82599EB 10-Gigabit SFI/SFP+ Network Connection' >> > class = network >> > subclass = ethernet >> > cap 01[40] = powerspec 3 supports D0 D3 current D0 >> > cap 05[50] = MSI supports 1 message, 64 bit, vector masks >> > cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled >> > cap 10[a0] = PCI-Express 2 endpoint max data 128(512) link x8(x8) >> > ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected >> > ecap 0003[140] = Serial 1 0023faffff300715 >> > ecap 000e[150] = unknown 1 >> > ecap 0010[160] = unknown 1 >> > >> > Thanks! >> > >> > -Nick >> > _______________________________________________ >> > freebsd-net@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-net >> > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > From owner-freebsd-net@FreeBSD.ORG Wed Sep 17 15:33:39 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7E2ACD0; Wed, 17 Sep 2014 15:33:39 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 780C5D32; Wed, 17 Sep 2014 15:33:39 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 143891) id C47D14E02; Wed, 17 Sep 2014 17:33:25 +0200 (SAST) Date: Wed, 17 Sep 2014 17:33:25 +0200 From: John Hay To: freebsd-net@freebsd.org Subject: ping6 -c broken after svn r269180 Message-ID: <20140917153325.GA69597@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Cc: tjmao@tjmao.net, delphij@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Sep 2014 15:33:39 -0000 Hi Guys, After svn r269180 and MFC to 10-stable r269800 and also to 9- and 8-, ping6 -c have an unintended behaviour. Previously if you did "ping6 -c 3 ", it would send the 3 packets, report the outcome and exit. Now, if the machine to be pinged, does not answer, ping6 will just sit and wait until you press ^C. The current behaviour badly break (hang) scripts that expect the old behaviour. Can these commits be reverted and the original bug be revisited, if need be? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=151023 Regards John -- John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za On Mon, Aug 11, 2014 at 06:54:07AM +0000, Xin LI wrote: > Author: delphij > Date: Mon Aug 11 06:54:07 2014 > New Revision: 269800 > URL: http://svnweb.freebsd.org/changeset/base/269800 > > Log: > MFC r269180: > > When interval is set to very small value with limited amount of packets, > ping6(8) would quit before the remote side gets a chance to respond. > > Solve this by resetting the itimer when we have reached the maximum packet > number have reached, but let the other handling to continue. > > PR: bin/151023 > Submitted by: tjmao at tjmao.net > > Modified: > stable/10/sbin/ping6/ping6.c > Directory Properties: > stable/10/ (props changed) > > Modified: stable/10/sbin/ping6/ping6.c > ============================================================================== > --- stable/10/sbin/ping6/ping6.c Mon Aug 11 03:04:16 2014 (r269799) > +++ stable/10/sbin/ping6/ping6.c Mon Aug 11 06:54:07 2014 (r269800) > @@ -1090,8 +1090,14 @@ main(int argc, char *argv[]) > /* signal handling */ > if (seenalrm) { > /* last packet sent, timeout reached? */ > - if (npackets && ntransmitted >= npackets) > - break; > + if (npackets && ntransmitted >= npackets) { > + struct timeval zerotime = {0, 0}; > + itimer.it_value = zerotime; > + itimer.it_interval = zerotime; > + (void)setitimer(ITIMER_REAL, &itimer, NULL); > + seenalrm = 0; /* clear flag */ > + continue; > + } > retransmit(); > seenalrm = 0; > continue; From owner-freebsd-net@FreeBSD.ORG Wed Sep 17 15:44:23 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5EEAB1F8 for ; Wed, 17 Sep 2014 15:44:23 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3D8F5E47 for ; Wed, 17 Sep 2014 15:44:23 +0000 (UTC) Received: from [192.168.200.200] (unknown [50.136.155.142]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 4EB4519413C; Wed, 17 Sep 2014 15:44:22 +0000 (UTC) Subject: Re: Multipath TCP for FreeBSD v0.4 From: Sean Bruno Reply-To: sbruno@freebsd.org To: Nigel Williams In-Reply-To: <5418F8E4.8070606@swin.edu.au> References: <513CB9AF.3090409@swin.edu.au> <53BF8945.3000802@swin.edu.au> <540D0741.6030403@swin.edu.au> <1410907731.1166.13.camel@bruno> <5418F8E4.8070606@swin.edu.au> Content-Type: text/plain; charset="us-ascii" Date: Wed, 17 Sep 2014 08:44:21 -0700 Message-ID: <1410968661.1166.32.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Sep 2014 15:44:23 -0000 On Wed, 2014-09-17 at 12:58 +1000, Nigel Williams wrote: > On 17/09/14 08:48, Sean Bruno wrote: > > On Mon, 2014-09-08 at 11:32 +1000, Nigel Williams wrote: > >> Hi, > >> > >> We recently released a new tech report "Design Overview of > Multipath TCP > >> version 0.4 for FreeBSD-11" [1]. The report provides some details > on > >> various aspects of the implementation (session management, > data-level > >> retransmission etc), as of the most recent v0.4 patch [2]. > >> > >> cheers, > >> nigel > >> > >> [1] http://caia.swin.edu.au/reports/140822A/CAIA-TR-140822A.pdf > >> [2] http://caia.swin.edu.au/urp/newtcp/mptcp/tools.html > >> > > > > > > Nigel: > > > > Hi! Are you folks interested in having this patchset incorporated > into > > the main line of FreeBSD? I'm open to putting up a phabricator > review > > for you folks at https://reviews.freebsd.org if that's something you > > guys want to do? > > > > sean > > > > Hi Sean, > > Thanks, but I think it's too early to put it into phabricator. The > patch > releases thus far are early test previews for those who are > interested > and perhaps willing to play around with. So in short, it's not > production quality and not ready for committing to mainline. > > I'll continue to announce these patches on the mailing list for the > time > being. I'm of course open to feedback/suggestions/questions and will > provide documentation with each release. > > cheers, > nigel > > Noted. Thank you for the feedback. I hope, that someday, https://reviews.freebsd.org becomes more of a code review tool for users than it is being used for today. sean From owner-freebsd-net@FreeBSD.ORG Wed Sep 17 17:27:54 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4BEF81AE; Wed, 17 Sep 2014 17:27:54 +0000 (UTC) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A63FCC5E; Wed, 17 Sep 2014 17:27:53 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id q58so1808179wes.7 for ; Wed, 17 Sep 2014 10:27:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=CqkJj04bKoVkqwNWE/3LPFsCq/iSjXSMkcLUraTOhlY=; b=uK154Uu4VorKdEC2Ewh4+/e97L0+yq3wJFnmXpoEltE6aI/VDQUKCmJajAy7hADKZn EtvxT05XNMMrszslqYZzlpvMWxv7HGWPvRSwNgN3sZaLXYL81o0wsueUxyqcGd+EyUXk owjGsXdNDpeswTR4oshyhwpwZMKoMQDRUXN73POKvbLhFkP4APQ8JiWHGn8xpICBtIRD 05a8SIrBPUMgxFdD0lvackzyxT+HVezXx9s5BeDMx4+BzpGC+j1GLKKhJw0lTnDBa7xK ozMDfBYIylNnA1EiBKAGYGnXxdEnX8aA4TuN0pBvDhD4Kv2oOwD/ZEYGVE5OqYWWDgS3 QGdw== MIME-Version: 1.0 X-Received: by 10.180.107.100 with SMTP id hb4mr6868225wib.59.1410974871879; Wed, 17 Sep 2014 10:27:51 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.199 with HTTP; Wed, 17 Sep 2014 10:27:51 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Sep 2014 10:27:51 -0700 X-Google-Sender-Auth: FjTR5MgoHUE-TJW01cfMvbtYY3Y Message-ID: Subject: Re: [RFC] Patch to add Software/Generic Segmentation Offload (GSO) support in FreeBSD From: Adrian Chadd To: Stefano Garzarella Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , freebsd-current , Luigi Rizzo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Sep 2014 17:27:54 -0000 Hi! Cool! How many flows were you testing with? Just one or two? It's for outbound, so it's not _as_ big a deal as it is for inbound, but it'd still be nice to know. -a On 17 September 2014 01:27, Stefano Garzarella wrote: > Hi all, > I have recently worked, during my master=E2=80=99s thesis with the superv= ision > of Prof. Luigi Rizzo, on a project to add GSO (Generic Segmentation > Offload) support in FreeBSD. I will present this project at EuroBSDcon > 2014, in Sofia (Bulgaria) on September 28, 2014. > > Following is a brief description of our project: > > The use of large frames makes network communication much less > demanding for the CPU. Yet, backward compatibility and slow links > requires the use of 1500 byte or smaller frames. Modern NICs with > hardware TCP segmentation offloading (TSO) address this problem. > However, a generic software version (GSO) provided by the OS has > reason to exist, for use on paths with no suitable hardware, such > as between virtual machines or with older or buggy NICs. > > Much of the advantage of TSO comes from crossing the network stack only > once per (large) segment instead of once per 1500-byte frame. > GSO does the same both for segmentation (TCP) and fragmentation (UDP) > by doing these operations as late as possible. Ideally, this could be don= e > within the device driver, but that would require modifications to all > drivers. > A more convenient, similarly effective approach is to segment > just before the packet is passed to the driver (in ether_output()). > > Our preliminary implementation supports TCP and UDP on IPv4/IPv6; > it only intercepts packets large than the MTU (others are left unchanged)= , > and only when GSO is marked as enabled for the interface. > > Segments larger than the MTU are not split in tcp_output(), > udp_output(), or ip_output(), but marked with a flag (contained in > m_pkthdr.csum_flags), which is processed by ether_output() just > before calling the device driver. > > ether_output(), through gso_dispatch(), splits the large frame as needed, > creating headers and possibly doing checksums if not supported by > the hardware. > > In experiments agains an LRO-enabled receiver (otherwise TSO/GSO > are ineffective) we have seen the following performance, > taken at different clock speeds (because at top speeds the > 10G link becomes the bottleneck): > > > Testing enviroment (all with Intel 10Gbit NIC) > Sender: FreeBSD 11-CURRENT - CPU i7-870 at 2.93 GHz + Turboboost > Receiver: Linux 3.12.8 - CPU i7-3770K at 3.50GHz + Turboboost > Benchmark tool: netperf 2.6.0 > > --- TCP/IPv4 packets (checksum offloading enabled) --- > Freq. TSO GSO none Speedup > [GHz] [Gbps] [Gbps] [Gbps] GSO-none > 2.93 9347 9298 8308 12 % > 2.53 9266 9401 6771 39 % > 2.00 9408 9294 5499 69 % > 1.46 9408 8087 4075 98 % > 1.05 9408 5673 2884 97 % > 0.45 6760 2206 1244 77 % > > > --- TCP/IPv6 packets (checksum offloading enabled) --- > Freq. TSO GSO none Speedup > [GHz] [Gbps] [Gbps] [Gbps] GSO-none > 2.93 7530 6939 4966 40 % > 2.53 5133 7145 4008 78 % > 2.00 5965 6331 3152 101 % > 1.46 5565 5180 2348 121 % > 1.05 8501 3607 1732 108 % > 0.45 3665 1505 651 131 % > > > --- UDP/IPv4 packets (9K) --- > Freq. GSO none Speedup > [GHz] [Gbps] [Gbps] GSO-none > 2.93 9440 8084 17 % > 2.53 7772 6649 17 % > 2.00 6336 5338 19 % > 1.46 4748 4014 18 % > 1.05 3359 2831 19 % > 0.45 1312 1120 17 % > > > --- UDP/IPv6 packets (9K) --- > Freq. GSO none Speedup > [GHz] [Gbps] [Gbps] GSO-none > 2.93 7281 6197 18 % > 2.53 5953 5020 19 % > 2.00 4804 4048 19 % > 1.46 3582 3004 19 % > 1.05 2512 2092 20 % > 0.45 998 826 21 % > > We tried to change as little as possible the network stack to add > GSO support. To avoid changing API/ABI, we temporarily used spare > fields in struct tcpcb (TCP Control Block) and struct ifnet to store > some information related to GSO (enabled, max burst size, etc.). > The code that performs the segmentation/fragmentation is contained > in the file gso.[h|c] in sys/net. We used 4 bit in m_pkthdr.csum_flags > (CSUM_GSO_MASK) to encode the packet type (TCP/IPv4, TCP/IPv6, etc) > to prevent access to the TCP/IP/Ethernet headers of each packet. > In ether_output_frame(), if the packet requires the GSO > ((m->m_pkthdr.csum_flags & CSUM_GSO_MASK) !=3D 0), it is segmented > or fragmented, and then they are sent to the device driver. > > At https://github.com/stefano-garzarella/freebsd-gso > you can find the kernel patches for FreeBSD-current, FreeBSD > 10-stable, FreeBSD 9-stable, a simple application (gso-stats.c) > that prints the GSO statistics and picobsd images with GSO support. > > At https://github.com/stefano-garzarella/freebsd-gso-src > you can get the FreeBSD source with GSO patch (various branch for > FreeBSD current, 10-stable, 9-stable). > > Any feedbacks, comments, questions are welcome. > > Thank you very much, > Stefano Garzarella > > -------------------------------------------------------------------------= ----------------------------------- > How to use GSO: > > - Apply the right kernel patch. > > - To compile the GSO support add =E2=80=98 options GSO ' to your kernel c= onfig file > and > rebuild a kernel. > > - To manage the GSO parameters there are some sysctls: > - net.inet.tcp.gso - GSO enable on TCP communications (!=3D0) > - net.inet.udp.gso - GSO enable on UDP communications (!=3D0) > > - for each interface: > - net.gso.dev."ifname=E2=80=9D.max_burst - GSO burst length lim= it > [default: IP_MAXPACKET=3D65535] > - net.gso.dev."ifname=E2=80=9D.enable_gso - GSO enable on =E2= =80=9Cifname=E2=80=9D > interface (!=3D0) > > - To show statistics: > - make sure that the GSO_STATS macro is defined in sys/net/gso.h > - use the simple gso-stats.c application to access the sysctl > net.gso.stats > that contains the address of the gsostats structure (defined in > gso.h) > which records the statistics. (compile with > -I/path/to/kernel/src/patched/) > -------------------------------------------------------------------------= ----------------------------------- > > -- > *Stefano Garzarella* > stefano.garzarella@gmail.com > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-net@FreeBSD.ORG Wed Sep 17 18:18:45 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C1E11A70; Wed, 17 Sep 2014 18:18:45 +0000 (UTC) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5BA4D2E3; Wed, 17 Sep 2014 18:18:45 +0000 (UTC) Received: by mail-qg0-f51.google.com with SMTP id e89so2475738qgf.24 for ; Wed, 17 Sep 2014 11:18:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tW86HSWxNkMFHRlYJxWkTNooCln+St7+VoNWM8Difu0=; b=nKxisU3PEeTUB01C1+BtJ9upkKS+cNHMVpdKpAkNIRoyAxL2zMWWyOppfb9rlyNsC8 pEmqzhCijGfMbdKVbUI5B3G1uJ9C2b7nDvMci/SREh+IeIP5fUE36TrZJcyGIJkzxAhR Q7QW+fL+WApAUWivnqJIQCBAG4KhICceH/Xr9x1A1sKIq6a/+BTvYW6gA8H61WhiMS6p qk2+JO3Gv0MCjNpLHekw4E/ojGKqduZKFIaw7FZ6iRh02qDLXpHyeFH4Bjdoliq3/h4l fdyVH6g0z2R1TPKy4oAJk3DOCDtHhkKL64dc3RQ/kFDaZAaTGv74OzFfx261blKjZAXM /R0g== MIME-Version: 1.0 X-Received: by 10.224.86.5 with SMTP id q5mr60394777qal.36.1410977924449; Wed, 17 Sep 2014 11:18:44 -0700 (PDT) Received: by 10.140.104.241 with HTTP; Wed, 17 Sep 2014 11:18:44 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Sep 2014 20:18:44 +0200 Message-ID: Subject: Re: [RFC] Patch to add Software/Generic Segmentation Offload (GSO) support in FreeBSD From: Stefano Garzarella To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , freebsd-current , Luigi Rizzo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Sep 2014 18:18:45 -0000 Hi Adrian, the results that I sent, regard just one flow, but I can try with two simultaneous flows and I'll send you the results. Thanks, Stefano 2014-09-17 19:27 GMT+02:00 Adrian Chadd : > Hi! > > Cool! > > How many flows were you testing with? Just one or two? > > It's for outbound, so it's not _as_ big a deal as it is for inbound, > but it'd still be nice to know. > > > -a > > > On 17 September 2014 01:27, Stefano Garzarella > wrote: > > Hi all, > > I have recently worked, during my master=E2=80=99s thesis with the supe= rvision > > of Prof. Luigi Rizzo, on a project to add GSO (Generic Segmentation > > Offload) support in FreeBSD. I will present this project at EuroBSDcon > > 2014, in Sofia (Bulgaria) on September 28, 2014. > > > > Following is a brief description of our project: > > > > The use of large frames makes network communication much less > > demanding for the CPU. Yet, backward compatibility and slow links > > requires the use of 1500 byte or smaller frames. Modern NICs with > > hardware TCP segmentation offloading (TSO) address this problem. > > However, a generic software version (GSO) provided by the OS has > > reason to exist, for use on paths with no suitable hardware, such > > as between virtual machines or with older or buggy NICs. > > > > Much of the advantage of TSO comes from crossing the network stack only > > once per (large) segment instead of once per 1500-byte frame. > > GSO does the same both for segmentation (TCP) and fragmentation (UDP) > > by doing these operations as late as possible. Ideally, this could be > done > > within the device driver, but that would require modifications to all > > drivers. > > A more convenient, similarly effective approach is to segment > > just before the packet is passed to the driver (in ether_output()). > > > > Our preliminary implementation supports TCP and UDP on IPv4/IPv6; > > it only intercepts packets large than the MTU (others are left > unchanged), > > and only when GSO is marked as enabled for the interface. > > > > Segments larger than the MTU are not split in tcp_output(), > > udp_output(), or ip_output(), but marked with a flag (contained in > > m_pkthdr.csum_flags), which is processed by ether_output() just > > before calling the device driver. > > > > ether_output(), through gso_dispatch(), splits the large frame as neede= d, > > creating headers and possibly doing checksums if not supported by > > the hardware. > > > > In experiments agains an LRO-enabled receiver (otherwise TSO/GSO > > are ineffective) we have seen the following performance, > > taken at different clock speeds (because at top speeds the > > 10G link becomes the bottleneck): > > > > > > Testing enviroment (all with Intel 10Gbit NIC) > > Sender: FreeBSD 11-CURRENT - CPU i7-870 at 2.93 GHz + Turboboost > > Receiver: Linux 3.12.8 - CPU i7-3770K at 3.50GHz + Turboboost > > Benchmark tool: netperf 2.6.0 > > > > --- TCP/IPv4 packets (checksum offloading enabled) --- > > Freq. TSO GSO none Speedup > > [GHz] [Gbps] [Gbps] [Gbps] GSO-none > > 2.93 9347 9298 8308 12 % > > 2.53 9266 9401 6771 39 % > > 2.00 9408 9294 5499 69 % > > 1.46 9408 8087 4075 98 % > > 1.05 9408 5673 2884 97 % > > 0.45 6760 2206 1244 77 % > > > > > > --- TCP/IPv6 packets (checksum offloading enabled) --- > > Freq. TSO GSO none Speedup > > [GHz] [Gbps] [Gbps] [Gbps] GSO-none > > 2.93 7530 6939 4966 40 % > > 2.53 5133 7145 4008 78 % > > 2.00 5965 6331 3152 101 % > > 1.46 5565 5180 2348 121 % > > 1.05 8501 3607 1732 108 % > > 0.45 3665 1505 651 131 % > > > > > > --- UDP/IPv4 packets (9K) --- > > Freq. GSO none Speedup > > [GHz] [Gbps] [Gbps] GSO-none > > 2.93 9440 8084 17 % > > 2.53 7772 6649 17 % > > 2.00 6336 5338 19 % > > 1.46 4748 4014 18 % > > 1.05 3359 2831 19 % > > 0.45 1312 1120 17 % > > > > > > --- UDP/IPv6 packets (9K) --- > > Freq. GSO none Speedup > > [GHz] [Gbps] [Gbps] GSO-none > > 2.93 7281 6197 18 % > > 2.53 5953 5020 19 % > > 2.00 4804 4048 19 % > > 1.46 3582 3004 19 % > > 1.05 2512 2092 20 % > > 0.45 998 826 21 % > > > > We tried to change as little as possible the network stack to add > > GSO support. To avoid changing API/ABI, we temporarily used spare > > fields in struct tcpcb (TCP Control Block) and struct ifnet to store > > some information related to GSO (enabled, max burst size, etc.). > > The code that performs the segmentation/fragmentation is contained > > in the file gso.[h|c] in sys/net. We used 4 bit in m_pkthdr.csum_flags > > (CSUM_GSO_MASK) to encode the packet type (TCP/IPv4, TCP/IPv6, etc) > > to prevent access to the TCP/IP/Ethernet headers of each packet. > > In ether_output_frame(), if the packet requires the GSO > > ((m->m_pkthdr.csum_flags & CSUM_GSO_MASK) !=3D 0), it is segmented > > or fragmented, and then they are sent to the device driver. > > > > At https://github.com/stefano-garzarella/freebsd-gso > > you can find the kernel patches for FreeBSD-current, FreeBSD > > 10-stable, FreeBSD 9-stable, a simple application (gso-stats.c) > > that prints the GSO statistics and picobsd images with GSO support. > > > > At https://github.com/stefano-garzarella/freebsd-gso-src > > you can get the FreeBSD source with GSO patch (various branch for > > FreeBSD current, 10-stable, 9-stable). > > > > Any feedbacks, comments, questions are welcome. > > > > Thank you very much, > > Stefano Garzarella > > > > > -------------------------------------------------------------------------= ----------------------------------- > > How to use GSO: > > > > - Apply the right kernel patch. > > > > - To compile the GSO support add =E2=80=98 options GSO ' to your kernel= config > file > > and > > rebuild a kernel. > > > > - To manage the GSO parameters there are some sysctls: > > - net.inet.tcp.gso - GSO enable on TCP communications (!=3D0) > > - net.inet.udp.gso - GSO enable on UDP communications (!=3D0) > > > > - for each interface: > > - net.gso.dev."ifname=E2=80=9D.max_burst - GSO burst length l= imit > > [default: IP_MAXPACKET=3D65535] > > - net.gso.dev."ifname=E2=80=9D.enable_gso - GSO enable on =E2= =80=9Cifname=E2=80=9D > > interface (!=3D0) > > > > - To show statistics: > > - make sure that the GSO_STATS macro is defined in sys/net/gso.h > > - use the simple gso-stats.c application to access the sysctl > > net.gso.stats > > that contains the address of the gsostats structure (defined in > > gso.h) > > which records the statistics. (compile with > > -I/path/to/kernel/src/patched/) > > > -------------------------------------------------------------------------= ----------------------------------- > > > > -- > > *Stefano Garzarella* > > stefano.garzarella@gmail.com > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscribe@freebsd.org" > --=20 *Stefano Garzarella* stefano.garzarella@gmail.com From owner-freebsd-net@FreeBSD.ORG Wed Sep 17 20:27:15 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0812D2; Wed, 17 Sep 2014 20:27:15 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9F255344; Wed, 17 Sep 2014 20:27:15 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 8B43F24800B; Wed, 17 Sep 2014 22:27:12 +0200 (CEST) Message-ID: <5419EE95.40600@selasky.org> Date: Wed, 17 Sep 2014 22:27:01 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Stefano Garzarella , Adrian Chadd Subject: Re: [RFC] Patch to add Software/Generic Segmentation Offload (GSO) support in FreeBSD References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , freebsd-current , Luigi Rizzo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Sep 2014 20:27:16 -0000 On 09/17/14 20:18, Stefano Garzarella wrote: > Hi Adrian, > the results that I sent, regard just one flow, but I can try with two > simultaneous flows and I'll send you the results. > > Thanks, > Stefano > Hi Stefano, You might have seen the discussion about TSO. Is it so that the proposed GSO feature only looks at the "ifp->if_hw_tsomax" field, and ignores hardware limits regarding maximum segment size and maximum segment count? --HPS From owner-freebsd-net@FreeBSD.ORG Wed Sep 17 22:34:50 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 58463F5D; Wed, 17 Sep 2014 22:34:50 +0000 (UTC) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0666927B; Wed, 17 Sep 2014 22:34:49 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id w8so33981qac.31 for ; Wed, 17 Sep 2014 15:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aAud/8w3JY9dDbNC8RV2+HBuToN1m6I9mTRVlLcb9OQ=; b=xMCuccm50x0MsWW3uJhfNf2aqmoF1rOVF/RY1fwBx7w4CAcJKqkryVRYz3l7OxFTcR XIQ3UA41uMD3vRoZFcYz72yBGiiMfNReHiYrA8Sel2vANc0gAexBjOBrf1VCKkavR1he 4gcdpbwRBxlStcKoE+M3uNIMfT8QRmtOHiCt1bGxLQoW7qlmU/HquqjHI5tlt7VEQd3d lfa5JLspFud/WXZ1ZMLGpNNc9kY++xh/lTDlXJTweRs9QE3iY/f2v20ilCx+Bbp86lde fqxtew3XaPN0q+DntQcgUGPf6RISNA1N4prykVJQXE1rUFrICvStHDP06iBovwEpxSSm oRwg== X-Received: by 10.236.93.2 with SMTP id k2mr260464yhf.184.1410993289055; Wed, 17 Sep 2014 15:34:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.170.161.131 with HTTP; Wed, 17 Sep 2014 15:34:08 -0700 (PDT) In-Reply-To: <1410968661.1166.32.camel@bruno> References: <513CB9AF.3090409@swin.edu.au> <53BF8945.3000802@swin.edu.au> <540D0741.6030403@swin.edu.au> <1410907731.1166.13.camel@bruno> <5418F8E4.8070606@swin.edu.au> <1410968661.1166.32.camel@bruno> From: Eric Joyner Date: Wed, 17 Sep 2014 15:34:08 -0700 Message-ID: Subject: Re: Multipath TCP for FreeBSD v0.4 To: Sean Bruno Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , Nigel Williams X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Sep 2014 22:34:50 -0000 As a random person without commit privileges, I hope so, too. --- - Eric Joyner On Wed, Sep 17, 2014 at 8:44 AM, Sean Bruno wrote: > On Wed, 2014-09-17 at 12:58 +1000, Nigel Williams wrote: > > On 17/09/14 08:48, Sean Bruno wrote: > > > On Mon, 2014-09-08 at 11:32 +1000, Nigel Williams wrote: > > >> Hi, > > >> > > >> We recently released a new tech report "Design Overview of > > Multipath TCP > > >> version 0.4 for FreeBSD-11" [1]. The report provides some details > > on > > >> various aspects of the implementation (session management, > > data-level > > >> retransmission etc), as of the most recent v0.4 patch [2]. > > >> > > >> cheers, > > >> nigel > > >> > > >> [1] http://caia.swin.edu.au/reports/140822A/CAIA-TR-140822A.pdf > > >> [2] http://caia.swin.edu.au/urp/newtcp/mptcp/tools.html > > >> > > > > > > > > > Nigel: > > > > > > Hi! Are you folks interested in having this patchset incorporated > > into > > > the main line of FreeBSD? I'm open to putting up a phabricator > > review > > > for you folks at https://reviews.freebsd.org if that's something you > > > guys want to do? > > > > > > sean > > > > > > > Hi Sean, > > > > Thanks, but I think it's too early to put it into phabricator. The > > patch > > releases thus far are early test previews for those who are > > interested > > and perhaps willing to play around with. So in short, it's not > > production quality and not ready for committing to mainline. > > > > I'll continue to announce these patches on the mailing list for the > > time > > being. I'm of course open to feedback/suggestions/questions and will > > provide documentation with each release. > > > > cheers, > > nigel > > > > > > Noted. Thank you for the feedback. > > I hope, that someday, https://reviews.freebsd.org becomes more of a code > review tool for users than it is being used for today. > > sean > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Sep 17 22:52:20 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE54436A for ; Wed, 17 Sep 2014 22:52:20 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id C81FD636 for ; Wed, 17 Sep 2014 22:52:20 +0000 (UTC) Received: from u10-2-32-011.office.norse-data.com (unknown [50.204.88.51]) by elvis.mu.org (Postfix) with ESMTPSA id 87C4C346DE0F for ; Wed, 17 Sep 2014 15:52:20 -0700 (PDT) Message-ID: <541A10B1.9040105@freebsd.org> Date: Wed, 17 Sep 2014 15:52:33 -0700 From: Alfred Perlstein Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Multipath TCP for FreeBSD v0.4 References: <513CB9AF.3090409@swin.edu.au> <53BF8945.3000802@swin.edu.au> <540D0741.6030403@swin.edu.au> <1410907731.1166.13.camel@bruno> <5418F8E4.8070606@swin.edu.au> <1410968661.1166.32.camel@bruno> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Sep 2014 22:52:21 -0000 Github offers an excellent system with comments and all that jazz for making pull requests. Super simple to use. On 9/17/14 3:34 PM, Eric Joyner wrote: > As a random person without commit privileges, I hope so, too. > > --- > - Eric Joyner > > On Wed, Sep 17, 2014 at 8:44 AM, Sean Bruno wrote: > >> On Wed, 2014-09-17 at 12:58 +1000, Nigel Williams wrote: >>> On 17/09/14 08:48, Sean Bruno wrote: >>>> On Mon, 2014-09-08 at 11:32 +1000, Nigel Williams wrote: >>>>> Hi, >>>>> >>>>> We recently released a new tech report "Design Overview of >>> Multipath TCP >>>>> version 0.4 for FreeBSD-11" [1]. The report provides some details >>> on >>>>> various aspects of the implementation (session management, >>> data-level >>>>> retransmission etc), as of the most recent v0.4 patch [2]. >>>>> >>>>> cheers, >>>>> nigel >>>>> >>>>> [1] http://caia.swin.edu.au/reports/140822A/CAIA-TR-140822A.pdf >>>>> [2] http://caia.swin.edu.au/urp/newtcp/mptcp/tools.html >>>>> >>>> >>>> Nigel: >>>> >>>> Hi! Are you folks interested in having this patchset incorporated >>> into >>>> the main line of FreeBSD? I'm open to putting up a phabricator >>> review >>>> for you folks at https://reviews.freebsd.org if that's something you >>>> guys want to do? >>>> >>>> sean >>>> >>> Hi Sean, >>> >>> Thanks, but I think it's too early to put it into phabricator. The >>> patch >>> releases thus far are early test previews for those who are >>> interested >>> and perhaps willing to play around with. So in short, it's not >>> production quality and not ready for committing to mainline. >>> >>> I'll continue to announce these patches on the mailing list for the >>> time >>> being. I'm of course open to feedback/suggestions/questions and will >>> provide documentation with each release. >>> >>> cheers, >>> nigel >>> >>> >> Noted. Thank you for the feedback. >> >> I hope, that someday, https://reviews.freebsd.org becomes more of a code >> review tool for users than it is being used for today. >> >> sean >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Sep 17 23:43:53 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 62E50C31 for ; Wed, 17 Sep 2014 23:43:53 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4A663A71 for ; Wed, 17 Sep 2014 23:43:53 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s8HNhrV4000780 for ; Wed, 17 Sep 2014 23:43:53 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193053] ixgbe(4) IXGBE_LEGACY_TX + ALTQ path broken Date: Wed, 17 Sep 2014 23:43:53 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ricera10@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Sep 2014 23:43:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193053 Eric Joyner changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ricera10@gmail.com --- Comment #1 from Eric Joyner --- Changes were made to IXGBE_LEGACY_TX in this ixgbe version: https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=14688 Does using that help? - Eric -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Sep 18 02:39:14 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6FB9B569 for ; Thu, 18 Sep 2014 02:39:14 +0000 (UTC) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3CDA9B6E for ; Thu, 18 Sep 2014 02:39:14 +0000 (UTC) Received: by mail-oi0-f46.google.com with SMTP id i138so176952oig.5 for ; Wed, 17 Sep 2014 19:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=j4jRE65xdUZjD2cOZ2jnketbvXEAiW1znsfdQuJm7y8=; b=anIkW3DrH/2wpNIJ9vxX/cDK0G1ZmB9nB2Xt0CO1poVgDXtZp8psDqZweyd8x1+9JE qLYIxYb3R7/AfkoqnHEJzjSo1lex2489T+AdYn6INnEWJReaI8ffjFiS+O7lvDl0xQP5 G9VSZrMQX7ni82y7Gc/qz2GiBDC1ysNUTS/BOipb1v4u/PhaUQURh8CK0sOMPtmWFJeR Rh3sLZwsl8h/lOzZygC9Srq26rZZ/Wkay0nSzg96mg3gJtT7yWVPs/MEbmETwtkMJdsO RpLMNWX3CeG6iky6xlv61qeO2Trnt+ZdJZ8gSlXd/HX9D2gUW8vM+mvqZWYsTKDsRTXQ pNMw== MIME-Version: 1.0 X-Received: by 10.182.65.65 with SMTP id v1mr1271634obs.58.1411007953497; Wed, 17 Sep 2014 19:39:13 -0700 (PDT) Received: by 10.76.95.199 with HTTP; Wed, 17 Sep 2014 19:39:13 -0700 (PDT) Date: Thu, 18 Sep 2014 10:39:13 +0800 Message-ID: Subject: [netmap/vale-ctl] when could process packet From: upyzl To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Sep 2014 02:39:14 -0000 Hi, I think it's right place to talk about FreeBSD 10 - netmap question (location at FreeBSD 10: /usr/src/tools/tools/netmap ; with kernel device netmap on) I'm (entry) study on openflow software switch based on netmap/vale It seems very simple in vale-ctl.c and hard to add features for packet process (such as flow match and forward actions apply) Could anyone give me some advice? thanks. Best regards, Jaye From owner-freebsd-net@FreeBSD.ORG Thu Sep 18 03:42:09 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 23192F73 for ; Thu, 18 Sep 2014 03:42:09 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0A81F20D for ; Thu, 18 Sep 2014 03:42:09 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s8I3g8pV006457 for ; Thu, 18 Sep 2014 03:42:08 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193053] ixgbe(4) IXGBE_LEGACY_TX + ALTQ path broken Date: Thu, 18 Sep 2014 03:42:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: adrian@freebsd.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Sep 2014 03:42:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193053 Adrian Chadd changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adrian@freebsd.org --- Comment #2 from Adrian Chadd --- Ugh, I totally dropped the ball on this one. I'm sorry. I'll see if I can get releng support to commit this before 10.1-RELEASE occurs. Thanks! -a -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Sep 18 03:48:16 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D43D1AA for ; Thu, 18 Sep 2014 03:48:16 +0000 (UTC) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9A76C232 for ; Thu, 18 Sep 2014 03:48:16 +0000 (UTC) Received: by mail-ob0-f176.google.com with SMTP id uz6so222634obc.7 for ; Wed, 17 Sep 2014 20:48:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=kqkQYdUsEC63PqVVzBVtHlNbWYoiaA6dMDZiH3VQaXk=; b=guoP6WOgK5fgmY+x2TnlZWYZIVAlrS6qAY6LRG1rSbTAgzxWuDW4pZhSWH/qjKcYNC kpMnt09WcetIF3xqb77pZdElgWe3RDqGbB2rG2UFHISfxn3pU0QnwiP+oRAAaZIMc5S7 m7HcPb8X/1U7A3fQvYkM+ooR6JQKriMh/lEDjfPv1jmeQVCeQDJzs8tL89gGE2pAs40D a5+zJPXHHaCJeyGDkqtZqLSBunzKnWVePCsqN4rImreN0JGVUbuYVzTx/YNVXKVp6Euo DxkAhVns9sVSSJHPCxcmWYmu2dim7HQFlh06I5igLSMaXrX8bYEdi/Rowc05wcUcWbmy 3ZxQ== X-Gm-Message-State: ALoCoQmBPYEFBYW0SyD6v+v/Fmuq6wJPbSQ1zVC6c3XTMoe3mAHA2/4oWsUuy70FD2JNe7Did2Eq X-Received: by 10.60.161.68 with SMTP id xq4mr485752oeb.84.1411012089724; Wed, 17 Sep 2014 20:48:09 -0700 (PDT) Received: from jamess-mbp.netgate.com (65-36-83-120.static.grandenetworks.net. [65.36.83.120]) by mx.google.com with ESMTPSA id ix8sm12543877obc.11.2014.09.17.20.48.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Sep 2014 20:48:09 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1985.3\)) Subject: Re: [netmap/vale-ctl] when could process packet From: Jim Thompson In-Reply-To: Date: Wed, 17 Sep 2014 22:48:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <357AB2A4-C00C-4EF6-A926-36CBE5FA2FDC@netgate.com> References: To: upyzl X-Mailer: Apple Mail (2.1985.3) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Sep 2014 03:48:16 -0000 Jaye, I=E2=80=99d really like to see this work happen. Let me know if I can help. Jim > On Sep 17, 2014, at 9:39 PM, upyzl wrote: >=20 > Hi, >=20 > I think it's right place to talk about FreeBSD 10 - netmap question > (location at FreeBSD 10: /usr/src/tools/tools/netmap ; with kernel = device > netmap on) >=20 > I'm (entry) study on openflow software switch based on netmap/vale >=20 > It seems very simple in vale-ctl.c and hard to add features for packet > process (such as flow match and forward actions apply) >=20 > Could anyone give me some advice? thanks. >=20 > Best regards, > Jaye > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Sep 18 04:11:45 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04BD3384 for ; Thu, 18 Sep 2014 04:11:45 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C750564E for ; Thu, 18 Sep 2014 04:11:44 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s8I4BiPm015443 for ; Thu, 18 Sep 2014 04:11:44 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193053] ixgbe(4) IXGBE_LEGACY_TX + ALTQ path broken Date: Thu, 18 Sep 2014 04:11:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ncrogers@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Sep 2014 04:11:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193053 --- Comment #3 from ncrogers@gmail.com --- >From what I can tell, the changes in the newer ixgbe driver here: https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=14688 Fix two of three problems with the IXGBE_LEGACY_TX path that I changed in the attached diff. My guess is because they were fixed because its pretty obvious when auditing the code. #1 #ifdef IXGBE_LEGACY_TX - if (!IFQ_DRV_IS_EMPTY(ifp->if_snd)) + if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) This is fixed in the newer Intel driver. Not in FBSD. #2 -#ifdef IXGBE_LEGACY_TX - if (txr->br != NULL) - buf_ring_free(txr->br, M_DEVBUF); -#endif This also seems to be fixed in the Intel driver, not FBSD, which as far as I can tell affects the non-legacy path behavior (i.e., most everyone). In my diff I opted to remove it, but in the newer Intel driver apparently its implied that its necessary for the non-legacy path, as the #ifdef is changed to #ifndef. #3 else if (txr->queue_status == IXGBE_QUEUE_WORKING) +#ifndef IXGBE_LEGACY_TX taskqueue_enqueue(que->tq, &txr->txq_task); +#else + taskqueue_enqueue(que->tq, &que->que_task); +#endif I still believe this change is necessary, and its not in the newer Intel driver from what I can tell, and its not so obvious unless you actually try to use the legacy path. Again, I'm not an expert, so I hope someone can validate all of this. 10/stable (and HEAD, I think) still have all three problems. It would indeed be nice for this to be fixed in 10.1-RELEASE. Thanks! -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Sep 18 06:17:11 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3F8C8A28 for ; Thu, 18 Sep 2014 06:17:11 +0000 (UTC) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0682FCC for ; Thu, 18 Sep 2014 06:17:10 +0000 (UTC) Received: by mail-oa0-f48.google.com with SMTP id g18so312860oah.21 for ; Wed, 17 Sep 2014 23:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zP58kBw+wnGse4ZUIgTwTWCcaR5NeVfLli4zwHqV5n4=; b=PZlObS81q1mBJq4z8iOTdb/DAH0/UC8vNgc8Z/f9VLYr3SXp2V7r3Wk47WC+33g0Jn nSoYw69Bla5vpJn30aPUasMNNO33jHNwcMp1X2KMPFbjz0zgIblUq5fOUp4n5DK7hCuu +s/5brwj1wlV8s9A2DQ/JAdZbM1rUysQbbSBWBkU79y+FEYi9dbgizYp/PkAIkGey8dL STTuQKwD9t7W8EFizNjqnfWQ5aCvHqxSdz+W1DpFbNOyDuydMfGIdu7spA/scdvskYHK u3TUZ49OCHoG+zuRodvvcQ9HCOXLaoyyQrHpmzUcq2gbFdH8nJ40YoEgbj5bAucld20X qNYA== MIME-Version: 1.0 X-Received: by 10.182.209.101 with SMTP id ml5mr2179587obc.2.1411021029915; Wed, 17 Sep 2014 23:17:09 -0700 (PDT) Received: by 10.76.95.199 with HTTP; Wed, 17 Sep 2014 23:17:09 -0700 (PDT) In-Reply-To: References: <357AB2A4-C00C-4EF6-A926-36CBE5FA2FDC@netgate.com> Date: Thu, 18 Sep 2014 14:17:09 +0800 Message-ID: Subject: Re: [netmap/vale-ctl] when could process packet From: upyzl To: Jim Thompson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Sep 2014 06:17:11 -0000 (forgot cc before) Hi, Jim thanks for reply this is my graduate design project my aim is to implement a simple software switch based on openflow using FreeBSD netmap as network I/O framework besides, I'm succeed doing on bridge.c at 2 interfaces add like /********************* Func: int main() rxring0 =3D NETMAP_RXRING((me+1)->nifp, (me+1)->begin); struct netmap_slot *rs0 =3D &rxring0->slot[rxring0->cur]; unsigned char *rxbuf0 =3D (unsigned char *)(NETMAP_BUF(rxring0, rs0->buf_idx)); *********************/ then process rxbuf0 before packet move but I need do at many interfaces, like vale-ctl does It's also hard to add interfaces on bridge.c, and from netmap introduces, I should use vale-ctl Jaye 2014-09-18 13:45 GMT+08:00 upyzl : > Hi, Jim > > thanks for reply > > this is my graduate design project > my aim is to implement a simple software switch based on openflow using > FreeBSD netmap as network I/O framework > > besides, I'm succeed doing on bridge.c at 2 interfaces > add like > /********************* Func: int main() > > rxring0 =3D NETMAP_RXRING((me+1)->nifp, (me+1)->begin); > struct netmap_slot *rs0 =3D &rxring0->slot[rxring0->cur]; > unsigned char *rxbuf0 =3D (unsigned char *)(NETMAP_BUF(rxring0, > rs0->buf_idx)); > > *********************/ > then process rxbuf0 before packet move > > but I need do at many interfaces, like vale-ctl does > It's also hard to add interfaces on bridge.c, and from netmap introduces, > I should use vale-ctl > > Jaye > > 2014-09-18 11:48 GMT+08:00 Jim Thompson : > >> Jaye, >> >> I=E2=80=99d really like to see this work happen. >> >> Let me know if I can help. >> >> Jim >> >> > On Sep 17, 2014, at 9:39 PM, upyzl wrote: >> > >> > Hi, >> > >> > I think it's right place to talk about FreeBSD 10 - netmap question >> > (location at FreeBSD 10: /usr/src/tools/tools/netmap ; with kernel >> device >> > netmap on) >> > >> > I'm (entry) study on openflow software switch based on netmap/vale >> > >> > It seems very simple in vale-ctl.c and hard to add features for packet >> > process (such as flow match and forward actions apply) >> > >> > Could anyone give me some advice? thanks. >> > >> > Best regards, >> > Jaye >> > _______________________________________________ >> > freebsd-net@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-net >> > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> > From owner-freebsd-net@FreeBSD.ORG Thu Sep 18 07:45:45 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB70FD95 for ; Thu, 18 Sep 2014 07:45:45 +0000 (UTC) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 72C3CADD for ; Thu, 18 Sep 2014 07:45:45 +0000 (UTC) Received: by mail-ob0-f170.google.com with SMTP id wm4so368091obc.15 for ; Thu, 18 Sep 2014 00:45:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tsUehk9P+K0uD1bineaJmfX0tNlRGLUTsHLFIrbiJVY=; b=o+tvPmM8ox35wF8THxdrBpaD5+NGmH7PERaOWQff6L+BK31B0Fi35kjJW530W39DJw uZc2qRve3W6xbbW7kV0fop+bkJc+8Vrex1uM4DlmZwU/AIlu1h/5FIW6t19rNJ99A0V6 3NqtNghgTC0XT4Hhk0on8NN4tfE03iWivBRpj1lCslx2/VUkQweEM68+WsqOZ8C43Bfk 9QgZA0xVzGDwXtsqHAeaBbOovX0B6d8YIjCFGzcljbqCL1mOf/PPo9ydxN7aUR8I7O7A 3DGUUG4qi0VcIuvjIcTVxU84A0xHc2kIR1PG2wPcdS0XZ4TCK3PjXo+pcDLe8Asi6DGS AHiA== MIME-Version: 1.0 X-Received: by 10.182.3.100 with SMTP id b4mr2314603obb.79.1411026344604; Thu, 18 Sep 2014 00:45:44 -0700 (PDT) Received: by 10.76.95.199 with HTTP; Thu, 18 Sep 2014 00:45:44 -0700 (PDT) In-Reply-To: References: Date: Thu, 18 Sep 2014 15:45:44 +0800 Message-ID: Subject: Re: [netmap/vale-ctl] when could process packet From: upyzl To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-net@freebsd.org, =?UTF-8?B?6LW16ZKm?= X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Sep 2014 07:45:45 -0000 Hi Luigi, glad to see you :) I just implement the datapath of the switch (base on openflow 1.0) For the basis, a FreeBSD act as the switch typical topo: (there should be a controller link with the switch, we currently ignore it) host1[eth0] -------- [em0]switch[em1] ------- [eth0]host2 [em2] [em3] | | host3[eth0] --------------| |----------------[eth0]host4 In OpenFlow std. there may be some rules like (just an example): TCP packet: host1 --> host 3 & host 4 I think I should analysis all incoming em0 packets which match the rules(flow table), forward only matched packets to em2 & em3 (forward itself using netmap) ( I use like this: ./vale-ctl -a vale0:em0 ./vale-ctl -a vale0:em1 ./vale-ctl -a vale0:em2 ./vale-ctl -a vale0:em3 then host1 send packets ) the point is, I don't know when/where to process it before forwarding ( as vale.ctl.c is very simple... I could do the match on bridge.c with 2 interfaces) Additional, I don't use OpenvSwitch since it's too complex (conclusion of talked with my advisor) Thanks! Jaye 2014-09-18 15:07 GMT+08:00 Luigi Rizzo : > Please tell me more details on what are your goals. We already have some > work on progress on the topic and it might make sense for you to start from > what we have already, rather than restart from scratch. Of course, if your > advisor agrees - you may want to involve him in the discussion. > > Cheers > Luigi > > On Thursday, September 18, 2014, upyzl wrote: > >> Hi, >> >> I think it's right place to talk about FreeBSD 10 - netmap question >> (location at FreeBSD 10: /usr/src/tools/tools/netmap ; with kernel device >> netmap on) >> >> I'm (entry) study on openflow software switch based on netmap/vale >> >> It seems very simple in vale-ctl.c and hard to add features for packet >> process (such as flow match and forward actions apply) >> >> Could anyone give me some advice? thanks. >> >> Best regards, >> Jaye >> _______________________________________________ >> 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 Thu Sep 18 14:16:36 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9261A150; Thu, 18 Sep 2014 14:16:36 +0000 (UTC) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2CF67B89; Thu, 18 Sep 2014 14:16:36 +0000 (UTC) Received: by mail-qa0-f45.google.com with SMTP id s7so1143140qap.18 for ; Thu, 18 Sep 2014 07:16:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9Pvf0pm+/GI60Oo68S0nok3Hq7X+nXfIIFisQBuzJdM=; b=MeTVt9pGNFOvsNHZZ7DFOrFh2N89PG+jqAvtt5r89H52xmZQBkvuj8KzfXugnNtRl4 wvpq4NnrC8L31uZoIN+/vQz9gowvSO+NR2elfQT0TCSeRWO/V4LIIUIA8h4QZskQcytR XtqiZqbJhUi4M4BkEwrhwXbaTm8pdIbyIJsWgDgM+jyrf+1XuRuMhFQ6TKdstwJow+sM Na1sD0E88XZ4xqZ9C+Hn1lPeyx55WnOEOqMnfCpOKXkX7giOc/oyRIxzqSUx9dD+Kzo4 tKHGgMzC57WI5E6tmQ91xqHeE4MQdPVoyoYJcsd/MRvfHaWTKlqfXktj8eJwPE7DGG3U qfog== MIME-Version: 1.0 X-Received: by 10.224.86.5 with SMTP id q5mr9574982qal.36.1411049795051; Thu, 18 Sep 2014 07:16:35 -0700 (PDT) Received: by 10.140.104.241 with HTTP; Thu, 18 Sep 2014 07:16:34 -0700 (PDT) In-Reply-To: <5419EE95.40600@selasky.org> References: <5419EE95.40600@selasky.org> Date: Thu, 18 Sep 2014 16:16:34 +0200 Message-ID: Subject: Re: [RFC] Patch to add Software/Generic Segmentation Offload (GSO) support in FreeBSD From: Stefano Garzarella To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , Adrian Chadd , freebsd-current , Luigi Rizzo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Sep 2014 14:16:36 -0000 Hi Hans, I saw the discussion about TSO, but the GSO is a software implementation unrelated with the hardware. Furthermore, if the TSO is enabled (and supported by the NIC), the GSO is not executed, because is useless. After the execution of the GSO, the packets, that are passed to the device driver, are smaller (or equal) than MTU, so the TSO is unnecessary. For this reason the GSO doesn't look neither "ifp->if_hw_tsomax" nor hardware segment limits. The GSO is very useful when you can't use the TSO. Cheers, Stefano 2014-09-17 22:27 GMT+02:00 Hans Petter Selasky : > On 09/17/14 20:18, Stefano Garzarella wrote: > >> Hi Adrian, >> the results that I sent, regard just one flow, but I can try with two >> simultaneous flows and I'll send you the results. >> >> Thanks, >> Stefano >> >> > Hi Stefano, > > You might have seen the discussion about TSO. Is it so that the proposed > GSO feature only looks at the "ifp->if_hw_tsomax" field, and ignores > hardware limits regarding maximum segment size and maximum segment count? > > --HPS > -- *Stefano Garzarella* stefano.garzarella@gmail.com From owner-freebsd-net@FreeBSD.ORG Thu Sep 18 15:27:48 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 29AF93B0; Thu, 18 Sep 2014 15:27:48 +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)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E42677E2; Thu, 18 Sep 2014 15:27:47 +0000 (UTC) Received: by mail-pd0-f172.google.com with SMTP id v10so1624243pde.17 for ; Thu, 18 Sep 2014 08:27:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PwOOEuTXCiU40DQ0+jIMK2m+x87Q8Pn4FYuUJkOHEQM=; b=CaWeokpPaew6TbzagIWIgZTj+1zlqYItN0V6kG5z9BFFhSaSGc9bh7kQyviY+/Tyj7 nfzOls9SPeu3uSdOz7bpQk8ZLkOtYgi9WyxnViQgJYOQOiWGVT7p2yCyISBcKwGgNHHO UKQ6OtJaAO9waa3uGCJyvma+be2NzyvZ2mAXYCxoESqcSt5+T78VnbUwBXzfuZXNntrH FnoHwbkFhWLDXKEaPeNGSAmscQFNbBl3z5HxY03g5CPFDRAMVtSeZ5xMCatmwjYDtnqp o5zD1BfgrFFgioD6HSUsudS7eEozf2SpcuYtS/egkFiTt7SbxM3lswq/GAUD1HV0xedH OwCw== MIME-Version: 1.0 X-Received: by 10.70.42.7 with SMTP id j7mr6284590pdl.9.1411054067133; Thu, 18 Sep 2014 08:27:47 -0700 (PDT) Received: by 10.202.104.89 with HTTP; Thu, 18 Sep 2014 08:27:47 -0700 (PDT) In-Reply-To: References: <5419EE95.40600@selasky.org> Date: Thu, 18 Sep 2014 08:27:47 -0700 Message-ID: Subject: Re: [RFC] Patch to add Software/Generic Segmentation Offload (GSO) support in FreeBSD From: Freddie Cash To: Stefano Garzarella Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Hans Petter Selasky , Adrian Chadd , "freebsd-net@freebsd.org" , freebsd-current , Luigi Rizzo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Sep 2014 15:27:48 -0000 On Thu, Sep 18, 2014 at 7:16 AM, Stefano Garzarella < stefanogarzarella@gmail.com> wrote: > I saw the discussion about TSO, but the GSO is a software > implementation unrelated with the hardware. > Furthermore, if the TSO is enabled (and supported by the NIC), the GSO is > not executed, because is useless. > > After the execution of the GSO, the packets, that are passed to the devic= e > driver, are smaller (or equal) than MTU, so the TSO is unnecessary. For > this reason the GSO doesn't look neither "ifp->if_hw_tsomax" nor hardware > segment limits. > > The GSO is very useful when you can't use the TSO. > =E2=80=8BHow does GSO affect IPFW, specifically the libalias(3)-based, in-k= ernel NAT? The ipfw(8) man page mentions that it doesn't play nicely with hardware-based TSO, and that one should disable TSO when using IPFW NAT. Will the software-based GSO play nicely with IPFW NAT?=E2=80=8B Will it ma= ke any difference to packet throughput through IPFW? Or is it still way too early in development to be worrying about such things? :) --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-net@FreeBSD.ORG Thu Sep 18 18:50:15 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 317FEAAC; Thu, 18 Sep 2014 18:50:15 +0000 (UTC) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7ED762ED; Thu, 18 Sep 2014 18:50:14 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id mc6so1780441lab.34 for ; Thu, 18 Sep 2014 11:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nqutUqgD/dt5ZyXbg3fM7Rvo8N3VThzImDqy2HKmZ1k=; b=n6am/tpaC2gZKPC4ZxXO+X8XC6S1c/g/unAInMqscLNzf8Pe7JQjHT2Banq2W+ebmu KOIJ/30OTAvj+KAsCOBSzLCNFWa2r9MxM0ocHGEHG4IqRs0uPHwijFr8kTm0QSKbNOfJ sGewWbbnrF3rfUmOg4ptgSuii6jr2lNCiVjL/4MQhMwzuwyy3/dF/P66XYKjNGVC/s56 8gNcslMrGAqvqo4GmwerbePWms1ANJkvHRFppH/odQkzdHa1gBYP7L53jijtHxCo4J2Z qudFV1+WzrxWdilf8Kj/60jggIwFujJcnfMq9sBCRslxlPcjEtyf2opXi/HQrTeD9ZHO 9T+g== MIME-Version: 1.0 X-Received: by 10.112.48.100 with SMTP id k4mr1427780lbn.95.1411066212278; Thu, 18 Sep 2014 11:50:12 -0700 (PDT) Received: by 10.25.21.166 with HTTP; Thu, 18 Sep 2014 11:50:12 -0700 (PDT) In-Reply-To: References: Date: Thu, 18 Sep 2014 14:50:12 -0400 Message-ID: Subject: Re: [RFC] Patch to add Software/Generic Segmentation Offload (GSO) support in FreeBSD From: Ryan Stone To: Stefano Garzarella Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@freebsd.org" , freebsd-current , Luigi Rizzo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Sep 2014 18:50:15 -0000 On Wed, Sep 17, 2014 at 4:27 AM, Stefano Garzarella wrote: > Much of the advantage of TSO comes from crossing the network stack only > once per (large) segment instead of once per 1500-byte frame. > GSO does the same both for segmentation (TCP) and fragmentation (UDP) > by doing these operations as late as possible. My initial impression is that this is a layering violation. Code like this gives me pause: + eh = mtod(m, struct ether_vlan_header *); + if (eh->evl_encap_proto == htons(ETHERTYPE_VLAN)) { + eh_len = ETHER_HDR_LEN + ETHER_VLAN_ENCAP_LEN; + } else { + eh_len = ETHER_HDR_LEN; + } + + return gso_dispatch(ifp, m, eh_len); If someone adds QinQ support, this code must be updated. When vxlan support comes in, we must update this code or else the outer UDP packet gets fragmented instead of the inner TCP payload being segmented. As more tunneling protocols get added to FreeBSD, the dispatch code for GSO gets uglier and uglier. It seems to me that the real problem that we are trying to solve is a lack of batching in the kernel. Currently the network stack operates on the mbuf (packet) boundary. It seems to me that we could introduce a "packet group" concept that is guaranteed to have the same L3 and L2 endpoint. In the transmit path, we would initially have a single (potentially oversized) packet in the group. When TCP segments the packet, it would add each packet to the packet group and pass it down the stack. Because we guarantee that the endpoints are the same for every packet in the group, the L3 code can do a single routing table lookup and the L2 code can do a single l2table lookup for the entire group. The disadvantages of packet groups would be that: a) You have touch a lot more code in a lot more places to take advantage of the concept. b) TSO inherently has the same layering problems. If we're going to solve the problem for tunneling protocols then GSO might well be able to take advantage of them. From owner-freebsd-net@FreeBSD.ORG Thu Sep 18 21:02:57 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2547BBA2 for ; Thu, 18 Sep 2014 21:02:57 +0000 (UTC) Received: from smtpout101.ehv.onlinespamfilter.nl (smtpout101.ehv.onlinespamfilter.nl [IPv6:2001:4cb8:1:1620:217:21:240:171]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AF6673F1 for ; Thu, 18 Sep 2014 21:02:56 +0000 (UTC) Received: from smtp.onlinespamfilter.nl (localhost [127.0.0.1]) by smtp.onlinespamfilter.nl (Postfix) with ESMTP id 3hzVxY5K3gzVV; Thu, 18 Sep 2014 23:02:41 +0200 (CEST) Received: from smtp.debank.tv (145-158-ftth.on.nl [88.159.158.145]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.onlinespamfilter.nl (Postfix) with ESMTPS; Thu, 18 Sep 2014 23:02:41 +0200 (CEST) Received: from smtp.debank.tv (smtp.debank.tv [172.16.143.25]) by smtp.debank.tv (Postfix) with ESMTP id 0CC4A488493; Thu, 18 Sep 2014 23:02:41 +0200 (CEST) Received: from roundcube.debank.tv (roundcube.debank.tv [IPv6:2001:1af8:fe30::41]) by smtp.debank.tv (Postfix) with ESMTP id 9D640488492; Thu, 18 Sep 2014 23:02:40 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 19 Sep 2014 09:02:40 +1200 From: mailinglists@debank.tv To: freebsd-net@freebsd.org, owner-freebsd-net@freebsd.org Subject: Re: Performance problem with slow link behind fast gateway (solved: worked around) In-Reply-To: References: Message-ID: X-Sender: mailinglists@debank.tv User-Agent: Roundcube Webmail/1.0.2 X-Virus-Scanned: ClamAV using ClamSMTP @ debank.tv X-OSF-Virus: CLEAN X-OSF-Outgoing: Innocent X-OSF-Account: 1327 X-OSF-SUM: c444face2d845b6f6cae41d14bebc412 X-OSF-Info: Checked for spam and viruses Cc: Bryan Venteicher X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Sep 2014 21:02:57 -0000 On 2014-09-15 07:55, Bryan Venteicher wrote: > Hi, > > On Tue, Sep 9, 2014 at 4:42 PM, wrote: > >> All, >> >> I'm seeing some performance problems with a slowish VPN connection >> behind >> a fast gateway, the setup looks like this: >> >> |----------------------------------| >> |-----------------------------| >> |client (zandbak) (DSL connection)| ---- 'VPN tunnel' ----- |Gateway >> (vps) using NAT on 1G|------ 'Internet' >> |----------------------------------| >> |-----------------------------| >> >> >> Transfers from the gateway to the client are reasonably fast (easily >> within usable range for me): >> root@zandbak:/usr/home/rob # scp rob@gateway:test_file ./ >> test_file >> 100% 10MB 445.2KB/s 00:23 >> >> >> Transfers from the internet to the gateway are fast: >> root@vps:/usr/home/rob # fetch -4 "http://149.20.53.23/pub/ >> FreeBSD/releases/amd64/amd64/ISO-IMAGES/10.0/FreeBSD-10.0- >> RELEASE-amd64-bootonly.iso" >> FreeBSD-10.0-RELEASE-amd64-bootonly.iso 100% of 209 MB 10 >> MBps >> 00m20s >> >> >> But transfers from the client to the internet through the tunnel are >> showing a very degraded connection speed, the speed jumps up and down >> but >> averages at around 20kBps: >> root@zandbak:/usr/home/rob # fetch "http://149.20.53.23/pub/ >> FreeBSD/ISO-IMAGES-amd64/10.0/FreeBSD-10.0-RELEASE-amd64-bootonly.iso" >> FreeBSD-10.0-RELEASE-amd64-bootonly.iso 0% of 209 MB 8275 >> Bps >> 07h27m >> >> >> I've tried to eliminate some variables: >> -VPN: tinc as a L2 VPN and openVPN as a L3 VPN, results are the same >> -NAT: pf and ipfw, results are the same >> >> I suspect that there's a problem with the fast link receiving too much >> data and once the buffers are full dropping packets although I'm not >> sure >> if this is actually the problem. >> My question is: how can I debug this issue? >> >> >> > ​On the vtnet0 interface in your KVM VM​, disable checksum offloading. > What > KVM/QEMU VirtIO provides as the "checksum" in situation likes this does > not > work well with what FreeBSD expects. Fixing this has been on my todo > list > for awhile, but it is a moderate amount of work to fix this, and > touches > many places in the stack. I have plans to do mbuf related work later > this > year, and was planning to finally fix this issue as well. > > > <--------------SNIP-----------> Thanks Bryan, I can confirm performance with checksum offloading disabled on the vtnet interface is back to expected levels! Rob Evers From owner-freebsd-net@FreeBSD.ORG Thu Sep 18 22:24:50 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 980856CA for ; Thu, 18 Sep 2014 22:24:50 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7EA98DBC for ; Thu, 18 Sep 2014 22:24:50 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s8IMOo9t062147 for ; Thu, 18 Sep 2014 22:24:50 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193053] ixgbe(4) IXGBE_LEGACY_TX + ALTQ path broken Date: Thu, 18 Sep 2014 22:24:50 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ricera10@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Sep 2014 22:24:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193053 --- Comment #4 from Eric Joyner --- Why do you believe the third change is necessary? Is there a reason the extra code in the que_task tasklet must run in the legacy tx case? -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Sep 18 22:53:41 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09B5DEA7 for ; Thu, 18 Sep 2014 22:53:41 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E483F123 for ; Thu, 18 Sep 2014 22:53:40 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s8IMreAQ046632 for ; Thu, 18 Sep 2014 22:53:40 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193053] ixgbe(4) IXGBE_LEGACY_TX + ALTQ path broken Date: Thu, 18 Sep 2014 22:53:41 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ncrogers@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Sep 2014 22:53:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193053 --- Comment #5 from ncrogers@gmail.com --- (In reply to Eric Joyner from comment #4) > Why do you believe the third change is necessary? Is there a reason the > extra code in the que_task tasklet must run in the legacy tx case? Because of this part of the compile error when I tried to build a new kernel. /usr/src/sys/dev/ixgbe/ixgbe.c: In function 'ixgbe_local_timer': /usr/src/sys/dev/ixgbe/ixgbe.c:2077: error: 'struct tx_ring' has no member named 'txq_task' Everything else relying on txr->txq_task is either confined to within a multiqueue (non-legacy) function or there is an #ifndef IXGBE_LEGACY_TX around it. Furthermore, if you look at an older version of the ixgbe_local_timer function, it has taskqueue_enqueue(que->tq, &que->que_task) instead of taskqueue_enqueue(que->tq, &txr->txq_task); Here is the change where that happened. http://svnweb.freebsd.org/base/head/sys/dev/ixgbe/ixgbe.c?annotate=271648 Line 2066 http://svnweb.freebsd.org/base?view=revision&revision=251964 Note that was the only line in ixgbe_local_timer that was changed. I believe this change was made without consideration of the LEGACY_TX path, which is strange, because the commit was evidently intended to add ALTQ support via the LEGACY_TX path. Also, the igb/e1000 driver (if_igb.c) has a similar behavior in the same function, where taskqueue_enqueue(que->tq, &que->que_task) is used. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Sep 18 23:36:21 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64D30730 for ; Thu, 18 Sep 2014 23:36:21 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C4446D3 for ; Thu, 18 Sep 2014 23:36:21 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s8INaLZK085980 for ; Thu, 18 Sep 2014 23:36:21 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193053] ixgbe(4) IXGBE_LEGACY_TX + ALTQ path broken Date: Thu, 18 Sep 2014 23:36:21 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ricera10@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Sep 2014 23:36:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193053 --- Comment #6 from Eric Joyner --- You didn't try a kernel build with the newer driver that I posted? -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Sep 19 00:06:01 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ACCBEFBC for ; Fri, 19 Sep 2014 00:06:01 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 93F429FF for ; Fri, 19 Sep 2014 00:06:01 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s8J061Bd069535 for ; Fri, 19 Sep 2014 00:06:01 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193053] ixgbe(4) IXGBE_LEGACY_TX + ALTQ path broken Date: Fri, 19 Sep 2014 00:06:01 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ncrogers@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Sep 2014 00:06:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193053 --- Comment #7 from ncrogers@gmail.com --- (In reply to Eric Joyner from comment #6) > You didn't try a kernel build with the newer driver that I posted? I have not. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Sep 19 09:59:42 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 70132CD0 for ; Fri, 19 Sep 2014 09:59:42 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 41DBCA09 for ; Fri, 19 Sep 2014 09:59:42 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s8J9xgWt028504 for ; Fri, 19 Sep 2014 09:59:42 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201409190959.s8J9xgWt028504@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-net@FreeBSD.org Subject: Problem reports for freebsd-net@FreeBSD.org that need special attention X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 Date: Fri, 19 Sep 2014 09:59:42 +0000 Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Sep 2014 09:59:42 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ----------------+-----------+------------------------------------------------- Needs MFC | 183659 | [tcp] TCP stack lock contention with short-live 1 problems total for which you should take action. From owner-freebsd-net@FreeBSD.ORG Fri Sep 19 09:36:33 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D09C56C; Fri, 19 Sep 2014 09:36:33 +0000 (UTC) Received: from forward2h.mail.yandex.net (forward2h.mail.yandex.net [84.201.187.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 38CBF606; Fri, 19 Sep 2014 09:36:32 +0000 (UTC) Received: from web21h.yandex.ru (web21h.yandex.ru [84.201.187.155]) by forward2h.mail.yandex.net (Yandex) with ESMTP id D010F700CCB; Fri, 19 Sep 2014 13:36:27 +0400 (MSK) Received: from 127.0.0.1 (localhost [127.0.0.1]) by web21h.yandex.ru (Yandex) with ESMTP id 4AF981360FDE; Fri, 19 Sep 2014 13:36:27 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1411119387; bh=5vvc7zuNxlNIP033XJjfElfcAQ7LXJ7hN1mY3wabBb0=; h=From:To:Subject:Date; b=ZdX7qVo+gmoY5HJikXZd07k4P4N5w3IzHzy/ygrlaFtnu/f5UDz3ggRVXHvViwQKD AemR3IW6aylM/kwtycg+st2ZRbMZUrWbEiIWBgbN5D6RrX8lfYwvDKbl04Jes8d4nO nq8IzY6eEpgM8ntt7qS7TkQxCcIlmbA/EYaiIoEo= Received: from mx.style-ekb.ru (mx.style-ekb.ru [188.234.244.3]) by web21h.yandex.ru with HTTP; Fri, 19 Sep 2014 13:36:27 +0400 From: =?koi8-r?B?59XM0cXXIOfP28E=?= To: freebsd-drivers@freebsd.org, freebsd-net@freebsd.org Subject: Success with Qualcomm Atheros QCA8171 Message-Id: <3320661411119387@web21h.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Fri, 19 Sep 2014 15:36:27 +0600 X-Mailman-Approved-At: Fri, 19 Sep 2014 11:24:35 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Sep 2014 09:36:33 -0000 Good day! Since I ask on the FreeBSD forums, there is a proposition to check alx-freebsd and have initialized interface. So if someone have similar hardware, you can got your experience with that project and share info. Links: #alx-freebsd repository on github [1]https://github.com/markjdb/alx-freebsd #Thread on FreeBSD Forums [2]http://forums.freebsd.org/viewtopic.php?f=32&t=48077 -------------------------------------------- , . References 1. https://github.com/markjdb/alx-freebsd 2. http://forums.freebsd.org/viewtopic.php?f=32&t=48077 From owner-freebsd-net@FreeBSD.ORG Sat Sep 20 08:13:50 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F8D57D5 for ; Sat, 20 Sep 2014 08:13:50 +0000 (UTC) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E60EACF4 for ; Sat, 20 Sep 2014 08:13:49 +0000 (UTC) Received: by mail-qc0-f179.google.com with SMTP id x13so4192279qcv.24 for ; Sat, 20 Sep 2014 01:13:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=lacxpD4pg50E02VmiFBe26FtHPFKjGTfvPSH0G0r6No=; b=NtwoLNiX0wc9KyPI/FRFy4EI+3+fqLfRgPkldRRvzAJhflPCWi1iF3CgTKolTtSk4Z F8C/0JtGTWlc8zoBTERsT1kdWwr4W7/r71Lon3eLIPcwIhLiuZFQ+7KN5xIi/Cs4X0bC MtiY1s1oAtlub8LK/VtWD+chYL1GQ8DiPa0GHF5yAiOAOSjdApiXgYJPmJuNCoOw17Uo VmeF38e1+tDXQOhPVR3wqLPf6hCdz19f2MnefZ+DIAk0db7UyOfbZYOs2AgtXAE3I58m ifHzAhVQL4T/dcqPE1hZnpcfCtjjMzkNZuf1rZ9kX0xDYU6J2gXKlhQLHnnREVbkMLrv /1Og== MIME-Version: 1.0 X-Received: by 10.224.20.9 with SMTP id d9mr6955559qab.7.1411200829065; Sat, 20 Sep 2014 01:13:49 -0700 (PDT) Received: by 10.229.234.194 with HTTP; Sat, 20 Sep 2014 01:13:49 -0700 (PDT) Date: Sat, 20 Sep 2014 11:43:49 +0330 Message-ID: Subject: timestamping by netmap's drivers From: Mahnaz Talebi To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Sep 2014 08:13:50 -0000 Hi, I want to timestamp generated packets by netmap-pktgen in order to compute delay of receiving packets. Is it possible? =D9=90Does netmap-drivers and its API support this? Does anyone have any advice to do this? >I use your netmap pkt-gen for testing my applications and thanks you for >your great nice work. >I want to modify (if I can!) your pkt-gen such that I can insert timestamp= s >in udp packets in order to find delay of receiving packets (that forward >from my DUT). >?Do you have any suggestion to me to do this work? >Thanks in advance. From owner-freebsd-net@FreeBSD.ORG Sat Sep 20 16:47:41 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 010854A6; Sat, 20 Sep 2014 16:47:40 +0000 (UTC) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8DA6EEAE; Sat, 20 Sep 2014 16:47:40 +0000 (UTC) Received: by mail-qa0-f46.google.com with SMTP id f12so3852968qad.5 for ; Sat, 20 Sep 2014 09:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FyPxHPmyL73FQT9YYshE4Cwu/ClZkJ674XYdXUrplnU=; b=pYLm4Sn8/zoPPx80iAmfzWdGgiwTJ33s8ogVsWDnEEgWcEad6eg8LvMQkUfjtWDpEU Pd65cEFNAB3zO4ka5LFnfpsIFO9iFcjebS8SboUfA34H47kcfwyzhX33eUR9z3BvnvLP jOimq96BEvbv5lpcaxDqZG813aIeqxVf22zwHCPVHPxl9EJhj01d1tEeX/8uBJ+E4AIY k9BtiFp+AKpELMG90xu1X42uKFzv0SlRNAwN6AY+IeGgsqpCHRKdFq1AGS0KD5MU8c2P yeZpNU/u6R0Ue87luMBcXal3xomlMEvRoFfxINrod3cmkwqtzH0y1S3AIcB8+xSKfWI1 wKVw== MIME-Version: 1.0 X-Received: by 10.140.95.234 with SMTP id i97mr9983143qge.93.1411231659586; Sat, 20 Sep 2014 09:47:39 -0700 (PDT) Received: by 10.140.104.241 with HTTP; Sat, 20 Sep 2014 09:47:39 -0700 (PDT) In-Reply-To: References: <5419EE95.40600@selasky.org> Date: Sat, 20 Sep 2014 18:47:39 +0200 Message-ID: Subject: Re: [RFC] Patch to add Software/Generic Segmentation Offload (GSO) support in FreeBSD From: Stefano Garzarella To: Freddie Cash Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Hans Petter Selasky , Adrian Chadd , "freebsd-net@freebsd.org" , freebsd-current , Luigi Rizzo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Sep 2014 16:47:41 -0000 Hi Freddie, this is a preliminary version and, for now, we have not analyzed all aspects. Thanks for your suggestion. We will try to analyze how the GSO affects IPFW as soon as possible. Cheers, Stefano 2014-09-18 17:27 GMT+02:00 Freddie Cash : > On Thu, Sep 18, 2014 at 7:16 AM, Stefano Garzarella < > stefanogarzarella@gmail.com> wrote: > >> I saw the discussion about TSO, but the GSO is a software >> implementation unrelated with the hardware. >> Furthermore, if the TSO is enabled (and supported by the NIC), the GSO i= s >> not executed, because is useless. >> >> After the execution of the GSO, the packets, that are passed to the devi= ce >> driver, are smaller (or equal) than MTU, so the TSO is unnecessary. For >> this reason the GSO doesn't look neither "ifp->if_hw_tsomax" nor hardwar= e >> segment limits. >> >> The GSO is very useful when you can't use the TSO. >> > > =E2=80=8BHow does GSO affect IPFW, specifically the libalias(3)-based, in= -kernel > NAT? The ipfw(8) man page mentions that it doesn't play nicely with > hardware-based TSO, and that one should disable TSO when using IPFW NAT. > > Will the software-based GSO play nicely with IPFW NAT?=E2=80=8B Will it = make any > difference to packet throughput through IPFW? > > Or is it still way too early in development to be worrying about such > things? :) > > -- > Freddie Cash > fjwcash@gmail.com > --=20 *Stefano Garzarella* stefano.garzarella@gmail.com