Lines Matching full:backend

17  * Older implementation of Xen network frontend / backend has an
20  * expected when frontend and backend have different MAX_SKB_FRAGS.
25  * slots backend must support.
28  * (18), which is proved to work with most frontends. Any new backend
38  * feature 'feature-rx-notify' via xenbus. Otherwise the backend will assume
44  * and RX notification. Backend either doesn't support this feature or
48  * channels for TX and RX, advertise them to backend as
56  * If supported, the backend will write the key "multi-queue-max-queues" to
61  * must be greater than zero, and no more than the value reported by the backend
72  * ring-ref keys are written as before, simplifying the backend processing
95  * If there is any inconsistency in the XenStore data, the backend may
101  * transmitting system (backend or frontend) and is not negotiated
124  * backend. If the frontend wishes to take advantage of this feature then
125  * it may set "request-multicast-control". If the backend only advertises
127  * before the frontend moves into the connected state. The backend will
129  * value will have no effect. However, if the backend also advertises
131  * may be set by the frontend at any time. In this case, the backend will
135  * backend transmit side should no longer flood multicast packets to the
165  * backend. Use of xenstore is not suitable for large quantities of data
167  * The ability of the backend to use a control ring is advertised by
170  * /local/domain/X/backend/<domid>/<vif>/feature-ctrl-ring = "1"
172  * The frontend provides a control ring to the backend by setting:
413  *       hashing and the backend is free to choose how it steers packets
420  * the backend.
441  * This is sent by the frontend to set the types of hash that the backend
467  *       Also, setting data[0] to zero disables hashing and the backend
490  *                                                     than the backend
500  *       The maximum size of key is algorithm and backend specific, but
509  * table supported by the backend. The size is specified in terms of
532  * table to be used by the backend. The size is specified in terms of
559  * hash value to queue number. The backend should calculate the hash from
579  *                                                     than the backend
600  *       The backend may support a mapping table larger than can be
617  * This is the 'wire' format for transmit (frontend -> backend) packets:
636  * (backend -> frontend) packets. Specifically, in a multi-fragment
675  * This is the 'wire' format for receive (backend -> frontend) packets:
694  * (frontend -> backend) packets. Specifically, in a multi-fragment
744  *       consumed to make the slot available, and the backend must ensure
796  * A backend that supports teoplitz hashing is assumed to accept