From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 20:18:26 2013 Return-Path: Delivered-To: current@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 ESMTP id AAE85D7B for ; Mon, 5 Aug 2013 20:18:26 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 01D5025BE for ; Mon, 5 Aug 2013 20:18:25 +0000 (UTC) Received: (qmail 46652 invoked from network); 5 Aug 2013 20:57:41 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 5 Aug 2013 20:57:41 -0000 Message-ID: <520006FB.4010202@freebsd.org> Date: Mon, 05 Aug 2013 22:11:39 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Bryan Venteicher Subject: Re: [net] protecting interfaces from races between control and data ? References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> In-Reply-To: <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo , current@freebsd.org, net@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 20:18:26 -0000 On 05.08.2013 16:59, Bryan Venteicher wrote: > > > ----- Original Message ----- >> i am slightly unclear of what mechanisms we use to prevent races >> between interface being reconfigured (up/down/multicast setting, etc, >> all causing reinitialization of the rx and tx rings) and >> >> i) packets from the host stack being sent out; >> ii) interrupts from the network card being processed. >> >> I think in the old times IFF_DRV_RUNNING was used for this purpose, >> but now it is not enough. >> Acquiring the "core lock" in the NIC does not seem enough, either, >> because newer drivers, especially multiqueue ones, have per-queue >> rx and tx locks. >> > > What I've done in my drivers is: > * Lock the core mutex > * Clear IFF_DRV_RUNNING > * Lock/unlock each queue's lock > > The various Rx/Tx queue functions check for IFF_DRV_RUNNING after > (re)acquiring their queue lock. See at vtnet_stop_rendezvous() at > [1] for an example. > >> Does anyone know if there is a generic mechanism, or each driver >> reimplements its own way ? >> > > We desperately need a saner ifnet/driver interface. I think andre@ > had some previous work in this area (and additional plans as well?). Yes. I have received a grant from the FF to look at this in depth, evaluate different approaches and to propose an implementation for the whole stack. -- Andre > IMO, there's a lot to like on what DragonflyBSD has done in this area. > > [1] - http://svnweb.freebsd.org/base/user/bryanv/vtnetmq/sys/dev/virtio/network/if_vtnet.c?revision=252451&view=markup > >> thanks >> luigi >> _______________________________________________ >> 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" >> > _______________________________________________ > 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" > >