Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 05 Aug 2013 22:11:39 +0200
From:      Andre Oppermann <andre@freebsd.org>
To:        Bryan Venteicher <bryanv@daemoninthecloset.org>
Cc:        Luigi Rizzo <rizzo@iet.unipi.it>, current@freebsd.org, net@freebsd.org
Subject:   Re: [net] protecting interfaces from races between control and data ?
Message-ID:  <520006FB.4010202@freebsd.org>
In-Reply-To: <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org>
References:  <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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"
>
>




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?520006FB.4010202>