Re: [Xen-devel] [PATCH v4 10/14] argo: implement the notify op

[Christopher Clark <christopher.w.clark@xxxxxxxxx>]

On Fri, Jan 18, 2019 at 3:54 PM Christopher Clark
<christopher.w.clark@xxxxxxxxx> wrote:
>
> On Fri, Jan 18, 2019 at 1:44 AM Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
> >
> > On Thu, Jan 17, 2019 at 01:44:32PM -0800, Christopher Clark wrote:
> > > On Thu, Jan 17, 2019 at 3:12 AM Roger Pau Monné <roger.pau@xxxxxxxxxx> 
> > > wrote:
> > > >
> > > > On Wed, Jan 16, 2019 at 10:54:48PM -0800, Christopher Clark wrote:
> > > > > On Tue, Jan 15, 2019 at 8:19 AM Roger Pau Monné 
> > > > > <roger.pau@xxxxxxxxxx> wrote:
> > > > > >
> > > > > > On Tue, Jan 15, 2019 at 01:27:42AM -0800, Christopher Clark wrote:

> New Situation 4 is:
>
> 4. Message doesn't fit based on the current available space on the ring,
> but Xen can't queue up a VIRQ for later because memory allocation to
> add an entry for that failed. Don't set NOTIFY.

I should add: there's an additional error condition for Situation 4 besides
memory allocation failure: the ring could have reached the maximum
number of pending space_available signals in its list, which would cause
ENOSPC as another possible error value returned there.

>
> We ought to enable the guest to distinguish Situation 2 from Situation 4
> -- which I think points to keeping the separate flags.
>
> > So that would leave the following set of flags:
> >
> > /* Ring is empty. */
> > #define XEN_ARGO_RING_EMPTY       (1U << 0)
> > /* Ring exists. */
> > #define XEN_ARGO_RING_EXISTS      (1U << 1)
> > /*
> >  * Not enough ring space available for the requested size, caller set
> >  * to receive a notification via VIRQ_ARGO when enough free space
> >  * might be available.
> >  */
> > #define XEN_ARGO_RING_NOTIFY      (1U << 2)
> > /* Requested size exceeds maximum ring message size. */
> > #define XEN_ARGO_RING_EMSGSIZE    (1U << 3)
> > /* Ring is shared, not unicast. */
> > #define XEN_ARGO_RING_SHARED      (1U << 4)
> >
> > Note that I've also removed the _DATA_F_, I think it's not specially
> > helpful, and shorter names are easier to read.
>
> Ack - done.
>
> >
> > I think the above is clearer and should be able to convey the
> > same set of information using one flag less, which is always better
> > IMO. That being set I don't know the users of this interface anyway,
> > so if you think the original proposal is better I'm not going to
> > oppose.
>
> ok -- let me know your view given the description of Situation 4 above.
> I've kept it unchanged for the time being.
>
> Christopher

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel