| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] [PATCH] Register watches for frontend features.
> -----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
|
|
|
| |
|
Home