On 04/18/2016 09:21 AM, Matan Barak (External) wrote: > On 18/04/2016 16:04, Christoph Hellwig wrote: >> On Sun, Apr 17, 2016 at 05:08:39PM +0300, Matan Barak wrote: >>> Hi Doug, >>> >>> The mlx5 driver handles completion callbacks inside interrupts. >>> These callbacks could be lengthy and thus cause hard lockups. >>> In order to avoid these lockups, we introduce a tasklet mechanism. >>> The mlx5_ib driver uses this mechanism in order to defer its >>> completion callbacks processing to the tasklet. >>> >>> This follows the same mechanism we implemented for mlx4 that >>> successfully decreased the processing time in interrupts. >> >> Just curious: how much of this time is spent inside the mlx5 driver, >> and how much is spent in the callbacks from the consumers? We've now >> more than half done with switch the kernel ULPs to the new CQ API >> which will always offload the callbacks to softirq or workqueue context, >> so if we can avoid a previous offload the completions would be a lot >> more efficient. >> > > In short, you could hit a situation where processing the completions in > the interrupt takes longer than the rate at which they arrive (lab cases > that use one event queue, but still). > I agree that going to softirqs/WQs (like the rest of the offloads) is a > good solution too - maybe even better than this one as the mechanism > already exists, but why would it be a lot more efficient? > Given the amount of the kernel converted to the new CQ API, are you guys still looking to have this included? -- Doug Ledford <dledford@xxxxxxxxxx> GPG KeyID: 0E572FDD
Attachment:
signature.asc
Description: OpenPGP digital signature