On Tue, Jan 19, 2016 at 2:22 PM, Ryota Ozaki <ozak...@netbsd.org> wrote: (snip) >> If ether_input is going to distribute packets to other CPUs at some >> point anyway, it seems to me that it's a waste of time to do that >> twice -- aside from the issue of IPI scarcity. So perhaps we should >> have either >> >> (a) a per-CPU pktq that never distributes packets to another CPU, or >> (b) a single-CPU pktq, to be used only from the CPU to which the >> device's (queue's) interrupt handler is bound. >> >> I suppose (a) is just a softint together with a percpu(9) of ifqs, and >> (b) is just a softint together with an ifq. > > Actually the reason I used pktq was that it's the easiest way to > write a POC code for softint + percpu queues, and I didn't have > plan to utilize pktq's packet distribution feature. So not using > pktq in favor of HW multi-queue support is okay for me (for us), > at least at an first step of this work. > > I'll rewrite the patch as your suggestion (I prefer (a) for now).
Through rewriting it, I feel that it seems to be a lesser version of pktqueue. So I think it may be better changing pktqueue to have a flag to not distribute packets between CPUs than implementing another one duplicating pktqueue. Here is a patch with the approach: http://www.netbsd.org/~ozaki-r/pktq-without-ipi.diff If we call pktq_create with PKTQ_F_NO_DISTRIBUTION, pktqueue doesn't setup IPI for softint and never call softint_schedule_cpu (i.e., never distribute packets). How about the approach? ozaki-r
