wrote: jamal wrote: Patch looks fine except for the 300 number. What are you smoking? Please retain the original value. The original value was 300, what d
I want to have a very high netdev_max_backlog, but that makes NAPI with the tulip driver (and 4 running ports) drop packets, I assume because by the time it polls the first 3, the 4th has been neglec
The original value was 300, what do you want it to be? (Check out what backlog defaults to, that is what is currently used for the budget, in 2.4.20-pre9 at least.) Ben -- Ben Greear <greearb@xxxxxxx
Ok, i take back what i said then. Your patch is not that useful. For some reason i thought you were introducing NET_CORE_DEV_WEIGHT which happens to already exist with default value of 64. The value
Patch looks fine except for the 300 number. What are you smoking? Please retain the original value. The original value was 300, what do you want it to be? Ok, i take back what i said then. Your patc
The 300 is shared amongst all the drivers which have something on their rx DMA. This is done on a roundrobin fashion. Also all the drivers which are non-napi are given the same quota. I think you mis
I think you misunderstood. Look at the dev->weight. Yep, I was definately confused. I don't see how changing the value as I did could affect anything in a good way, but I definately saw changes in d
tulip hardcodes it; net/core/dev.c::weight_p is supposed to be the general one and is proc settable via NET_CORE_DEV_WEIGHT; only problem is that is not shadowed by the devices. I am not sure if ioct