On Thu, 30 Jul 2020 22:43:10 +0300
Vitaliy Makkoveev <[email protected]> wrote:
> On Thu, Jul 30, 2020 at 10:05:13PM +0900, YASUOKA Masahiko wrote:
>> On Thu, 30 Jul 2020 15:34:09 +0300
>> Vitaliy Makkoveev <[email protected]> wrote:
>> > On Thu, Jul 30, 2020 at 09:13:46PM +0900, YASUOKA Masahiko wrote:
>> >> If the diff removes the queue, then the pipex input routine is
>> >> executed by the NIC's interrupt handler.
>> >>
>> >> The queues had been made to avoid that kind of situations.
>> >
>> > It's not enqueued in pppoe case. According pipex_pppoe_input() code we
>> > call pipex_common_input() with `useq' argument set to '0', so we don't
>> > enqueue mbuf(9) but pass it to pipex_ppp_input() which will pass it to
>> > ipv{4,6}_input().
>>
>> You are right. Sorry, I forgot about this which I did that by myself.
>
> I'm interesting the reason why you did that.
I remembered, it was first step of MP steps for pipex.
At that time, I discussed with mpi, he suggested like below.
1. stop enqueueing packets for PPPoE
2. try not take a kernel lock before calling gre_input(), then we can
also stop enqueueing packets for PPTP(GRE)
3. for L2TP, keep the queue and change the netisr to an unlocked task
