Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 17 May 2012 10:33:37 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        freebsd-drivers@freebsd.org
Cc:        "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, "freebsd-current@freebsd.org \(freebsd-current@FreeBSD.org\)" <freebsd-current@freebsd.org>, "davidcs@FreeBSD.org" <davidcs@freebsd.org>
Subject:   Re: Ethernet Drivers: Question on ifp->if_ioctl invocation for SIOCADDMULTI and SIOCDELMULTI
Message-ID:  <201205171033.37636.jhb@freebsd.org>
In-Reply-To: <75E1A2A7D185F841A975979B0906BBA67C7A229F49@AVEXMB1.qlogic.org>
References:  <75E1A2A7D185F841A975979B0906BBA67C7A229F49@AVEXMB1.qlogic.org>

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



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