Lines Matching +full:tx +full:- +full:queues +full:- +full:to +full:- +full:use
4 * Unified network-device I/O interface for Xen guest OSes.
6 * Permission is hereby granted, free of charge, to any person obtaining a copy
7 * of this software and associated documentation files (the "Software"), to
9 * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
10 * sell copies of the Software, and to permit persons to whom the Software is
11 * furnished to do so, subject to the following conditions:
17 * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
21 * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
24 * Copyright (c) 2003-2004, Keir Fraser
36 * ring slots a skb can use. Netfront / netback may not work as
39 * A better approach is to add mechanism for netfront / netback to
41 * frontends, so we need to define a value which states the minimum
45 * (18), which is proved to work with most frontends. Any new backend
46 * which doesn't negotiate with frontend should expect frontend to
47 * send a valid packet using slots up to this value.
55 * feature 'feature-rx-notify' via xenbus. Otherwise the backend will assume
56 * that it cannot safely queue packets (as it may not be kicked to send them).
60 * "feature-split-event-channels" is introduced to separate guest TX
64 * To make use of this feature, frontend should allocate two event
65 * channels for TX and RX, advertise them to backend as
66 * "event-channel-tx" and "event-channel-rx" respectively. If frontend
67 * doesn't want to use this feature, it just writes "event-channel"
72 * Multiple transmit and receive queues:
73 * If supported, the backend will write the key "multi-queue-max-queues" to
74 * the directory for that vif, and set its value to the maximum supported
75 * number of queues.
76 * Frontends that are aware of this feature and wish to use it can write the
77 * key "multi-queue-num-queues", set to the number they wish to use, which
79 * in "multi-queue-max-queues".
81 * Queues replicate the shared rings and event channels.
82 * "feature-split-event-channels" may optionally be used when using
83 * multiple queues, but is not mandatory.
86 * number of tx and rx rings.
88 * For frontends requesting just one queue, the usual event-channel and
89 * ring-ref keys are written as before, simplifying the backend processing
90 * to avoid distinguishing between a frontend that doesn't understand the
91 * multi-queue feature, and one that does, but requested only one queue.
93 * Frontends requesting two or more queues must not write the toplevel
94 * event-channel (or event-channel-{tx,rx}) and {tx,rx}-ring-ref keys,
95 * instead writing those keys under sub-keys having the name "queue-N" where
96 * N is the integer ID of the queue for which those keys belong. Queues
97 * are indexed from zero. For example, a frontend with two queues and split
98 * event channels must write the following set of queue-related keys:
100 * /local/domain/1/device/vif/0/multi-queue-num-queues = "2"
101 * /local/domain/1/device/vif/0/queue-0 = ""
102 * /local/domain/1/device/vif/0/queue-0/tx-ring-ref = "<ring-ref-tx0>"
103 * /local/domain/1/device/vif/0/queue-0/rx-ring-ref = "<ring-ref-rx0>"
104 * /local/domain/1/device/vif/0/queue-0/event-channel-tx = "<evtchn-tx0>"
105 * /local/domain/1/device/vif/0/queue-0/event-channel-rx = "<evtchn-rx0>"
106 * /local/domain/1/device/vif/0/queue-1 = ""
107 * /local/domain/1/device/vif/0/queue-1/tx-ring-ref = "<ring-ref-tx1>"
108 * /local/domain/1/device/vif/0/queue-1/rx-ring-ref = "<ring-ref-rx1"
109 * /local/domain/1/device/vif/0/queue-1/event-channel-tx = "<evtchn-tx1>"
110 * /local/domain/1/device/vif/0/queue-1/event-channel-rx = "<evtchn-rx1>"
113 * choose not to connect any queues, instead treating the request as an
114 * error. This includes scenarios where more (or fewer) queues were
117 * Mapping of packets to queues is considered to be a function of the
119 * between the two. Guests are free to transmit packets on any queue
121 * prepared to receive packets on any queue they have requested be set up.
125 * "feature-no-csum-offload" should be used to turn IPv4 TCP/UDP checksum
126 * offload off or on. If it is missing then the feature is assumed to be on.
127 * "feature-ipv6-csum-offload" should be used to turn IPv6 TCP/UDP checksum
128 * offload on or off. If it is missing then the feature is assumed to be off.
132 * "feature-gso-tcpv4" and "feature-gso-tcpv6" advertise the capability to
134 * frontends nor backends are assumed to be capable unless the flags are
139 * "feature-multicast-control" and "feature-dynamic-multicast-control"
140 * advertise the capability to filter ethernet multicast packets in the
141 * backend. If the frontend wishes to take advantage of this feature then
142 * it may set "request-multicast-control". If the backend only advertises
143 * "feature-multicast-control" then "request-multicast-control" must be set
147 * "feature-dynamic-multicast-control" then "request-multicast-control"
149 * watch the value and re-sample on watch events.
151 * If the sampled value of "request-multicast-control" is set then the
152 * backend transmit side should no longer flood multicast packets to the
156 * containing XEN_NETIF_EXTRA_TYPE_MCAST_{ADD,DEL} extra-info fragments as
159 * "request-multicast-control" is not set, however the filter should only
164 * "xdp-headroom" is used to request that extra space is added
166 * the frontend to be consistent between both ends.
168 * an RX response is going to be passed to an XDP program for processing.
171 * "feature-xdp-headroom" is set to "1" by the netback side like other features
181 * significant amount of out-of-band data to be passed from frontend to
182 * backend. Use of xenstore is not suitable for large quantities of data
184 * The ability of the backend to use a control ring is advertised by
187 * /local/domain/X/backend/<domid>/<vif>/feature-ctrl-ring = "1"
189 * The frontend provides a control ring to the backend by setting:
191 * /local/domain/<domid>/device/vif/<vif>/ctrl-ring-ref = <gref>
192 * /local/domain/<domid>/device/vif/<vif>/event-channel-ctrl = <port>
194 * where <gref> is the grant reference of the shared page used to
195 * implement the control ring and <port> is an event channel to be used
200 * balanced (i.e. one request to one response), so operationally it is much
212 * sub-array of 'Array' containing bytes X thru Y inclusive, and '+' is
213 * used to indicate concatenation of arrays.
285 * (Buffer[] and Key[] are treated as shift-registers where the MSB of
286 * Buffer/Key[0] is considered 'left-most' and the LSB of Buffer/Key[N-1]
287 * is the 'right-most').
291 * If (left-most bit of Buffer[] is 1)
292 * Value ^= left-most 32 bits of Key[]
308 /* Pre-load prefix with the first 8 bytes of the key */ in xen_netif_toeplitz_hash()
326 * 'prefix' has now been left-shifted by 8, so in xen_netif_toeplitz_hash()
345 * +-----+-----+-----+-----+-----+-----+-----+-----+
347 * +-----+-----+-----+-----+-----+-----+-----+-----+
349 * +-----+-----+-----+-----+-----------------------+
379 * +-----+-----+-----+-----+-----+-----+-----+-----+
381 * +-----+-----+-----+-----+-----+-----+-----+-----+
383 * +-----+-----+-----+-----+
410 * --------------------------------------
412 * This is sent by the frontend to set the desired hash algorithm.
423 * status = XEN_NETIF_CTRL_STATUS_NOT_SUPPORTED - Operation not
425 * XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER - The algorithm is not
427 * XEN_NETIF_CTRL_STATUS_SUCCESS - Operation successful
429 * NOTE: Setting data[0] to XEN_NETIF_CTRL_HASH_ALGORITHM_NONE disables
430 * hashing and the backend is free to choose how it steers packets
431 * to queues (which is the default behaviour).
434 * ----------------------------------
436 * This is sent by the frontend to query the types of hash supported by
448 * status = XEN_NETIF_CTRL_STATUS_NOT_SUPPORTED - Operation not supported
449 * XEN_NETIF_CTRL_STATUS_SUCCESS - Operation successful
456 * ----------------------------------
458 * This is sent by the frontend to set the types of hash that the backend
463 * former only calculated for non-TCP packets.
474 * status = XEN_NETIF_CTRL_STATUS_NOT_SUPPORTED - Operation not
476 * XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER - One or more flag
479 * XEN_NETIF_CTRL_STATUS_SUCCESS - Operation successful
484 * Also, setting data[0] to zero disables hashing and the backend
485 * is free to choose how it steers packets to queues.
488 * --------------------------------
490 * This is sent by the frontend to set the key of the hash if the algorithm
496 * data[0] = grant reference of page containing the key (assumed to
503 * status = XEN_NETIF_CTRL_STATUS_NOT_SUPPORTED - Operation not
505 * XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER - Key size is invalid
506 * XEN_NETIF_CTRL_STATUS_BUFFER_OVERFLOW - Key size is larger
509 * XEN_NETIF_CTRL_STATUS_SUCCESS - Operation successful
512 * NOTE: Any key octets not specified are assumed to be zero (the key
513 * is assumed to be empty by default) and specifying a new key
519 * The grant reference may be read-only and must remain valid until
523 * -----------------------------------------
525 * This is sent by the frontend to query the maximum size of mapping
538 * status = XEN_NETIF_CTRL_STATUS_NOT_SUPPORTED - Operation not supported
539 * XEN_NETIF_CTRL_STATUS_SUCCESS - Operation successful
546 * -------------------------------------
548 * This is sent by the frontend to set the actual size of the mapping
549 * table to be used by the backend. The size is specified in terms of
552 * is assumed to be zero filled.
563 * status = XEN_NETIF_CTRL_STATUS_NOT_SUPPORTED - Operation not
565 * XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER - Table size is invalid
566 * XEN_NETIF_CTRL_STATUS_SUCCESS - Operation successful
569 * NOTE: Setting data[0] to 0 means that hash mapping should be done
573 * ------------------------------------
575 * This is sent by the frontend to set the content of the table mapping
576 * hash value to queue number. The backend should calculate the hash from
577 * the packet header, use it as an index into the table (modulo the size
578 * of the table) and then steer the packet to the queue number found at
584 * data[0] = grant reference of page containing the mapping (sub-)table
585 * (assumed to start at beginning of grant)
586 * data[1] = size of (sub-)table in entries
587 * data[2] = offset, in entries, of sub-table within overall table
591 * status = XEN_NETIF_CTRL_STATUS_NOT_SUPPORTED - Operation not
593 * XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER - Table size or content
595 * XEN_NETIF_CTRL_STATUS_BUFFER_OVERFLOW - Table size is larger
598 * XEN_NETIF_CTRL_STATUS_SUCCESS - Operation successful
604 * +-----+-----+-----+-----+-----+-----+-----+-----+
606 * +-----+-----+-----+-----+-----+-----+-----+-----+
610 * +-----+-----+-----+-----+-----+-----+-----+-----+
611 * | mapping[N-2] | mapping[N-1] |
612 * +-----+-----+-----+-----+-----+-----+-----+-----+
616 * "multi-queue-num-queues" (see above).
618 * mapped by a single grant reference. Thus sub-tables within a
620 * with differing offset values. Specifying a new sub-table does not
622 * The grant reference may be read-only and must remain valid until
634 * This is the 'wire' format for transmit (frontend -> backend) packets:
636 * Fragment 1: xen_netif_tx_request_t - flags = XEN_NETTXF_*
638 * [Extra 1: xen_netif_extra_info_t] - (only if fragment 1 flags include
641 * [Extra N: xen_netif_extra_info_t] - (only if extra N-1 flags include
644 * Fragment N: xen_netif_tx_request_t - (only if fragment N-1 flags include
645 * XEN_NETTXF_more_data - flags on preceding
653 * (backend -> frontend) packets. Specifically, in a multi-fragment
658 * structs use the full size.
660 * tx request data (xen_netif_tx_request_t)
661 * ------------------------------------
664 * +-----+-----+-----+-----+-----+-----+-----+-----+
666 * +-----+-----+-----+-----+-----+-----+-----+-----+
668 * +-----+-----+-----+-----+
670 * grant ref: Reference to buffer page.
676 * tx response (xen_netif_tx_response_t)
677 * ---------------------------------
680 * +-----+-----+-----+-----+-----+-----+-----+-----+
682 * +-----+-----+-----+-----+-----+-----+-----+-----+
684 * +-----+-----+-----+-----+
692 * This is the 'wire' format for receive (backend -> frontend) packets:
694 * Fragment 1: xen_netif_rx_request_t - flags = XEN_NETRXF_*
696 * [Extra 1: xen_netif_extra_info_t] - (only if fragment 1 flags include
699 * [Extra N: xen_netif_extra_info_t] - (only if extra N-1 flags include
702 * Fragment N: xen_netif_rx_request_t - (only if fragment N-1 flags include
703 * XEN_NETRXF_more_data - flags on preceding
711 * (frontend -> backend) packets. Specifically, in a multi-fragment
718 * -------------------------------
721 * +-----+-----+-----+-----+-----+-----+-----+-----+
723 * +-----+-----+-----+-----+-----+-----+-----+-----+
726 * gref: reference to incoming granted frame.
729 * ---------------------------------
732 * +-----+-----+-----+-----+-----+-----+-----+-----+
734 * +-----+-----+-----+-----+-----+-----+-----+-----+
739 * status: -ve: XEN_NETIF_RSP_*; +ve: Rx'ed pkt size.
741 * NOTE: Historically, to support GSO on the frontend receive side, Linux
742 * netfront does not make use of the rx response id (because, as
745 * slot as their corresponding request. Thus, to maintain
754 * The struct therefore needs to fit into either a tx or rx slot and
755 * is therefore limited to 8 octets.
761 * consumed to make the slot available, and the backend must ensure
765 * -------------------------------
770 * +-----+-----+-----+-----+-----+-----+-----+-----+
772 * +-----+-----+-----+-----+-----+-----+-----+-----+
773 * | padding for tx |
774 * +-----+-----+-----+-----+
778 * padding for tx: present only in the tx case due to 8 octet limit
785 * +-----+-----+-----+-----+-----+-----+-----+-----+
787 * +-----+-----+-----+-----+-----+-----+-----+-----+
794 * the packet and any extra features required to segment the
797 * features required to process this packet, such as ECN
803 * +-----+-----+-----+-----+-----+-----+-----+-----+
805 * +-----+-----+-----+-----+-----+-----+-----+-----+
809 * addr: address to add/remove
813 * A backend that supports teoplitz hashing is assumed to accept
815 * A frontend that enables hashing is assumed to accept
819 * +-----+-----+-----+-----+-----+-----+-----+-----+
820 * |type |flags|htype| alg |LSB ---- value ---- MSB|
821 * +-----+-----+-----+-----+-----+-----+-----+-----+
825 * htype: Hash type (one of _XEN_NETIF_CTRL_HASH_TYPE_* - see above)
826 * alg: The algorithm used to calculate the hash (one of
827 * XEN_NETIF_CTRL_HASH_TYPE_ALGORITHM_* - see above)
843 /* Packet to be followed by extra descriptor(s). */
857 #define XEN_NETIF_EXTRA_TYPE_NONE (0) /* Never used - invalid */
875 * This structure needs to fit within both xen_netif_tx_request_t and
927 /* Packet to be followed by extra descriptor(s). */
951 #define XEN_NETIF_RSP_DROPPED -2
952 #define XEN_NETIF_RSP_ERROR -1