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