Lines Matching +full:charge +full:- +full:ctrl +full:- +full:value
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
24 * Copyright (c) 2003-2004, Keir Fraser
40 * negotiate this value. However we cannot fix all possible
41 * frontends, so we need to define a value which states the minimum
44 * The minimum value derives from older Linux kernel's MAX_SKB_FRAGS
47 * send a valid packet using slots up to this value.
55 * feature 'feature-rx-notify' via xenbus. Otherwise the backend will assume
60 * "feature-split-event-channels" is introduced to separate guest TX
66 * "event-channel-tx" and "event-channel-rx" respectively. If frontend
67 * doesn't want to use this feature, it just writes "event-channel"
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
77 * key "multi-queue-num-queues", set to the number they wish to use, which
78 * must be greater than zero, and no more than the value reported by the backend
79 * in "multi-queue-max-queues".
82 * "feature-split-event-channels" may optionally be used when using
88 * For frontends requesting just one queue, the usual event-channel and
89 * ring-ref keys are written as before, simplifying the backend processing
91 * multi-queue feature, and one that does, but requested only one queue.
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
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>"
125 * "feature-no-csum-offload" should be used to turn IPv4 TCP/UDP checksum
127 * "feature-ipv6-csum-offload" should be used to turn IPv6 TCP/UDP checksum
132 * "feature-gso-tcpv4" and "feature-gso-tcpv6" advertise the capability to
139 * "feature-multicast-control" and "feature-dynamic-multicast-control"
142 * it may set "request-multicast-control". If the backend only advertises
143 * "feature-multicast-control" then "request-multicast-control" must be set
145 * sample the value on this state transition and any subsequent change in
146 * value will have no effect. However, if the backend also advertises
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
156 * containing XEN_NETIF_EXTRA_TYPE_MCAST_{ADD,DEL} extra-info fragments as
158 * Note that the filter list may be amended even if the sampled value of
159 * "request-multicast-control" is not set, however the filter should only
164 * "xdp-headroom" is used to request that extra space is added
165 * for XDP processing. The value is measured in bytes and passed by
167 * If the value is greater than zero that means that
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
187 * /local/domain/X/backend/<domid>/<vif>/feature-ctrl-ring = "1"
191 * /local/domain/<domid>/device/vif/<vif>/ctrl-ring-ref = <gref>
192 * /local/domain/<domid>/device/vif/<vif>/event-channel-ctrl = <port>
212 * sub-array of 'Array' containing bytes X thru Y inclusive, and '+' is
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').
289 * Value = 0
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 * --------------------------------------
417 * data[0] = a XEN_NETIF_CTRL_HASH_ALGORITHM_* value
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
434 * ----------------------------------
448 * status = XEN_NETIF_CTRL_STATUS_NOT_SUPPORTED - Operation not supported
449 * XEN_NETIF_CTRL_STATUS_SUCCESS - Operation successful
456 * ----------------------------------
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
477 * value is invalid or
479 * XEN_NETIF_CTRL_STATUS_SUCCESS - Operation successful
488 * --------------------------------
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
519 * The grant reference may be read-only and must remain valid until
523 * -----------------------------------------
538 * status = XEN_NETIF_CTRL_STATUS_NOT_SUPPORTED - Operation not supported
539 * XEN_NETIF_CTRL_STATUS_SUCCESS - Operation successful
546 * -------------------------------------
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
573 * ------------------------------------
576 * hash value to queue number. The backend should calculate the hash from
584 * data[0] = grant reference of page containing the mapping (sub-)table
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
661 * ------------------------------------
664 * +-----+-----+-----+-----+-----+-----+-----+-----+
666 * +-----+-----+-----+-----+-----+-----+-----+-----+
668 * +-----+-----+-----+-----+
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 * +-----+-----+-----+-----+-----+-----+-----+-----+
729 * ---------------------------------
732 * +-----+-----+-----+-----+-----+-----+-----+-----+
734 * +-----+-----+-----+-----+-----+-----+-----+-----+
739 * status: -ve: XEN_NETIF_RSP_*; +ve: Rx'ed pkt size.
765 * -------------------------------
770 * +-----+-----+-----+-----+-----+-----+-----+-----+
772 * +-----+-----+-----+-----+-----+-----+-----+-----+
774 * +-----+-----+-----+-----+
785 * +-----+-----+-----+-----+-----+-----+-----+-----+
787 * +-----+-----+-----+-----+-----+-----+-----+-----+
803 * +-----+-----+-----+-----+-----+-----+-----+-----+
805 * +-----+-----+-----+-----+-----+-----+-----+-----+
819 * +-----+-----+-----+-----+-----+-----+-----+-----+
820 * |type |flags|htype| alg |LSB ---- value ---- MSB|
821 * +-----+-----+-----+-----+-----+-----+-----+-----+
825 * htype: Hash type (one of _XEN_NETIF_CTRL_HASH_TYPE_* - see above)
827 * XEN_NETIF_CTRL_HASH_TYPE_ALGORITHM_* - see above)
828 * value: Hash value
857 #define XEN_NETIF_EXTRA_TYPE_NONE (0) /* Never used - invalid */
894 uint8_t value[4]; member
951 #define XEN_NETIF_RSP_DROPPED -2
952 #define XEN_NETIF_RSP_ERROR -1