lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dc98e4d7-b076-66ca-a22f-5199b6d13ea9@mojatatu.com>
Date:   Tue, 1 Nov 2016 07:38:49 -0400
From:   Jamal Hadi Salim <jhs@...atatu.com>
To:     David Miller <davem@...emloft.net>, make0818@...il.com
Cc:     stephen@...workplumber.org, netdev@...r.kernel.org
Subject: Re: Why do we need tasklet in IFB?

On 16-10-31 02:10 PM, David Miller wrote:
> From: Michael Ma <make0818@...il.com>
> Date: Mon, 31 Oct 2016 11:02:28 -0700
>
>> 2016-10-28 14:52 GMT-07:00 Michael Ma <make0818@...il.com>:
>>> 2016-10-28 14:48 GMT-07:00 Stephen Hemminger <stephen@...workplumber.org>:
>>>> On Fri, 28 Oct 2016 14:45:07 -0700
>>>> Michael Ma <make0818@...il.com> wrote:
>>>>
>>>>> 2016-10-28 14:38 GMT-07:00 Stephen Hemminger <stephen@...workplumber.org>:
>>>>>> On Fri, 28 Oct 2016 14:36:27 -0700
>>>>>> Michael Ma <make0818@...il.com> wrote:
>>>>>>
>>>>>>> Hi -
>>>>>>>
>>>>>>> Currently IFB uses tasklet to process tx/rx on the interface that
>>>>>>> forwarded the packet to IFB. My understanding on why we're doing this
>>>>>>> is that since dev_queue_xmit() can be invoked in interrupt, we want to
>>>>>>> defer the processing of original tx/rx in case ifb_xmit() is called
>>>>>>> from interrupt.
>>>>>>
>>>>>> dev_queue_xmit is only called from interrupt if doing netconsole.
>>>>>
>>
>> In fact this doesn't seem to explain since if the original path is tx
>> and the context is interrupt, IFB will call dev_queue_xmit as well so
>> the context can be interrupt in that case.
>>
>> Then tasklet is still unnecessary.
>
> Perhaps it's necessary to deal with potential recursion, that's my only
> guess at this point.
>
> Jamal, do you remember what went through your mind back in 2005? :-)
>

Certainly recursions (which were a huge issue in the original
implementations) as well as the need to have qdisc which shape traffic
(which implies they will sit on the queue for some period of time and
where accuracy of timing is important; therefore low latency of
scheduling was  needed).

I didnt follow the context of "tasklets are unnecessary":
Are tasklets bad or is the OP interested in replacing them with
something s/he thinks is better? IIRC, at some point the idea was to
infact use a softirq but it became obvious it was overkill.

cheers,
jamal

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ