From owner-freebsd-drivers@freebsd.org Fri Sep 4 10:43:41 2015 Return-Path: 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 C6EFA9CA2B5 for ; Fri, 4 Sep 2015 10:43:41 +0000 (UTC) (envelope-from noname.esst@yahoo.com) Received: from nm4-vm1.bullet.mail.ne1.yahoo.com (nm4-vm1.bullet.mail.ne1.yahoo.com [98.138.91.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 970758AC for ; Fri, 4 Sep 2015 10:43:41 +0000 (UTC) (envelope-from noname.esst@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1441363052; bh=3YXjyDVxosqhgiKrw6+4y5eHt9KyXAmAlUfvAcYn3Cs=; h=Date:From:Reply-To:To:Subject:From:Subject; b=QGxbJtmXPih7VwMd/5YqigktekAjDp3zSbQXQUddZfV5XIIbqGKpJ3CDLke9dDCK7gTfHOs6s5kNHDIsmS7yxwrAdTZ33JXSs+A78To1xqCjhIjH9LKAo91+xYoQVkAVo1ZtSzCKRT8ZU/Z0YGkBt3eeZFQqH2stIhp4i9kzXIcrOvAh3uL+X7qpDQpdlL2eSu2NNr5ZQFnfHGsHCVmGbHFGACIZD9nAz+ekp9R1FZ21MlPnWnMeSdmpZE0nany9JqbrvY3HemOavRLWPf2KLcuxJeF8NLrx39TlDqYo63CQ0nnur08NrQspTO/VZyqwUmhsGhqqaoFxRUOZXYnU5g== Received: from [98.138.101.132] by nm4.bullet.mail.ne1.yahoo.com with NNFMP; 04 Sep 2015 10:37:32 -0000 Received: from [98.138.87.5] by tm20.bullet.mail.ne1.yahoo.com with NNFMP; 04 Sep 2015 10:37:32 -0000 Received: from [127.0.0.1] by omp1005.mail.ne1.yahoo.com with NNFMP; 04 Sep 2015 10:37:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 176579.64844.bm@omp1005.mail.ne1.yahoo.com X-YMail-OSG: ymxtVEQVM1np.37CbZ1Ys8NXXC.st3CmV2qBc76lqrg9.U2higFhK2ljyok.1D0 b8wcF__acyeVBBlSe_ENxkMVXbz481jQ2esW48lCnCmL2DbjVXlj9vP2rZNWs6u8Sb9AXoOD5GiM phPuGTKwUqwhpSjQrvkSlef8MUzBhl_tSTpq_j5rr7_WApXRpLgKyAvjRv1nGr4tY.OscrreIdXz ViprMdG9cqiwU7CR9exkmBrGzHVr6lrln3Pml87EdiTrh2FqkOAtuqDx_cNz72pJyEd3rHt.bS4F QwyEwO.LnaEW69SA.pmgZIVqm7H2n0LKr1PQ5k6NA_CYkO5gd3GpHNh8bQF1O7suOkYOq7ubgOW1 XKHDLLBTFkXQ5QEKfrWLc_tUt4ZKA3pRd.oLhV_fsLoRNPTFDAUaziztDofahY11WErSx8X8E.rL Wj9b9mSnzcQyWtef7pjox3aE16RhWmckoGR0Ugx51nWi6qsSHMi6kA34- Received: by 98.138.105.193; Fri, 04 Sep 2015 10:37:31 +0000 Date: Fri, 4 Sep 2015 10:37:31 +0000 (UTC) From: Nomad Esst Reply-To: Nomad Esst To: "freebsd-drivers@freebsd.org" , FreeBSD Net , Freebsd Hackers List Message-ID: <740628555.1564144.1441363051289.JavaMail.yahoo@mail.yahoo.com> Subject: FreeBSD em, igb driver question MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 10:43:41 -0000 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: 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 ; 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 ; 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 To: Konstantin Belousov Cc: freebsd-drivers@freebsd.org, Leonardo Fogel 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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