RE: [Xen-devel] [PATCH] Register watches for frontend features.

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jeremy Fitzhardinge [mailto:jeremy@xxxxxxxx]
> Sent: 07 July 2010 19:11
> To: Paul Durrant
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Ian Campbell
> Subject: Re: [Xen-devel] [PATCH] Register watches for frontend
> features.
> 
> On 07/05/2010 04:39 AM, Paul Durrant wrote:
> > Frontend features are currently only sampled at ring connection
> time.
> > Some frontends can change these features dynamically so watches
> should
> > be used to update the corresponding netback flags as and when they
> > change.
> >
> 
> Are there any concerns about these feature flags changing
> asynchronously?
> 
> The watches will run in their own task, and so can be concurrent to
> the
> netback code using the flags.  What prevents that from upsetting the
> tests of the flags in, for example, netbk_max_required_rx_slots?
> Should
> there be some locking?  Or double-buffer the feature flags so that
> the
> netback code can get updated values at a safe/appropriate time?
> 
> Can all features be changed dynamically by the frontend, or just
> some?
> 

Realistically, with a Windows frontend, the only ones that are going to change 
dynamically are gso_prefix and csum. I can 'de-watch' the others, if you'd 
prefer.
As for locking, it's not clear to me how fatal getting 
netbk_max_required_rx_slots wrong is. However, losing or gaining gso/gso_prefix 
part way through a receive is not going to be good so I thing some double 
buffering is probably called for. I'll re-work the patch accordingly.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel