Ethernet Drivers: Question on ifp->if_ioctl invocation for
SIOCADDMULTI and SIOCDELMULTI
John Baldwin
jhb at freebsd.org
Thu May 17 15:00:42 UTC 2012
On Wednesday, May 16, 2012 2:41:25 pm David Somayajulu wrote:
> Hi All,
> When ifp->if_ioctl() is invoked for the ioctl cmd SIOCADDMULTI,
>
>
>
> IN_MULTI_LOCK() is called in one of the functions in_joingroup() in the
caller stack.
>
>
>
> >From netinet/in_var.h, line 357 : #define IN_MULTI_LOCK()
mtx_lock(&in_multi_mtx)
>
>
>
> >From netinet/in_mcast.c
> 1098 in_joingroup(struct ifnet *ifp, const struct in_addr *gina,
> 1099 /*const*/ struct in_mfilter *imf, struct in_multi **pinm)
> 1100 {
> 1101 int error;
> 1102
> 1103 IN_MULTI_LOCK();
> 1104 error = in_joingroup_locked(ifp, gina, imf, pinm);
> 1105 IN_MULTI_UNLOCK();
> 1106
>
> This is also the case for SIOCDELMULTI, where the function holding
"in_multi_mtx" lock is in_leavegroup()
>
> This poses a problem in the driver in that the hardware dependent function
performing it, is not allowed to sleep() in case it needs to poll some state.
>
> Question:
>
> 1. If I want to implement any delays - for the above case - in the
driver using DELAY(usec) macro, is there a maximum amount of time that the
driver is allowed to complete this function? I am concerned that if it takes
to too long I might run into a soft_lockup() situation.
>
> 2. Is it o.k to defer the processing in a separate in a separate
thread which can sleep() ?
You can always queue a task to update the MAC table if you need to use a
sleep.
--
John Baldwin
More information about the freebsd-current
mailing list