Hi
I poll my driver every 10 ms for a frame. There seems to be another way, you have to supply the adapter with multiple buffers and later on see to it that the card does not exhaust them and although I am perfectly happy with a polling solution, I got curious if my solution is significantly slower so I come here to listen for your opinions.
A great delay might be annoying, like if the driver was polled once each second when you played a shooter game online. A very small delay might introduce large overheads to the processing. And still, a 10 ms latency time is a lot when you want to host a router.
Do you find 10 ms reasonable?
Cheers
ethernet frame reception through polling
Re: ethernet frame reception through polling
10ms is probably fine as long as you have a big enough packet threshold and buffers space. I personally would poll faster than that, but I don't know what you are intending to use this for (network intessive or not). Also, save some CPU processing by testing buffer bits to see if there are packets buffered, and if not, the CPU doesnt have to keep executing driver functions after that.
Website: https://joscor.com
Re: ethernet frame reception through polling
Wow, I figured out my scheduler starves threads very easily; a trivial use of locks (a _TRIVIAL_ use) made me get priority inversion. Bad luck, gotta go for round robin temporarily.
As for the driver, the thread indeed checks an inb() value for availlable packets so it doesn't do a lot when no packets are waiting, but there are a couple of function calls - I've never really checked out how costly are function calls - are they?
Anyways what I missed here is that my scheduler code may not be able to run the thread each 10 msecs, it just guarantees it's at least 10 msecs between each run. And secondly I believe that my card drops packets when it's got one in buffer so I'll go for multiple buffers + no thread + job done in irq any way.
As for the driver, the thread indeed checks an inb() value for availlable packets so it doesn't do a lot when no packets are waiting, but there are a couple of function calls - I've never really checked out how costly are function calls - are they?
Anyways what I missed here is that my scheduler code may not be able to run the thread each 10 msecs, it just guarantees it's at least 10 msecs between each run. And secondly I believe that my card drops packets when it's got one in buffer so I'll go for multiple buffers + no thread + job done in irq any way.