Date: Mon, 31 Aug 2015 08:49:21 -0700 From: Sean Bruno <sbruno@freebsd.org> To: freebsd-arch@freebsd.org Subject: Re: Network card interrupt handling Message-ID: <55E47781.7020009@freebsd.org> In-Reply-To: <20150828184800.GE33167@funkthat.com> References: <55DDE9B8.4080903@freebsd.org> <20150828184800.GE33167@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
-----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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55E47781.7020009>