Re: KPI Interface filter and filter detachment
Re: KPI Interface filter and filter detachment
- Subject: Re: KPI Interface filter and filter detachment
- From: Josh Graessley <email@hidden>
- Date: Fri, 3 Feb 2006 09:10:43 -0800
As currently implemented, the iff_input callback is most likely to
occur on the dlil input thread. Your callback for handling data sent
on a kernel control socket will occur on the thread that calls send/
sendmsg/sendto. These are two different threads.
The implementation may change in the future. You need to be very
careful. One day there may be multiple input threads. Other changes
are possible too. Too avoid headaches, you need to be very careful
with your locking. Lock only while manipulating shared data
structures. Never hold a lock while calling back in to the stack, you
never know when the stack might turn around and call your kext. While
using sockets inside of the kernel, never close the socket while
another thread may be performing an operation on that socket (send/
recv/sockopt).
Also, be very conscious of the performance impact of your kext.
netperf is a decent tool for testing throughput. As you develop your
kext, try running netperf with and without your kext to see what
impact you're having. Gigabit is pretty dang fast, and 10 gigabit is
just ridiculously fast. It doesn't take much to hose your throughput
on networks running at those speeds.
-josh
On Feb 3, 2006, at 7:15 AM, Stephane Sudre wrote:
OK, so this would not explain a recursive lock attempt.
Mmm, is it possible for a kernel control message to be received when
you are within a iff_input callback? I would say yes. But would it
be considered the same "thread" or not?
On 2 févr. 06, at 20:29, Josh Graessley wrote:
I believe the detach is a special case. The detach is there to
notify you that your filter has been detached. In this case, that
is the last call you will receive and it should only happen when we
are not calling any other entry points in your filter for that
interface.
-josh
On Feb 2, 2006, at 9:36 AM, Stephane Sudre wrote:
Maybe someone can shed some light on this.
Let's say a KPI Interface filter is attached to every available
interfaces.
Let's say this KPI Interface filter is implementing a iff_input
callback.
the callback can be sum-up to:
myCallBack
{
mutex lock
do something but never return anything
mutex unlock
return a value
}
now at one point an interface is going away => a detach filter is
called.
Question:
can the detach filter (iflt_detach) be called while we are in
myCallBack?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden