The Design and Implementation of the FreeBSD Operating System, Second Edition
Now available: The Design and Implementation of the FreeBSD Operating System (Second Edition)


[ source navigation ] [ diff markup ] [ identifier search ] [ freetext search ] [ file search ] [ list types ] [ track identifier ]

FreeBSD/Linux Kernel Cross Reference
sys/xen/interface/io/netif.h

Version: -  FREEBSD  -  FREEBSD-13-STABLE  -  FREEBSD-13-0  -  FREEBSD-12-STABLE  -  FREEBSD-12-0  -  FREEBSD-11-STABLE  -  FREEBSD-11-0  -  FREEBSD-10-STABLE  -  FREEBSD-10-0  -  FREEBSD-9-STABLE  -  FREEBSD-9-0  -  FREEBSD-8-STABLE  -  FREEBSD-8-0  -  FREEBSD-7-STABLE  -  FREEBSD-7-0  -  FREEBSD-6-STABLE  -  FREEBSD-6-0  -  FREEBSD-5-STABLE  -  FREEBSD-5-0  -  FREEBSD-4-STABLE  -  FREEBSD-3-STABLE  -  FREEBSD22  -  l41  -  OPENBSD  -  linux-2.6  -  MK84  -  PLAN9  -  xnu-8792 
SearchContext: -  none  -  3  -  10 

    1 /******************************************************************************
    2  * netif.h
    3  *
    4  * Unified network-device I/O interface for Xen guest OSes.
    5  *
    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
    8  * deal in the Software without restriction, including without limitation the
    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:
   12  *
   13  * The above copyright notice and this permission notice shall be included in
   14  * all copies or substantial portions of the Software.
   15  *
   16  * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
   17  * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
   18  * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
   19  * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
   20  * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
   21  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
   22  * DEALINGS IN THE SOFTWARE.
   23  *
   24  * Copyright (c) 2003-2004, Keir Fraser
   25  */
   26 
   27 #ifndef __XEN_PUBLIC_IO_NETIF_H__
   28 #define __XEN_PUBLIC_IO_NETIF_H__
   29 
   30 #include "ring.h"
   31 #include "../grant_table.h"
   32 
   33 /*
   34  * Older implementation of Xen network frontend / backend has an
   35  * implicit dependency on the MAX_SKB_FRAGS as the maximum number of
   36  * ring slots a skb can use. Netfront / netback may not work as
   37  * expected when frontend and backend have different MAX_SKB_FRAGS.
   38  *
   39  * A better approach is to add mechanism for netfront / netback to
   40  * negotiate this value. However we cannot fix all possible
   41  * frontends, so we need to define a value which states the minimum
   42  * slots backend must support.
   43  *
   44  * The minimum value derives from older Linux kernel's MAX_SKB_FRAGS
   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.
   48  */
   49 #define XEN_NETIF_NR_SLOTS_MIN 18
   50 
   51 /*
   52  * Notifications after enqueuing any type of message should be conditional on
   53  * the appropriate req_event or rsp_event field in the shared ring.
   54  * If the client sends notification for rx requests then it should specify
   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).
   57  */
   58 
   59 /*
   60  * "feature-split-event-channels" is introduced to separate guest TX
   61  * and RX notification. Backend either doesn't support this feature or
   62  * advertises it via xenstore as 0 (disabled) or 1 (enabled).
   63  *
   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"
   68  * node as before.
   69  */
   70 
   71 /*
   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
   78  * must be greater than zero, and no more than the value reported by the backend
   79  * in "multi-queue-max-queues".
   80  *
   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.
   84  *
   85  * Each queue consists of one shared ring pair, i.e. there must be the same
   86  * number of tx and rx rings.
   87  *
   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.
   92  *
   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:
   99  *
  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>"
  111  *
  112  * If there is any inconsistency in the XenStore data, the backend may
  113  * choose not to connect any queues, instead treating the request as an
  114  * error. This includes scenarios where more (or fewer) queues were
  115  * requested than the frontend provided details for.
  116  *
  117  * Mapping of packets to queues is considered to be a function of the
  118  * transmitting system (backend or frontend) and is not negotiated
  119  * between the two. Guests are free to transmit packets on any queue
  120  * they choose, provided it has been set up correctly. Guests must be
  121  * prepared to receive packets on any queue they have requested be set up.
  122  */
  123 
  124 /*
  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.
  129  */
  130 
  131 /*
  132  * "feature-gso-tcpv4" and "feature-gso-tcpv6" advertise the capability to
  133  * handle large TCP packets (in IPv4 or IPv6 form respectively). Neither
  134  * frontends nor backends are assumed to be capable unless the flags are
  135  * present.
  136  */
  137 
  138 /*
  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
  144  * before the frontend moves into the connected state. The backend will
  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"
  148  * may be set by the frontend at any time. In this case, the backend will
  149  * watch the value and re-sample on watch events.
  150  *
  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
  153  * frontend, it should instead drop any multicast packet that does not
  154  * match in a filter list.
  155  * The list is amended by the frontend by sending dummy transmit requests
  156  * containing XEN_NETIF_EXTRA_TYPE_MCAST_{ADD,DEL} extra-info fragments as
  157  * specified below.
  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
  160  * be applied if it is set.
  161  */
  162 
  163 /*
  164  * Control ring
  165  * ============
  166  *
  167  * Some features, such as hashing (detailed below), require a
  168  * significant amount of out-of-band data to be passed from frontend to
  169  * backend. Use of xenstore is not suitable for large quantities of data
  170  * because of quota limitations and so a dedicated 'control ring' is used.
  171  * The ability of the backend to use a control ring is advertised by
  172  * setting:
  173  *
  174  * /local/domain/X/backend/vif/<domid>/<vif>/feature-ctrl-ring = "1"
  175  *
  176  * The frontend provides a control ring to the backend by setting:
  177  *
  178  * /local/domain/<domid>/device/vif/<vif>/ctrl-ring-ref = <gref>
  179  * /local/domain/<domid>/device/vif/<vif>/event-channel-ctrl = <port>
  180  *
  181  * where <gref> is the grant reference of the shared page used to
  182  * implement the control ring and <port> is an event channel to be used
  183  * as a mailbox interrupt. These keys must be set before the frontend
  184  * moves into the connected state.
  185  *
  186  * The control ring uses a fixed request/response message size and is
  187  * balanced (i.e. one request to one response), so operationally it is much
  188  * the same as a transmit or receive ring.
  189  * Note that there is no requirement that responses are issued in the same
  190  * order as requests.
  191  */
  192 
  193 /*
  194  * Link state
  195  * ==========
  196  *
  197  * The backend can advertise its current link (carrier) state to the
  198  * frontend using the /local/domain/X/backend/vif/<domid>/<vif>/carrier
  199  * node. If this node is not present, then the frontend should assume that
  200  * the link is up (for compatibility with backends that do not implement
  201  * this feature). If this node is present, then a value of "" should be
  202  * interpreted by the frontend as the link being down (no carrier) and a
  203  * value of "1" should be interpreted as the link being up (carrier
  204  * present).
  205  */
  206 
  207 /*
  208  * Hash types
  209  * ==========
  210  *
  211  * For the purposes of the definitions below, 'Packet[]' is an array of
  212  * octets containing an IP packet without options, 'Array[X..Y]' means a
  213  * sub-array of 'Array' containing bytes X thru Y inclusive, and '+' is
  214  * used to indicate concatenation of arrays.
  215  */
  216 
  217 /*
  218  * A hash calculated over an IP version 4 header as follows:
  219  *
  220  * Buffer[0..8] = Packet[12..15] (source address) +
  221  *                Packet[16..19] (destination address)
  222  *
  223  * Result = Hash(Buffer, 8)
  224  */
  225 #define _XEN_NETIF_CTRL_HASH_TYPE_IPV4 0
  226 #define XEN_NETIF_CTRL_HASH_TYPE_IPV4 \
  227     (1 << _XEN_NETIF_CTRL_HASH_TYPE_IPV4)
  228 
  229 /*
  230  * A hash calculated over an IP version 4 header and TCP header as
  231  * follows:
  232  *
  233  * Buffer[0..12] = Packet[12..15] (source address) +
  234  *                 Packet[16..19] (destination address) +
  235  *                 Packet[20..21] (source port) +
  236  *                 Packet[22..23] (destination port)
  237  *
  238  * Result = Hash(Buffer, 12)
  239  */
  240 #define _XEN_NETIF_CTRL_HASH_TYPE_IPV4_TCP 1
  241 #define XEN_NETIF_CTRL_HASH_TYPE_IPV4_TCP \
  242     (1 << _XEN_NETIF_CTRL_HASH_TYPE_IPV4_TCP)
  243 
  244 /*
  245  * A hash calculated over an IP version 6 header as follows:
  246  *
  247  * Buffer[0..32] = Packet[8..23]  (source address ) +
  248  *                 Packet[24..39] (destination address)
  249  *
  250  * Result = Hash(Buffer, 32)
  251  */
  252 #define _XEN_NETIF_CTRL_HASH_TYPE_IPV6 2
  253 #define XEN_NETIF_CTRL_HASH_TYPE_IPV6 \
  254     (1 << _XEN_NETIF_CTRL_HASH_TYPE_IPV6)
  255 
  256 /*
  257  * A hash calculated over an IP version 6 header and TCP header as
  258  * follows:
  259  *
  260  * Buffer[0..36] = Packet[8..23]  (source address) +
  261  *                 Packet[24..39] (destination address) +
  262  *                 Packet[40..41] (source port) +
  263  *                 Packet[42..43] (destination port)
  264  *
  265  * Result = Hash(Buffer, 36)
  266  */
  267 #define _XEN_NETIF_CTRL_HASH_TYPE_IPV6_TCP 3
  268 #define XEN_NETIF_CTRL_HASH_TYPE_IPV6_TCP \
  269     (1 << _XEN_NETIF_CTRL_HASH_TYPE_IPV6_TCP)
  270 
  271 /*
  272  * Hash algorithms
  273  * ===============
  274  */
  275 
  276 #define XEN_NETIF_CTRL_HASH_ALGORITHM_NONE 0
  277 
  278 /*
  279  * Toeplitz hash:
  280  */
  281 
  282 #define XEN_NETIF_CTRL_HASH_ALGORITHM_TOEPLITZ 1
  283 
  284 /*
  285  * This algorithm uses a 'key' as well as the data buffer itself.
  286  * (Buffer[] and Key[] are treated as shift-registers where the MSB of
  287  * Buffer/Key[0] is considered 'left-most' and the LSB of Buffer/Key[N-1]
  288  * is the 'right-most').
  289  *
  290  * Value = 0
  291  * For number of bits in Buffer[]
  292  *    If (left-most bit of Buffer[] is 1)
  293  *        Value ^= left-most 32 bits of Key[]
  294  *    Key[] << 1
  295  *    Buffer[] << 1
  296  *
  297  * The code below is provided for convenience where an operating system
  298  * does not already provide an implementation.
  299  */
  300 #ifdef XEN_NETIF_DEFINE_TOEPLITZ
  301 static uint32_t xen_netif_toeplitz_hash(const uint8_t *key,
  302                                         unsigned int keylen,
  303                                         const uint8_t *buf,
  304                                         unsigned int buflen)
  305 {
  306     unsigned int keyi, bufi;
  307     uint64_t prefix = 0;
  308     uint64_t hash = 0;
  309 
  310     /* Pre-load prefix with the first 8 bytes of the key */
  311     for (keyi = 0; keyi < 8; keyi++) {
  312         prefix <<= 8;
  313         prefix |= (keyi < keylen) ? key[keyi] : 0;
  314     }
  315 
  316     for (bufi = 0; bufi < buflen; bufi++) {
  317         uint8_t byte = buf[bufi];
  318         unsigned int bit;
  319 
  320         for (bit = 0; bit < 8; bit++) {
  321             if (byte & 0x80)
  322                 hash ^= prefix;
  323             prefix <<= 1;
  324             byte <<=1;
  325         }
  326 
  327         /*
  328          * 'prefix' has now been left-shifted by 8, so
  329          * OR in the next byte.
  330          */
  331         prefix |= (keyi < keylen) ? key[keyi] : 0;
  332         keyi++;
  333     }
  334 
  335     /* The valid part of the hash is in the upper 32 bits. */
  336     return hash >> 32;
  337 }
  338 #endif /* XEN_NETIF_DEFINE_TOEPLITZ */
  339 
  340 /*
  341  * Control requests (struct xen_netif_ctrl_request)
  342  * ================================================
  343  *
  344  * All requests have the following format:
  345  *
  346  *    0     1     2     3     4     5     6     7  octet
  347  * +-----+-----+-----+-----+-----+-----+-----+-----+
  348  * |    id     |   type    |         data[0]       |
  349  * +-----+-----+-----+-----+-----+-----+-----+-----+
  350  * |         data[1]       |         data[2]       |
  351  * +-----+-----+-----+-----+-----------------------+
  352  *
  353  * id: the request identifier, echoed in response.
  354  * type: the type of request (see below)
  355  * data[]: any data associated with the request (determined by type)
  356  */
  357 
  358 struct xen_netif_ctrl_request {
  359     uint16_t id;
  360     uint16_t type;
  361 
  362 #define XEN_NETIF_CTRL_TYPE_INVALID               0
  363 #define XEN_NETIF_CTRL_TYPE_GET_HASH_FLAGS        1
  364 #define XEN_NETIF_CTRL_TYPE_SET_HASH_FLAGS        2
  365 #define XEN_NETIF_CTRL_TYPE_SET_HASH_KEY          3
  366 #define XEN_NETIF_CTRL_TYPE_GET_HASH_MAPPING_SIZE 4
  367 #define XEN_NETIF_CTRL_TYPE_SET_HASH_MAPPING_SIZE 5
  368 #define XEN_NETIF_CTRL_TYPE_SET_HASH_MAPPING      6
  369 #define XEN_NETIF_CTRL_TYPE_SET_HASH_ALGORITHM    7
  370 #define XEN_NETIF_CTRL_TYPE_GET_GREF_MAPPING_SIZE 8
  371 #define XEN_NETIF_CTRL_TYPE_ADD_GREF_MAPPING      9
  372 #define XEN_NETIF_CTRL_TYPE_DEL_GREF_MAPPING     10
  373 
  374     uint32_t data[3];
  375 };
  376 
  377 /*
  378  * Control responses (struct xen_netif_ctrl_response)
  379  * ==================================================
  380  *
  381  * All responses have the following format:
  382  *
  383  *    0     1     2     3     4     5     6     7  octet
  384  * +-----+-----+-----+-----+-----+-----+-----+-----+
  385  * |    id     |   type    |         status        |
  386  * +-----+-----+-----+-----+-----+-----+-----+-----+
  387  * |         data          |
  388  * +-----+-----+-----+-----+
  389  *
  390  * id: the corresponding request identifier
  391  * type: the type of the corresponding request
  392  * status: the status of request processing
  393  * data: any data associated with the response (determined by type and
  394  *       status)
  395  */
  396 
  397 struct xen_netif_ctrl_response {
  398     uint16_t id;
  399     uint16_t type;
  400     uint32_t status;
  401 
  402 #define XEN_NETIF_CTRL_STATUS_SUCCESS           0
  403 #define XEN_NETIF_CTRL_STATUS_NOT_SUPPORTED     1
  404 #define XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER 2
  405 #define XEN_NETIF_CTRL_STATUS_BUFFER_OVERFLOW   3
  406 
  407     uint32_t data;
  408 };
  409 
  410 /*
  411  * Static Grants (struct xen_netif_gref)
  412  * =====================================
  413  *
  414  * A frontend may provide a fixed set of grant references to be mapped on
  415  * the backend. The message of type XEN_NETIF_CTRL_TYPE_ADD_GREF_MAPPING
  416  * prior its usage in the command ring allows for creation of these mappings.
  417  * The backend will maintain a fixed amount of these mappings.
  418  *
  419  * XEN_NETIF_CTRL_TYPE_GET_GREF_MAPPING_SIZE lets a frontend query how many
  420  * of these mappings can be kept.
  421  *
  422  * Each entry in the XEN_NETIF_CTRL_TYPE_{ADD,DEL}_GREF_MAPPING input table has
  423  * the following format:
  424  *
  425  *    0     1     2     3     4     5     6     7  octet
  426  * +-----+-----+-----+-----+-----+-----+-----+-----+
  427  * | grant ref             |  flags    |  status   |
  428  * +-----+-----+-----+-----+-----+-----+-----+-----+
  429  *
  430  * grant ref: grant reference (IN)
  431  * flags: flags describing the control operation (IN)
  432  * status: XEN_NETIF_CTRL_STATUS_* (OUT)
  433  *
  434  * 'status' is an output parameter which does not require to be set to zero
  435  * prior to its usage in the corresponding control messages.
  436  */
  437 
  438 struct xen_netif_gref {
  439        grant_ref_t ref;
  440        uint16_t flags;
  441 
  442 #define _XEN_NETIF_CTRLF_GREF_readonly    0
  443 #define XEN_NETIF_CTRLF_GREF_readonly    (1U<<_XEN_NETIF_CTRLF_GREF_readonly)
  444 
  445        uint16_t status;
  446 };
  447 
  448 /*
  449  * Control messages
  450  * ================
  451  *
  452  * XEN_NETIF_CTRL_TYPE_SET_HASH_ALGORITHM
  453  * --------------------------------------
  454  *
  455  * This is sent by the frontend to set the desired hash algorithm.
  456  *
  457  * Request:
  458  *
  459  *  type    = XEN_NETIF_CTRL_TYPE_SET_HASH_ALGORITHM
  460  *  data[0] = a XEN_NETIF_CTRL_HASH_ALGORITHM_* value
  461  *  data[1] = 0
  462  *  data[2] = 0
  463  *
  464  * Response:
  465  *
  466  *  status = XEN_NETIF_CTRL_STATUS_NOT_SUPPORTED     - Operation not
  467  *                                                     supported
  468  *           XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER - The algorithm is not
  469  *                                                     supported
  470  *           XEN_NETIF_CTRL_STATUS_SUCCESS           - Operation successful
  471  *
  472  * NOTE: Setting data[0] to XEN_NETIF_CTRL_HASH_ALGORITHM_NONE disables
  473  *       hashing and the backend is free to choose how it steers packets
  474  *       to queues (which is the default behaviour).
  475  *
  476  * XEN_NETIF_CTRL_TYPE_GET_HASH_FLAGS
  477  * ----------------------------------
  478  *
  479  * This is sent by the frontend to query the types of hash supported by
  480  * the backend.
  481  *
  482  * Request:
  483  *
  484  *  type    = XEN_NETIF_CTRL_TYPE_GET_HASH_FLAGS
  485  *  data[0] = 0
  486  *  data[1] = 0
  487  *  data[2] = 0
  488  *
  489  * Response:
  490  *
  491  *  status = XEN_NETIF_CTRL_STATUS_NOT_SUPPORTED - Operation not supported
  492  *           XEN_NETIF_CTRL_STATUS_SUCCESS       - Operation successful
  493  *  data   = supported hash types (if operation was successful)
  494  *
  495  * NOTE: A valid hash algorithm must be selected before this operation can
  496  *       succeed.
  497  *
  498  * XEN_NETIF_CTRL_TYPE_SET_HASH_FLAGS
  499  * ----------------------------------
  500  *
  501  * This is sent by the frontend to set the types of hash that the backend
  502  * should calculate. (See above for hash type definitions).
  503  * Note that the 'maximal' type of hash should always be chosen. For
  504  * example, if the frontend sets both IPV4 and IPV4_TCP hash types then
  505  * the latter hash type should be calculated for any TCP packet and the
  506  * former only calculated for non-TCP packets.
  507  *
  508  * Request:
  509  *
  510  *  type    = XEN_NETIF_CTRL_TYPE_SET_HASH_FLAGS
  511  *  data[0] = bitwise OR of XEN_NETIF_CTRL_HASH_TYPE_* values
  512  *  data[1] = 0
  513  *  data[2] = 0
  514  *
  515  * Response:
  516  *
  517  *  status = XEN_NETIF_CTRL_STATUS_NOT_SUPPORTED     - Operation not
  518  *                                                     supported
  519  *           XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER - One or more flag
  520  *                                                     value is invalid or
  521  *                                                     unsupported
  522  *           XEN_NETIF_CTRL_STATUS_SUCCESS           - Operation successful
  523  *  data   = 0
  524  *
  525  * NOTE: A valid hash algorithm must be selected before this operation can
  526  *       succeed.
  527  *       Also, setting data[0] to zero disables hashing and the backend
  528  *       is free to choose how it steers packets to queues.
  529  *
  530  * XEN_NETIF_CTRL_TYPE_SET_HASH_KEY
  531  * --------------------------------
  532  *
  533  * This is sent by the frontend to set the key of the hash if the algorithm
  534  * requires it. (See hash algorithms above).
  535  *
  536  * Request:
  537  *
  538  *  type    = XEN_NETIF_CTRL_TYPE_SET_HASH_KEY
  539  *  data[0] = grant reference of page containing the key (assumed to
  540  *            start at beginning of grant)
  541  *  data[1] = size of key in octets
  542  *  data[2] = 0
  543  *
  544  * Response:
  545  *
  546  *  status = XEN_NETIF_CTRL_STATUS_NOT_SUPPORTED     - Operation not
  547  *                                                     supported
  548  *           XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER - Key size is invalid
  549  *           XEN_NETIF_CTRL_STATUS_BUFFER_OVERFLOW   - Key size is larger
  550  *                                                     than the backend
  551  *                                                     supports
  552  *           XEN_NETIF_CTRL_STATUS_SUCCESS           - Operation successful
  553  *  data   = 0
  554  *
  555  * NOTE: Any key octets not specified are assumed to be zero (the key
  556  *       is assumed to be empty by default) and specifying a new key
  557  *       invalidates any previous key, hence specifying a key size of
  558  *       zero will clear the key (which ensures that the calculated hash
  559  *       will always be zero).
  560  *       The maximum size of key is algorithm and backend specific, but
  561  *       is also limited by the single grant reference.
  562  *       The grant reference may be read-only and must remain valid until
  563  *       the response has been processed.
  564  *
  565  * XEN_NETIF_CTRL_TYPE_GET_HASH_MAPPING_SIZE
  566  * -----------------------------------------
  567  *
  568  * This is sent by the frontend to query the maximum size of mapping
  569  * table supported by the backend. The size is specified in terms of
  570  * table entries.
  571  *
  572  * Request:
  573  *
  574  *  type    = XEN_NETIF_CTRL_TYPE_GET_HASH_MAPPING_SIZE
  575  *  data[0] = 0
  576  *  data[1] = 0
  577  *  data[2] = 0
  578  *
  579  * Response:
  580  *
  581  *  status = XEN_NETIF_CTRL_STATUS_NOT_SUPPORTED - Operation not supported
  582  *           XEN_NETIF_CTRL_STATUS_SUCCESS       - Operation successful
  583  *  data   = maximum number of entries allowed in the mapping table
  584  *           (if operation was successful) or zero if a mapping table is
  585  *           not supported (i.e. hash mapping is done only by modular
  586  *           arithmetic).
  587  *
  588  * XEN_NETIF_CTRL_TYPE_SET_HASH_MAPPING_SIZE
  589  * -------------------------------------
  590  *
  591  * This is sent by the frontend to set the actual size of the mapping
  592  * table to be used by the backend. The size is specified in terms of
  593  * table entries.
  594  * Any previous table is invalidated by this message and any new table
  595  * is assumed to be zero filled.
  596  *
  597  * Request:
  598  *
  599  *  type    = XEN_NETIF_CTRL_TYPE_SET_HASH_MAPPING_SIZE
  600  *  data[0] = number of entries in mapping table
  601  *  data[1] = 0
  602  *  data[2] = 0
  603  *
  604  * Response:
  605  *
  606  *  status = XEN_NETIF_CTRL_STATUS_NOT_SUPPORTED     - Operation not
  607  *                                                     supported
  608  *           XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER - Table size is invalid
  609  *           XEN_NETIF_CTRL_STATUS_SUCCESS           - Operation successful
  610  *  data   = 0
  611  *
  612  * NOTE: Setting data[0] to 0 means that hash mapping should be done
  613  *       using modular arithmetic.
  614  *
  615  * XEN_NETIF_CTRL_TYPE_SET_HASH_MAPPING
  616  * ------------------------------------
  617  *
  618  * This is sent by the frontend to set the content of the table mapping
  619  * hash value to queue number. The backend should calculate the hash from
  620  * the packet header, use it as an index into the table (modulo the size
  621  * of the table) and then steer the packet to the queue number found at
  622  * that index.
  623  *
  624  * Request:
  625  *
  626  *  type    = XEN_NETIF_CTRL_TYPE_SET_HASH_MAPPING
  627  *  data[0] = grant reference of page containing the mapping (sub-)table
  628  *            (assumed to start at beginning of grant)
  629  *  data[1] = size of (sub-)table in entries
  630  *  data[2] = offset, in entries, of sub-table within overall table
  631  *
  632  * Response:
  633  *
  634  *  status = XEN_NETIF_CTRL_STATUS_NOT_SUPPORTED     - Operation not
  635  *                                                     supported
  636  *           XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER - Table size or content
  637  *                                                     is invalid
  638  *           XEN_NETIF_CTRL_STATUS_BUFFER_OVERFLOW   - Table size is larger
  639  *                                                     than the backend
  640  *                                                     supports
  641  *           XEN_NETIF_CTRL_STATUS_SUCCESS           - Operation successful
  642  *  data   = 0
  643  *
  644  * NOTE: The overall table has the following format:
  645  *
  646  *          0     1     2     3     4     5     6     7  octet
  647  *       +-----+-----+-----+-----+-----+-----+-----+-----+
  648  *       |       mapping[0]      |       mapping[1]      |
  649  *       +-----+-----+-----+-----+-----+-----+-----+-----+
  650  *       |                       .                       |
  651  *       |                       .                       |
  652  *       |                       .                       |
  653  *       +-----+-----+-----+-----+-----+-----+-----+-----+
  654  *       |      mapping[N-2]     |      mapping[N-1]     |
  655  *       +-----+-----+-----+-----+-----+-----+-----+-----+
  656  *
  657  *       where N is specified by a XEN_NETIF_CTRL_TYPE_SET_HASH_MAPPING_SIZE
  658  *       message and each  mapping must specifies a queue between 0 and
  659  *       "multi-queue-num-queues" (see above).
  660  *       The backend may support a mapping table larger than can be
  661  *       mapped by a single grant reference. Thus sub-tables within a
  662  *       larger table can be individually set by sending multiple messages
  663  *       with differing offset values. Specifying a new sub-table does not
  664  *       invalidate any table data outside that range.
  665  *       The grant reference may be read-only and must remain valid until
  666  *       the response has been processed.
  667  *
  668  * XEN_NETIF_CTRL_TYPE_GET_GREF_MAPPING_SIZE
  669  * -----------------------------------------
  670  *
  671  * This is sent by the frontend to fetch the number of grefs that can be kept
  672  * mapped in the backend.
  673  *
  674  * Request:
  675  *
  676  *  type    = XEN_NETIF_CTRL_TYPE_GET_GREF_MAPPING_SIZE
  677  *  data[0] = queue index (assumed 0 for single queue)
  678  *  data[1] = 0
  679  *  data[2] = 0
  680  *
  681  * Response:
  682  *
  683  *  status = XEN_NETIF_CTRL_STATUS_NOT_SUPPORTED     - Operation not
  684  *                                                     supported
  685  *           XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER - The queue index is
  686  *                                                     out of range
  687  *           XEN_NETIF_CTRL_STATUS_SUCCESS           - Operation successful
  688  *  data   = maximum number of entries allowed in the gref mapping table
  689  *           (if operation was successful) or zero if it is not supported.
  690  *
  691  * XEN_NETIF_CTRL_TYPE_ADD_GREF_MAPPING
  692  * ------------------------------------
  693  *
  694  * This is sent by the frontend for backend to map a list of grant
  695  * references.
  696  *
  697  * Request:
  698  *
  699  *  type    = XEN_NETIF_CTRL_TYPE_ADD_GREF_MAPPING
  700  *  data[0] = queue index
  701  *  data[1] = grant reference of page containing the mapping list
  702  *            (r/w and assumed to start at beginning of page)
  703  *  data[2] = size of list in entries
  704  *
  705  * Response:
  706  *
  707  *  status = XEN_NETIF_CTRL_STATUS_NOT_SUPPORTED     - Operation not
  708  *                                                     supported
  709  *           XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER - Operation failed
  710  *           XEN_NETIF_CTRL_STATUS_SUCCESS           - Operation successful
  711  *
  712  * NOTE: Each entry in the input table has the format outlined
  713  *       in struct xen_netif_gref.
  714  *       Contrary to XEN_NETIF_CTRL_TYPE_DEL_GREF_MAPPING, the struct
  715  *       xen_netif_gref 'status' field is not used and therefore the response
  716  *       'status' determines the success of this operation. In case of
  717  *       failure none of grants mappings get added in the backend.
  718  *
  719  * XEN_NETIF_CTRL_TYPE_DEL_GREF_MAPPING
  720  * ------------------------------------
  721  *
  722  * This is sent by the frontend for backend to unmap a list of grant
  723  * references.
  724  *
  725  * Request:
  726  *
  727  *  type    = XEN_NETIF_CTRL_TYPE_DEL_GREF_MAPPING
  728  *  data[0] = queue index
  729  *  data[1] = grant reference of page containing the mapping list
  730  *            (r/w and assumed to start at beginning of page)
  731  *  data[2] = size of list in entries
  732  *
  733  * Response:
  734  *
  735  *  status = XEN_NETIF_CTRL_STATUS_NOT_SUPPORTED     - Operation not
  736  *                                                     supported
  737  *           XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER - Operation failed
  738  *           XEN_NETIF_CTRL_STATUS_SUCCESS           - Operation successful
  739  *  data   = number of entries that were unmapped
  740  *
  741  * NOTE: Each entry in the input table has the format outlined in struct
  742  *       xen_netif_gref.
  743  *       The struct xen_netif_gref 'status' field determines if the entry
  744  *       was successfully removed.
  745  *       The entries used are only the ones representing grant references that
  746  *       were previously the subject of a XEN_NETIF_CTRL_TYPE_ADD_GREF_MAPPING
  747  *       operation. Any other entries will have their status set to
  748  *       XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER upon completion.
  749  */
  750 
  751 DEFINE_RING_TYPES(xen_netif_ctrl,
  752                   struct xen_netif_ctrl_request,
  753                   struct xen_netif_ctrl_response);
  754 
  755 /*
  756  * Guest transmit
  757  * ==============
  758  *
  759  * This is the 'wire' format for transmit (frontend -> backend) packets:
  760  *
  761  *  Fragment 1: netif_tx_request_t  - flags = NETTXF_*
  762  *                                    size = total packet size
  763  * [Extra 1: netif_extra_info_t]    - (only if fragment 1 flags include
  764  *                                     NETTXF_extra_info)
  765  *  ...
  766  * [Extra N: netif_extra_info_t]    - (only if extra N-1 flags include
  767  *                                     XEN_NETIF_EXTRA_MORE)
  768  *  ...
  769  *  Fragment N: netif_tx_request_t  - (only if fragment N-1 flags include
  770  *                                     NETTXF_more_data - flags on preceding
  771  *                                     extras are not relevant here)
  772  *                                    flags = 0
  773  *                                    size = fragment size
  774  *
  775  * NOTE:
  776  *
  777  * This format slightly is different from that used for receive
  778  * (backend -> frontend) packets. Specifically, in a multi-fragment
  779  * packet the actual size of fragment 1 can only be determined by
  780  * subtracting the sizes of fragments 2..N from the total packet size.
  781  *
  782  * Ring slot size is 12 octets, however not all request/response
  783  * structs use the full size.
  784  *
  785  * tx request data (netif_tx_request_t)
  786  * ------------------------------------
  787  *
  788  *    0     1     2     3     4     5     6     7  octet
  789  * +-----+-----+-----+-----+-----+-----+-----+-----+
  790  * | grant ref             | offset    | flags     |
  791  * +-----+-----+-----+-----+-----+-----+-----+-----+
  792  * | id        | size      |
  793  * +-----+-----+-----+-----+
  794  *
  795  * grant ref: Reference to buffer page.
  796  * offset: Offset within buffer page.
  797  * flags: NETTXF_*.
  798  * id: request identifier, echoed in response.
  799  * size: packet size in bytes.
  800  *
  801  * tx response (netif_tx_response_t)
  802  * ---------------------------------
  803  *
  804  *    0     1     2     3     4     5     6     7  octet
  805  * +-----+-----+-----+-----+-----+-----+-----+-----+
  806  * | id        | status    | unused                |
  807  * +-----+-----+-----+-----+-----+-----+-----+-----+
  808  * | unused                |
  809  * +-----+-----+-----+-----+
  810  *
  811  * id: reflects id in transmit request
  812  * status: NETIF_RSP_*
  813  *
  814  * Guest receive
  815  * =============
  816  *
  817  * This is the 'wire' format for receive (backend -> frontend) packets:
  818  *
  819  *  Fragment 1: netif_rx_request_t  - flags = NETRXF_*
  820  *                                    size = fragment size
  821  * [Extra 1: netif_extra_info_t]    - (only if fragment 1 flags include
  822  *                                     NETRXF_extra_info)
  823  *  ...
  824  * [Extra N: netif_extra_info_t]    - (only if extra N-1 flags include
  825  *                                     XEN_NETIF_EXTRA_MORE)
  826  *  ...
  827  *  Fragment N: netif_rx_request_t  - (only if fragment N-1 flags include
  828  *                                     NETRXF_more_data - flags on preceding
  829  *                                     extras are not relevant here)
  830  *                                    flags = 0
  831  *                                    size = fragment size
  832  *
  833  * NOTE:
  834  *
  835  * This format slightly is different from that used for transmit
  836  * (frontend -> backend) packets. Specifically, in a multi-fragment
  837  * packet the size of the packet can only be determined by summing the
  838  * sizes of fragments 1..N.
  839  *
  840  * Ring slot size is 8 octets.
  841  *
  842  * rx request (netif_rx_request_t)
  843  * -------------------------------
  844  *
  845  *    0     1     2     3     4     5     6     7  octet
  846  * +-----+-----+-----+-----+-----+-----+-----+-----+
  847  * | id        | pad       | gref                  |
  848  * +-----+-----+-----+-----+-----+-----+-----+-----+
  849  *
  850  * id: request identifier, echoed in response.
  851  * gref: reference to incoming granted frame.
  852  *
  853  * rx response (netif_rx_response_t)
  854  * ---------------------------------
  855  *
  856  *    0     1     2     3     4     5     6     7  octet
  857  * +-----+-----+-----+-----+-----+-----+-----+-----+
  858  * | id        | offset    | flags     | status    |
  859  * +-----+-----+-----+-----+-----+-----+-----+-----+
  860  *
  861  * id: reflects id in receive request
  862  * offset: offset in page of start of received packet
  863  * flags: NETRXF_*
  864  * status: -ve: NETIF_RSP_*; +ve: Rx'ed pkt size.
  865  *
  866  * NOTE: Historically, to support GSO on the frontend receive side, Linux
  867  *       netfront does not make use of the rx response id (because, as
  868  *       described below, extra info structures overlay the id field).
  869  *       Instead it assumes that responses always appear in the same ring
  870  *       slot as their corresponding request. Thus, to maintain
  871  *       compatibility, backends must make sure this is the case.
  872  *
  873  * Extra Info
  874  * ==========
  875  *
  876  * Can be present if initial request or response has NET{T,R}XF_extra_info,
  877  * or previous extra request has XEN_NETIF_EXTRA_MORE.
  878  *
  879  * The struct therefore needs to fit into either a tx or rx slot and
  880  * is therefore limited to 8 octets.
  881  *
  882  * NOTE: Because extra info data overlays the usual request/response
  883  *       structures, there is no id information in the opposite direction.
  884  *       So, if an extra info overlays an rx response the frontend can
  885  *       assume that it is in the same ring slot as the request that was
  886  *       consumed to make the slot available, and the backend must ensure
  887  *       this assumption is true.
  888  *
  889  * extra info (netif_extra_info_t)
  890  * -------------------------------
  891  *
  892  * General format:
  893  *
  894  *    0     1     2     3     4     5     6     7  octet
  895  * +-----+-----+-----+-----+-----+-----+-----+-----+
  896  * |type |flags| type specific data                |
  897  * +-----+-----+-----+-----+-----+-----+-----+-----+
  898  * | padding for tx        |
  899  * +-----+-----+-----+-----+
  900  *
  901  * type: XEN_NETIF_EXTRA_TYPE_*
  902  * flags: XEN_NETIF_EXTRA_FLAG_*
  903  * padding for tx: present only in the tx case due to 8 octet limit
  904  *                 from rx case. Not shown in type specific entries
  905  *                 below.
  906  *
  907  * XEN_NETIF_EXTRA_TYPE_GSO:
  908  *
  909  *    0     1     2     3     4     5     6     7  octet
  910  * +-----+-----+-----+-----+-----+-----+-----+-----+
  911  * |type |flags| size      |type | pad | features  |
  912  * +-----+-----+-----+-----+-----+-----+-----+-----+
  913  *
  914  * type: Must be XEN_NETIF_EXTRA_TYPE_GSO
  915  * flags: XEN_NETIF_EXTRA_FLAG_*
  916  * size: Maximum payload size of each segment. For example,
  917  *       for TCP this is just the path MSS.
  918  * type: XEN_NETIF_GSO_TYPE_*: This determines the protocol of
  919  *       the packet and any extra features required to segment the
  920  *       packet properly.
  921  * features: EN_NETIF_GSO_FEAT_*: This specifies any extra GSO
  922  *           features required to process this packet, such as ECN
  923  *           support for TCPv4.
  924  *
  925  * XEN_NETIF_EXTRA_TYPE_MCAST_{ADD,DEL}:
  926  *
  927  *    0     1     2     3     4     5     6     7  octet
  928  * +-----+-----+-----+-----+-----+-----+-----+-----+
  929  * |type |flags| addr                              |
  930  * +-----+-----+-----+-----+-----+-----+-----+-----+
  931  *
  932  * type: Must be XEN_NETIF_EXTRA_TYPE_MCAST_{ADD,DEL}
  933  * flags: XEN_NETIF_EXTRA_FLAG_*
  934  * addr: address to add/remove
  935  *
  936  * XEN_NETIF_EXTRA_TYPE_HASH:
  937  *
  938  * A backend that supports teoplitz hashing is assumed to accept
  939  * this type of extra info in transmit packets.
  940  * A frontend that enables hashing is assumed to accept
  941  * this type of extra info in receive packets.
  942  *
  943  *    0     1     2     3     4     5     6     7  octet
  944  * +-----+-----+-----+-----+-----+-----+-----+-----+
  945  * |type |flags|htype| alg |LSB ---- value ---- MSB|
  946  * +-----+-----+-----+-----+-----+-----+-----+-----+
  947  *
  948  * type: Must be XEN_NETIF_EXTRA_TYPE_HASH
  949  * flags: XEN_NETIF_EXTRA_FLAG_*
  950  * htype: Hash type (one of _XEN_NETIF_CTRL_HASH_TYPE_* - see above)
  951  * alg: The algorithm used to calculate the hash (one of
  952  *      XEN_NETIF_CTRL_HASH_TYPE_ALGORITHM_* - see above)
  953  * value: Hash value
  954  */
  955 
  956 /* Protocol checksum field is blank in the packet (hardware offload)? */
  957 #define _NETTXF_csum_blank     (0)
  958 #define  NETTXF_csum_blank     (1U<<_NETTXF_csum_blank)
  959 
  960 /* Packet data has been validated against protocol checksum. */
  961 #define _NETTXF_data_validated (1)
  962 #define  NETTXF_data_validated (1U<<_NETTXF_data_validated)
  963 
  964 /* Packet continues in the next request descriptor. */
  965 #define _NETTXF_more_data      (2)
  966 #define  NETTXF_more_data      (1U<<_NETTXF_more_data)
  967 
  968 /* Packet to be followed by extra descriptor(s). */
  969 #define _NETTXF_extra_info     (3)
  970 #define  NETTXF_extra_info     (1U<<_NETTXF_extra_info)
  971 
  972 #define XEN_NETIF_MAX_TX_SIZE 0xFFFF
  973 struct netif_tx_request {
  974     grant_ref_t gref;
  975     uint16_t offset;
  976     uint16_t flags;
  977     uint16_t id;
  978     uint16_t size;
  979 };
  980 typedef struct netif_tx_request netif_tx_request_t;
  981 
  982 /* Types of netif_extra_info descriptors. */
  983 #define XEN_NETIF_EXTRA_TYPE_NONE      (0)  /* Never used - invalid */
  984 #define XEN_NETIF_EXTRA_TYPE_GSO       (1)  /* u.gso */
  985 #define XEN_NETIF_EXTRA_TYPE_MCAST_ADD (2)  /* u.mcast */
  986 #define XEN_NETIF_EXTRA_TYPE_MCAST_DEL (3)  /* u.mcast */
  987 #define XEN_NETIF_EXTRA_TYPE_HASH      (4)  /* u.hash */
  988 #define XEN_NETIF_EXTRA_TYPE_MAX       (5)
  989 
  990 /* netif_extra_info_t flags. */
  991 #define _XEN_NETIF_EXTRA_FLAG_MORE (0)
  992 #define XEN_NETIF_EXTRA_FLAG_MORE  (1U<<_XEN_NETIF_EXTRA_FLAG_MORE)
  993 
  994 /* GSO types */
  995 #define XEN_NETIF_GSO_TYPE_NONE         (0)
  996 #define XEN_NETIF_GSO_TYPE_TCPV4        (1)
  997 #define XEN_NETIF_GSO_TYPE_TCPV6        (2)
  998 
  999 /*
 1000  * This structure needs to fit within both netif_tx_request_t and
 1001  * netif_rx_response_t for compatibility.
 1002  */
 1003 struct netif_extra_info {
 1004     uint8_t type;
 1005     uint8_t flags;
 1006     union {
 1007         struct {
 1008             uint16_t size;
 1009             uint8_t type;
 1010             uint8_t pad;
 1011             uint16_t features;
 1012         } gso;
 1013         struct {
 1014             uint8_t addr[6];
 1015         } mcast;
 1016         struct {
 1017             uint8_t type;
 1018             uint8_t algorithm;
 1019             uint8_t value[4];
 1020         } hash;
 1021         uint16_t pad[3];
 1022     } u;
 1023 };
 1024 typedef struct netif_extra_info netif_extra_info_t;
 1025 
 1026 struct netif_tx_response {
 1027     uint16_t id;
 1028     int16_t  status;
 1029 };
 1030 typedef struct netif_tx_response netif_tx_response_t;
 1031 
 1032 struct netif_rx_request {
 1033     uint16_t    id;        /* Echoed in response message.        */
 1034     uint16_t    pad;
 1035     grant_ref_t gref;
 1036 };
 1037 typedef struct netif_rx_request netif_rx_request_t;
 1038 
 1039 /* Packet data has been validated against protocol checksum. */
 1040 #define _NETRXF_data_validated (0)
 1041 #define  NETRXF_data_validated (1U<<_NETRXF_data_validated)
 1042 
 1043 /* Protocol checksum field is blank in the packet (hardware offload)? */
 1044 #define _NETRXF_csum_blank     (1)
 1045 #define  NETRXF_csum_blank     (1U<<_NETRXF_csum_blank)
 1046 
 1047 /* Packet continues in the next request descriptor. */
 1048 #define _NETRXF_more_data      (2)
 1049 #define  NETRXF_more_data      (1U<<_NETRXF_more_data)
 1050 
 1051 /* Packet to be followed by extra descriptor(s). */
 1052 #define _NETRXF_extra_info     (3)
 1053 #define  NETRXF_extra_info     (1U<<_NETRXF_extra_info)
 1054 
 1055 /* Packet has GSO prefix. Deprecated but included for compatibility */
 1056 #define _NETRXF_gso_prefix     (4)
 1057 #define  NETRXF_gso_prefix     (1U<<_NETRXF_gso_prefix)
 1058 
 1059 struct netif_rx_response {
 1060     uint16_t id;
 1061     uint16_t offset;
 1062     uint16_t flags;
 1063     int16_t  status;
 1064 };
 1065 typedef struct netif_rx_response netif_rx_response_t;
 1066 
 1067 /*
 1068  * Generate netif ring structures and types.
 1069  */
 1070 
 1071 DEFINE_RING_TYPES(netif_tx, struct netif_tx_request, struct netif_tx_response);
 1072 DEFINE_RING_TYPES(netif_rx, struct netif_rx_request, struct netif_rx_response);
 1073 
 1074 #define NETIF_RSP_DROPPED         -2
 1075 #define NETIF_RSP_ERROR           -1
 1076 #define NETIF_RSP_OKAY             0
 1077 /* No response: used for auxiliary requests (e.g., netif_extra_info_t). */
 1078 #define NETIF_RSP_NULL             1
 1079 
 1080 #endif
 1081 
 1082 /*
 1083  * Local variables:
 1084  * mode: C
 1085  * c-file-style: "BSD"
 1086  * c-basic-offset: 4
 1087  * tab-width: 4
 1088  * indent-tabs-mode: nil
 1089  * End:
 1090  */

Cache object: ddbe5b0f77d08c56b5514f2c5cd65bbf


[ source navigation ] [ diff markup ] [ identifier search ] [ freetext search ] [ file search ] [ list types ] [ track identifier ]


This page is part of the FreeBSD/Linux Linux Kernel Cross-Reference, and was automatically generated using a modified version of the LXR engine.