On Fri, Apr 22, 2011 at 12:59 AM, Roberto Riggio < [email protected]> wrote:
> Il 22/04/2011 09:31, Cliff Frey ha scritto: > > Oh yes, sorry for misunderstanding. >> >> We actually had issues with KernelTun. We ended up adding a BURST >> parameter to it. There are weird interactions between selected() and tasks >> where selected() does not get called as often as one might hope. You could >> also try changing the _tasks_per_iter to be much much lower (like 2) and see >> if it helps... >> > > what is the meaning of the _tasks_per_iter variable? Which are the > sideeffects of lowering it? Does it means that tasks (and timers???) will be > checked fewer times > per iteration allowing click to schedule also (for example) the kerneltun > element? I'm not positive off the top of my head, would need to look at the source, but essentially yes, I think it is the number of task runs between checking timers/select(). > I can look into giving you an updated KernelTun with a BURST param if you >> are interested, but it might take me a few days to get to it. >> > Shall the BURST param allow to iterate N times over this > > int cc = read(_fd, p->data(), _mtu_in); > > and the following if block in KernelTun::selected? > Give or take, yes. It also needs to create a new packet each time. You also need to ignore EAGAIN (well, break out of the loop, but don't print anything or treat it as an error). Cliff _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
