Architecture - User Level Access - Revision history

Docadmin at 21:25, 22 January 2010

2010-01-22T21:25:01Z

← Older revision		Revision as of 14:25, 22 January 2010
Line 1:		Line 1:
	'''''Note:''''' The content on this page reflects the state of design of a Lustre feature at a particular point in time and may contain outdated information.		'''''Note:''''' ''The content on this page reflects the state of design of a Lustre feature at a particular point in time and may contain outdated information.''

	== Summary ==		== Summary ==

Docadmin: Protected "Architecture - User Level Access" ([edit=sysop] (indefinite) [move=sysop] (indefinite))

2010-01-22T19:22:54Z

Protected "Architecture - User Level Access" ([edit=sysop] (indefinite) [move=sysop] (indefinite))

← Older revision	Revision as of 12:22, 22 January 2010
(No difference)

Docadmin at 00:21, 19 January 2010

2010-01-19T00:21:53Z

← Older revision		Revision as of 17:21, 18 January 2010
Line 1:		Line 1:
			'''''Note:''''' The content on this page reflects the state of design of a Lustre feature at a particular point in time and may contain outdated information.

	== Summary ==		== Summary ==
	The LNET userspace API driver exports the LNET API to userspace so that userspace lustre servers and clients can use all existing kernel LNET infrastructure.		The LNET userspace API driver exports the LNET API to userspace so that userspace lustre servers and clients can use all existing kernel LNET infrastructure.

Docadmin: /* References */

2010-01-15T00:05:37Z

References

← Older revision		Revision as of 17:05, 14 January 2010
Line 26:		Line 26:

	; Resource Limits : LNET kernel module parameters allow resource limits (e.g. extant PIDs, MEs, MDs, concurrent GETs and PUTs) to be set for two classes of user: privileged and unprivileged. These limits include global maxima to limit the total resource that either class of process may use in aggregate. Either class may be set to infinity or zero. The normal "getrlimit" resource limits will apply to pages associated with MDs.		; Resource Limits : LNET kernel module parameters allow resource limits (e.g. extant PIDs, MEs, MDs, concurrent GETs and PUTs) to be set for two classes of user: privileged and unprivileged. These limits include global maxima to limit the total resource that either class of process may use in aggregate. Either class may be set to infinity or zero. The normal "getrlimit" resource limits will apply to pages associated with MDs.

	~~== References ==~~
	~~[[category:Architecture\|User Level Access]]~~

Docadmin: moved User Level Access to Architecture - User Level Access

2010-01-14T21:19:01Z

moved User Level Access to Architecture - User Level Access

← Older revision	Revision as of 14:19, 14 January 2010
(No difference)

Docadmin: 1 revision

2010-01-14T21:01:06Z

1 revision

← Older revision	Revision as of 14:01, 14 January 2010
(No difference)

Eeb at 18:43, 10 August 2007

2007-08-10T18:43:21Z

New page

== Summary ==
The LNET userspace API driver exports the LNET API to userspace so that userspace lustre servers and clients can use all existing kernel LNET infrastructure.

== Requirements ==
; LNET API : Userspace processes can use the LNET API transparently to communicate with other processes of all flavours.

; Multi-user : LNET users are distinguished by LNET PID. This PID may be shared by several O/S processes which may in turn be multi-threaded. Processes sharing the same LNET PID may share ME, MD and EQ handles. Kernel threads all share the same PID.

; PID assignment : PID is requested in LNetNIInit(). If this is LNET_PID_ANY, a new unique PID is created and given the real userid of the caller. If the requested PID exists already, the caller may be permitted to join it. If it does not exist, the caller may be permitted to create it.

; Privilege : Privileged users may create or join any PID. Unprivileged users must set the "userflag" when requesting a PID and my only join an existing PID if the caller's real userid matches the PID's userid.

; Isolation : Replies, acks and events for a given PID are isolated from other PIDs, including future incarnations of the same PID.

; Cleanup : A PID is destroyed when all its processes have finalized or terminated. At this time, all outstanding communications are completed with failure in finite time and all associated state is freed.

; Parameter checking : NO userspace LNET API parameters are trusted. Checking may occur at any time - e.g. invalid buffer addresses may be discovered when a communication completes rather than when it was initiated.

; Memory : User pages bound to an MD are locked down until the MD has been destroyed.

; EQ Callbacks : EQ callbacks in userspace are not supported. Userspace processes may dedicate one or more threads to process events eagerly.

; Thread safety : All exported LNET API calls are thread-safe.

; Zero-copy : Communications to/from userspace buffers are zero-copy where the kernel LND supports it.

; Resource Limits : LNET kernel module parameters allow resource limits (e.g. extant PIDs, MEs, MDs, concurrent GETs and PUTs) to be set for two classes of user: privileged and unprivileged. These limits include global maxima to limit the total resource that either class of process may use in aggregate. Either class may be set to infinity or zero. The normal "getrlimit" resource limits will apply to pages associated with MDs.

== References ==
[[category:Architecture|User Level Access]]