Date: Thu, 09 May 2002 18:42:43 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Peter Wemm <peter@wemm.org> Cc: Josef Karthauser <joe@tao.org.uk>, hackers@FreeBSD.ORG Subject: Re: Soft interrupts Message-ID: <3CDB2593.43E20459@mindspring.com> References: <20020510003901.085A7380A@overcee.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Wemm wrote: > You probably want to have a good look at usb_ethersubr.c - it does this > sort of thing already, but for different reasons. On FreeBSD, the usb > hardware interrupts ran (pre-SMPng) as bio, not net. All of the > assumptions, problems and workarounds for this from pre-SMPng are now > invalid or irrelevant. usb_ethersubr.c can be gutted right down now > since splnet and splbio are irrelevant. The problems that NetBSD > has to deal with are no longer the same for us. The softint stuff > is probably harmful for us because it would mean an *extra* context > switch. (from the uhci/ohci ithread to the swinet ithread). I'll second the softint stuff being a real performance pig. I answered your question, but if I was more careful, I should have spoken to the problem you seemed to be trying to solve, like Peter did. Even if you are looking at the TCP/IP stack itself, running the processing to completion at hardware interrupt time saves you a lot, including the latencey between the splx/netisr run (I meant it each time I discussed LRP on the list). IMO, the USB processing isn't performance critical in itself, but the more things that get jammed into softint processing, and the more things you register with netisr_register() (or whatever), the higher the latency. So just jamming something in there to make it look like NetBSD, if it isn't really, really important to maintain interface compatability for some reason, could hurt other users who have USB in the hardware (in theory, USB should be ripped out for rack-mount and server stuff, for the most part, but not every user builds a use-specfic kernel). For -current, you probably want to process to completion in the uhci/ohci thread, rather than delaying it as upper/lower like the NetBSD code tries to do. Are you running -current, or are you running a 4.x? It's really hard to tell, when you post on -hackers instead of -stable or -current... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CDB2593.43E20459>