RE: [PATCH v2] Limit the amount of work done for each Receiver DPC

["Durrant, Paul" <pdurrant@xxxxxxxxxxxx>]

> -----Original Message-----
> From: win-pv-devel <win-pv-devel-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of 
> Martin Harvey
> Sent: 06 June 2022 13:22
> To: paul@xxxxxxx; Owen Smith <owen.smith@xxxxxxxxxx>
> Cc: win-pv-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: RE: [EXTERNAL][PATCH v2] Limit the amount of work done for each 
> Receiver DPC
> 
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open
> attachments unless you can confirm the sender and know the content is safe.
> 
> 
> 
> -----Original Message-----
> From: Durrant, Paul <xadimgnik@xxxxxxxxx>
> Sent: 06 June 2022 13:09
> To: Martin Harvey <martin.harvey@xxxxxxxxxx>; paul@xxxxxxx; Owen Smith 
> <owen.smith@xxxxxxxxxx>
> Cc: win-pv-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [PATCH v2] Limit the amount of work done for each Receiver DPC
> 
> > Yes, that is a mistake.
> >
> > I'll rebase the 2nd patch on top and let's see how that looks.
> 
> If the first is broken, the second is unlikely to be any better...
> 
> Promise the original patches were well tested, and have been quite reliable. 
> Totally happy with
> variable renames and cosmetic changes, but some of the logic to do with 
> backpressure and flushing
> deliberately overlaps from one DPC to the next, and it's not possible to 
> simplify it into "state
> depends only on this dpc".
> 
> What do you want to achieve here, and what's the best way of going about it?
> 

Each patch generally stands on its own merits and I wanted to try to get the 
incremental changes looking right; e.g. we don't introduce stack variables in 
patch 1 that aren't really needed until patch 2. I'll play with both patches 
together.

  Paul

> MH.