Date: Fri, 4 Sep 2015 10:37:31 +0000 (UTC) From: Nomad Esst <noname.esst@yahoo.com> To: "freebsd-drivers@freebsd.org" <freebsd-drivers@freebsd.org>, FreeBSD Net <freebsd-net@freebsd.org>, Freebsd Hackers List <freebsd-hackers@freebsd.org> Subject: FreeBSD em, igb driver question Message-ID: <740628555.1564144.1441363051289.JavaMail.yahoo@mail.yahoo.com>
next in thread | raw e-mail | index | archive | help
Hi allDuring some performance tests, we found out some weird problems. We u= se a shell script that do the following : do from 1 to 10Shutdown em/igb interfacesleep 3Bring em/igb interface uptcp= replay -i em0 -l ospf_hello.pcap=C2=A0sleep3end By running this shell on one side we expect 10 ospf hello packets to get ar= rived at the other side, but tcpdump (on the other side) shows 4, sometimes= 8 and etc ... (not all 10 packets are arrived at the other side).We test t= his scenario with a Cisco router, and all packets are received at the Cisco= side. What causes this packet loss in FreeBSD (maybe in em or igb drivers)= ?I know that this scenario may not have any use in the real world, but I'm = curious, why Cisco don't have such behavior.Thanks in advance. Regards. From owner-freebsd-drivers@freebsd.org Fri Sep 4 19:22:36 2015 Return-Path: <owner-freebsd-drivers@freebsd.org> Delivered-To: freebsd-drivers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 426CF9CA2E4 for <freebsd-drivers@mailman.ysv.freebsd.org>; Fri, 4 Sep 2015 19:22:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (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 1C53A14AB for <freebsd-drivers@freebsd.org>; Fri, 4 Sep 2015 19:22:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E57B2B945; Fri, 4 Sep 2015 15:22:33 -0400 (EDT) From: John Baldwin <jhb@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-drivers@freebsd.org, Leonardo Fogel <leonardofogel@yahoo.com.br> Subject: Re: Race conditions Date: Fri, 04 Sep 2015 11:42:38 -0700 Message-ID: <1595067.LHJIsK18l7@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20150903094727.GD2072@kib.kiev.ua> References: <1439923294.98963.YahooMailBasic@web120801.mail.ne1.yahoo.com> <1619676.EuPFulsFRT@ralph.baldwin.cx> <20150903094727.GD2072@kib.kiev.ua> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 04 Sep 2015 15:22:34 -0400 (EDT) X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Writing device drivers for FreeBSD <freebsd-drivers.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-drivers>, <mailto:freebsd-drivers-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-drivers/>; List-Post: <mailto:freebsd-drivers@freebsd.org> List-Help: <mailto:freebsd-drivers-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-drivers>, <mailto:freebsd-drivers-request@freebsd.org?subject=subscribe> X-List-Received-Date: Fri, 04 Sep 2015 19:22:36 -0000 On Thursday, September 03, 2015 12:47:27 PM Konstantin Belousov wrote: > On Wed, Sep 02, 2015 at 10:59:12AM -0700, John Baldwin wrote: > > If we allow a cdevsw to override how devname works, then that would probably > > be sufficient on its own. I don't think you would need to change the > > /dev/tapX devices at all. The cdevpriv for /dev/tap desciptors would have a > > reference to the /dev/tapX device it is using and return that device's name > > in the devname override. > You mean, the consumers of tap use fdevname(3), not devname(3) ? Since > for devname(), there is no access to cdevpriv. Correct, if you open /dev/tap to get a free tap device, you want to find out which interface you actually opened, so fdevname() on the descriptor would work. If you used fstat() to extract a dev_t to pass to devname() I guess that would still just return '/dev/tap'. > > Another option that I had started to play with previously is to let devices > > auto-created by /dev/tap set an internal 'destroy-on-close' flag. That > > seems a bit more heavyweight, but it might also be simpler to implement? > > Could you, please, clarify, how this would help to handle the race at > open ? Hmm, I guess it wouldn't really help. There's just no way to reliably interlock between the clone handler and the open routine. Even with "simple" cloning I think you will always have a race in that the clone handler might create a new device to use but then fail the open. I think that from an API perspective, opening a "clone" device should never fail. Hmm, looking at /dev/ptmx, it handles this by not doing a clone on open, but instead using a d_fdopen routine and explicitly setting up the new file descriptor as if it had opened the equivalent named device. Perhaps that is what I should do instead in my tap change. If I go that route, then I think that fdevname/devname would already DTRT without needing a new cdevsw method. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?740628555.1564144.1441363051289.JavaMail.yahoo>