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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 31 May 2022 11:19:49 -0700
From:   Allen Pais <>
To:     Arnd Bergmann <>
Cc:     Vinod Koul <>,
        Linus Walleij <>,
        Vincent Guittot <>,, Stefan Roese <>,
        Kees Cook <>,,
        Ludovic Desroches <>,
        Tudor Ambarus <>,
        Florian Fainelli <>,
        Ray Jui <>,
        Scott Branden <>,
        bcm-kernel-feedback-list <>,
        Nicolas Saenz Julienne <>,
        Paul Cercueil <>,,
        Gustavo Pimentel <>,
        Viresh Kumar <>,
        Andy Shevchenko <>,
        Leo Li <>,,
        Zhou Wang <>,
        Shawn Guo <>,
        Sascha Hauer <>,
        Sean Wang <>,
        Matthias Brugger <>,
        Andreas Färber <>,
        Manivannan Sadhasivam <>,
        Logan Gunthorpe <>,
        Sanjay R Mehta <>,
        Daniel Mack <>,
        Haojian Zhuang <>,
        Robert Jarzmik <>,
        Andy Gross <>,
        Bjorn Andersson <>,
        Krzysztof Kozlowski <>,, Orson Zhai <>,
        Baolin Wang <>,
        Lyra Zhang <>,
        Patrice CHOTARD <>,
        Chen-Yu Tsai <>,
        Jernej Škrabec <>,
        Samuel Holland <>,,
        Linux Kernel Mailing List <>
Subject: Re: [RFC 1/1] drivers/dma/*: replace tasklets with workqueue

> [note: something is wrong with your email client, your previous reply appears to
> be in HTML]
  Sorry, fixed it.

>>> That is a good idea, lot of drivers are waiting for completion which can
>>> be signalled from hardirq, this would also reduce the hops we have and
>>> help improve latency a bit. On the downside, some controllers provide
>>> error information, which would need to be dealt with.
>>   I am not an expert in dma subsystem, but by using completion from
>> Hardirq context be a concern? Especially with latency.
> I don't see how: to the task waiting for the completion, there should
> be no difference, and for the irq handler sending it, it just avoids
> a few cycles going into softirq context.

  Thanks for clarification. 

  If I have understood it correctly, your suggestion is to move the current
Callback mechanism out to dmaengine as a generic helper function
And introduce completion in dma_async_tx_descriptor to handle what
Tasklets currently do.


>>> Yes that would be a very reasonable mechanism, thanks for the
>>> suggestions.
>>  I have started working on the idea of global softirq. A RFC should be ready
>> For review soon.
> Ok, thanks!
>       Arnd

Powered by blists - more mailing lists