Date: Wed, 16 May 2012 11:41:25 -0700 From: David Somayajulu <david.somayajulu@qlogic.com> To: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, "freebsd-current@freebsd.org (freebsd-current@FreeBSD.org)" <freebsd-current@FreeBSD.org>, "freebsd-drivers@freebsd.org" <freebsd-drivers@freebsd.org> Cc: "davidcs@FreeBSD.org" <davidcs@FreeBSD.org> Subject: Ethernet Drivers: Question on ifp->if_ioctl invocation for SIOCADDMULTI and SIOCDELMULTI Message-ID: <75E1A2A7D185F841A975979B0906BBA67C7A229F49@AVEXMB1.qlogic.org>
next in thread | raw e-mail | index | archive | help
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 ca=
ller 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 =3D in_joingroup_locked(ifp, gina, imf, pinm);
1105 IN_MULTI_UNLOCK();
1106
This is also the case for SIOCDELMULTI, where the function holding "in_mul=
ti_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 sta=
te.
Question:
1. If I want to implement any delays - for the above case - in the dr=
iver using DELAY(usec) macro, is there a maximum amount of time that the dr=
iver 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 thre=
ad which can sleep() ?
Thanks
David S.
________________________________
This message and any attached documents contain information from QLogic Cor=
poration or its wholly-owned subsidiaries that may be confidential. If you =
are not the intended recipient, you may not read, copy, distribute, or use =
this information. If you have received this transmission in error, please n=
otify the sender immediately by reply e-mail and then delete this message.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?75E1A2A7D185F841A975979B0906BBA67C7A229F49>