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>
index | next in thread | raw e-mail
Hi allDuring some performance tests, we found out some weird problems. We use a shell script that do the following : do from 1 to 10Shutdown em/igb interfacesleep 3Bring em/igb interface uptcpreplay -i em0 -l ospf_hello.pcap sleep3end By running this shell on one side we expect 10 ospf hello packets to get arrived 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 this 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 Baldwinhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?740628555.1564144.1441363051289.JavaMail.yahoo>