Caller context flags [PSARC/2007/632 FastTrack timeout 11/09/2007]
This was approved at today's PSARC meeting. I've updated the IAM file. Rich
Caller context flags [PSARC/2007/632 FastTrack timeout 11/09/2007]
Rich.Brown at Sun.COM writes: The first two new flags to be defined: #define CC_WOULDBLOCK 0x1 /* set upon return by monitor */ #define CC_DONTBLOCK0x2 /* set by caller */ The caller sets CC_DONTBLOCK in cc_flags to direct the monitor not to perform an operation that might block. In the case where a monitor would perform a blocking operation and CC_DONTBLOCK is set, the monitor sets CC_WOULDBLOCK in the cc_flags and returns EAGAIN to the caller. I'm not sure I understand how this is intended to be used. What exactly is the caller supposed to do when he gets CC_WOULDBLOCK? How long should he wait before trying again? Or is it always possible to detect this case and defer the operation until at can be run without CC_DONTBLOCK? -- James Carlson, Solaris Networking james.d.carlson at sun.com Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
Caller context flags [PSARC/2007/632 FastTrack timeout 11/09/2007]
James Carlson wrote: Rich.Brown at Sun.COM writes: The first two new flags to be defined: #define CC_WOULDBLOCK 0x1 /* set upon return by monitor */ #define CC_DONTBLOCK0x2 /* set by caller */ The caller sets CC_DONTBLOCK in cc_flags to direct the monitor not to perform an operation that might block. In the case where a monitor would perform a blocking operation and CC_DONTBLOCK is set, the monitor sets CC_WOULDBLOCK in the cc_flags and returns EAGAIN to the caller. I'm not sure I understand how this is intended to be used. It is intended to be used by callers that do not want to block inside a monitor while waiting for a delegation to be returned. What exactly is the caller supposed to do when he gets CC_WOULDBLOCK? I'm not certain that there is a general rule to follow here, however, I can give you examples of what NFS does. Each version of the NFS server will use the CC_DONTBLOCK flag on calls to VOP_READ, VOP_WRITE, VOP_SETATTR, and (in the case of v4) VOP_OPEN. When a monitor on a delegated file detects a conflict in one of the ops, it will issue a recall of the delegation and then check to see if the CC_DONTBLOCK flag is set. If it is set, it will then set the CC_WOULDBLOCK flag and return EAGAIN. When the NFSv2 server gets this, it will simply drop the response, causing the client to reissue the request. When the NFSv3 server gets the EAGAIN w/CC_WOULDBLOCK, it will return the error NFS3ERR_JUKEBOX to the client. The NFSv3 client knows to retry when it sees this error. The NFSv4 server will return NFS4ERR_DELAY when it gets this error from the monitor. How long should he wait before trying again? Or is it always possible to detect this case and defer the operation until at can be run without CC_DONTBLOCK? The way the NFSv2v3 server currently work is to use cross calls into the NFSv4 server to check if a file is delegated. If so, the delegation is recalled and the v2 v3 server do what is described above. The reason for this fast track is to allow us to remove those cross calls from the v2 v3 server and have all conflict detection handled by the monitors. The point is, the only caller that will use these flags are ones that are built to handle it. That is, if they get EAGAIN, they have a mechanism for retrying. I hope this helped. Jim
Caller context flags [PSARC/2007/632 FastTrack timeout 11/09/2007]
I'm sponsoring this fast-track for Jim Wahlig. This case seeks Minor binding.
Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI
This information is Copyright 2007 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
Caller context flags
1.2. Name of Document Author/Supplier:
Author: Jim Wahlig
1.3 Date of This Document:
02 November, 2007
4. Technical Description
One of the uses of the caller_context structure is to pass information
between the caller of a vnode operation (VOP) and a File Event Monitor
(FEM). It is used by both NFS and CIFS servers.
Monitors often need to perform operations that would block the
caller. For example, an NFSv4 delegation monitor may need to
perform an over-the-wire operation to recall a delegation. The
problem is that the caller may not be in a position to block and
has no way to communicate that state to the monitor.
Proposed Solution
This case proposes to add a flags field (cc_flags) to the caller_context
structure as well as values to communicate the behavior needed by the
caller.
The new caller context structure looks like this:
typedef struct caller_context {
pid_t cc_pid; /* Process ID of the caller */
int cc_sysid; /* System ID, used for remote calls */
u_longlong_tcc_caller_id; /* Identifier for (set of) caller(s) */
uint64_tcc_flags; -- NEW FLAG FIELD
} caller_context_t;
The first two new flags to be defined:
#define CC_WOULDBLOCK 0x1 /* set upon return by monitor */
#define CC_DONTBLOCK0x2 /* set by caller */
The caller sets CC_DONTBLOCK in cc_flags to direct the monitor not to
perform an operation that might block. In the case where a monitor would
perform a blocking operation and CC_DONTBLOCK is set, the monitor
sets CC_WOULDBLOCK in the cc_flags and returns EAGAIN to the caller.
The first consumer of this new field would be the NFS server. The flags
passed would inform the monitors on delegated files whether to wait for
the delegation to be returned or just kick off the recall and return
an error. The NFS server will set CC_DONTBLOCK to inform the
delegation monitors not to wait for a delegation to be returned when
there is a conflict. Instead, the monitors will return EAGAIN and set
the CC_WOULDBLOCK flag after issuing the delegation recall.
Exported Interfaces
||
Interface Name | Classification | Comments
=
||
CC_WOULDBLOCK | consolidation | set when returning EAGAIN to an op
| private| that would have been blocked.
||
CC_DONTBLOCK || set by caller to indicate that op's
|| should not block.
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
6.5. ARC review type: FastTrack
6.6. ARC Exposure: open
