Hiten Pandya wrote: > > If someone with a Tigon III card could try the patch with the > > DEVICE_POLLING option enabled, and device polling turned on, > > and let us know that the card keeps functioning, rather than > > them getting a panic, then that would be enough, I think, to > > say "commit it". > > I think the Device Polling sysctls will need tuning, if I am > thinking straightly. No?
You can control it with IFF_POLLING. But that's only good if the code in the interrupt routine, init routine, and, in the if_ti case, the ti_rxeof routine isn't broken. It's incredibly trivial code, but the fact that it's in the default interrupt path, if the kernel was compiled with the DEVICE_POLLING option, even if it's not set on the interface, means the risk is too high for a blind commit this close to a release. The correct thing to have done is probably to add an entry point into the DEVMETHOD table for the rxeof and txeof, and a polling init routine, and a polling routine, to avoid having to wedge the ether_poll register into the init routine of drivers which support polling. And then seperate out the interrupt enabling/disabling code as DEVMETHOD entry points as well. A side effect of this would be to remove a measurable amount of overhead from the interrupt handlers of drivers that support DEVICE_POLLING, but don't have it enabled on the card. Doing this would allow for automatic support for DEVICE_POLLING for all drivers, without the device_polling function call and compare overhead on each interrupt, in the non-polling case. Turning it on/off via sysctl also requires these changes, as does turning it off via ifconfig, since a poll is required after that to take care of data that arrived before interrupts were enabled, and failed to generate an interrupt, and so will never result in the data being reaped (this is a bug in the polling disabling case for all DEVICE_POLLING code, right now). This would also allow the implementation of soft interrupt coelescing at a higher layer, for all drivers... that only assumes that all drivers are munged to add rxeof/txeof DEVMETHODs, so it could be done without supporting DEVICE_POLLING everywhere. Basically, this would mean changing all the drivers to match Bill Paul's template (seperate rxeof/txeof routines), which most older drivers don't do, and which had bus overhead for some other drivers, and then exposing the routines as part of the formal interface. None of this is stuff that would make it past the release engineers in time for inclusion in 5.0, but an tested if_ti patch might. So I only did an if_ti patch. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
