Re: RFC: softint-based if_input

[Ryota Ozaki <ozaki-r%netbsd.org@localhost>]

On Tue, Jan 19, 2016 at 2:22 PM, Ryota Ozaki <ozaki-r%netbsd.org@localhost> 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