Subject: Re: [nfsv4] SET_PRIORITY: new op proposal

From: Trond Myklebust <[email-masked]>
Date: Thu, 01 Mar 2007 00:21:07 -0500

On Wed, 2007-02-28 at 07:48 -0800, Mike Eisler wrote:
> --- "Talpey, Thomas" <[email-masked]> wrote:
> 
> > At 11:06 PM 2/27/2007, Mike Eisler wrote:
> > >that. With sessions a session can be tagged, and all the connections
> > >bound it serviced in higher priority. 
> > 
> > Yipes - does this proposal allow each request (or session) to
> > *globally*
> > specify its priority? Holy denial of service, Batman.
> 
> 
> Servers don't have to allow clients to set higher, service
> denying priorities, if they don't want to.
> 
> Besides which, AUTH_SYS is the ultimate in denial of service,
> and who cares? :-) 
> > 
> > I still want to see the server's MUSTs and SHOULDs w.r.t the
> > client-specified
> > priority. If everything is a MAY, then I think we should ask
> > ourselves a) what
> > good is it and b) why are we adding it now.
> 
> How about this:
> 
> Priority is a 32 bit signed integer.
> 
> Zero means the peer doesn't care.  1 is the base
> priority. Priorities other than "don't care" are in the
> set { ..., -3, -1, 1, 3, ... } The higher the number,
> the higher the priority.
> 
> Clients and servers MAY implement per-session priority. If
> they do not, they express priority with the zero value.

So I should always set priority 2^31-1 in order to ensure that my
clients will always get the best performance in reviews, right?

Trond

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Mike Eisler <[email-masked]>
Date: Thu, 1 Mar 2007 02:28:53 -0800 (PST)

> clients will always get the best performance in reviews, right?

Incorrect.

mre>  At CREATE_SESSION time, the client offers two priorities,
mre>  one for the back channel, one for the fore channel, and
mre>  the server responds with confirmed values. The server MAY
mre>  override the fore channel priority with any value. The
mre>  server MUST NOT override the back channel priority, except
mre>  if it is not implementing priority, in which case it MAY
mre>  set the back channel priority to zero.

So a server that received a request for a priority of 2^32-1 would
likely reset it to 1 or 0.

There was also stuff in my write up about the server have
policies to allow some clients to set priorities above the base.

---

From: Mike Eisler <[email-masked]>
Date: Thu, 1 Mar 2007 16:08:50 -0800 (PST)

I see no rough consensus to add priorities to NFSv4.1.
Spencer Shepler and Dave Noveck concur. So draft-09 will not
support priorities, which means NFSv4.1 will not have them.

I've asked Spencer to submit draft-09 as soon as possible.

---

From: Benny Halevy <[email-masked]>
Date: Fri, 02 Mar 2007 09:48:02 +0200

> I've asked Spencer to submit draft-09 as soon as possible.

OK.
Do we keep anywhere a laundry list for 4.2 feature candidates?

Benny

---

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 2 Mar 2007 07:25:24 -0500

We could deal this by creating an issue on the editor web 
site and marking it with a v4.2 keyword.  The state can 
be resolved-no-change (for v4.1) for now. 

-----Original Message-----
From: Benny Halevy [mailto:[email-masked]] 
Sent: Friday, March 02, 2007 2:48 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [nfsv4] SET_PRIORITY: new op proposal

Mike Eisler wrote:
> Spencer Shepler and Dave Noveck concur. So draft-09 will not support 
> priorities, which means NFSv4.1 will not have them.
> 

OK.

Benny