Network card interrupt handling

[Sean Bruno]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512




> I have a better question, for MSI-X, we have a dedicated interrupt 
> thread to do the processing, so why are we even doing any
> moderation in this case?  It's not any different than spinning in
> the task queue..
> 
> How about the attached patch that just disables taskqueue
> processing for MSI-X RX interrupts, and does all processing in the
> interrupt thread?

This is another design that I had thought of.  For em(4) when using
seperate ISR threads for *each* rx queue and *each* tx queue, I think
that doing processing in the interrupt thread is the right thing to do.

I'm unsure of what the correct thing to do when tx/rx is combined into
a single handler though (igb/ix for example).  This would lead to
possible starvation as Adrian has pointed out.  There is nothing
stopping us from breaking the queues apart into seperate tx/rx threads
of execution for these drivers.  em(4) was my little science project
to see what the behavior would be.

> 
> Do you need to add the rx_task to the em_local_timer?  If so, then 
> I would look at setting a flag in the _rxeof that says that
> processing is happening... and in the case of the taskqueue, when
> it sees this flag set, it just exits, while for the interrupt
> filter case, we'd need to be more careful (possibly set a flag that
> the taskqueue will inspect, and cause it to stop processing the rx
> queue)...
> 

^^ I'll ponder this a bit further today and comment after coffee.

> btw, since you're hacking on em a lot, interrested in fixing em's 
> jumbo frames so it doesn't use 9k clusters, but instead page sized 
> clusters?
> 
> 

Uh ... hrm.   I can look into it, but would need more details as I'm
pretty ignorant of what you're referring to.  Ping me off list and
I'll take a look (jumbo frames is out of scope for $dayjob).

sean
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQF8BAEBCgBmBQJV5Hd+XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx
MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kL4wH/AmMvnZ7EKfF04qKhUxdOA90
YN5OZpyeXc8zk0QUq+INNMIHiQJN1wCHiOVd46YIuwjdWeSvHxKgnJMV1whDod55
c4QO6WG5yRcP5Wl30YN5XhjfUW48MYytYXxlAY5cC5A+TIUq/HywSNmyEVxKAooY
lSw+8Zpdzaozv1LxS70bRggi9y/y5NEgcVViO1cjip+nkl3eNvYOFq5jp2KJc0vS
+oe/wqbF5syRiBO4R2XnJs6PJ9BALOF73pFteHBebAe5jUwt6UD17c35/I2B4v60
+zNuM3rdNdDCOecFEdFctOQe6XDpSAu6Q7Dv88SKoKeIs+2lXHD/AJf24heTQOg=
=oY0k
-----END PGP SIGNATURE-----