Type Alias gnrc_pktsnip_t

pub type gnrc_pktsnip_t = gnrc_pktsnip;

@brief Type to represent parts (either headers or payload) of a packet, called snips. @details The idea behind the packet snips is that they either can represent protocol-specific headers or payload. A packet can be comprised of multiple pktsnip_t elements.

     Example:

                                                             buffer
         +---------------------------+                      +------+
         | size = 14                 | data +-------------->|      |
         | type = NETTYPE_ETHERNET   |------+               +------+
         +---------------------------+                      .      .
               | next                                       .      .
               v                                            +------+
         +---------------------------+         +----------->|      |
         | size = 40                 | data    |            |      |
         | type = NETTYPE_IPV6       |---------+            +------+
         +---------------------------+                      .      .
               | next                                       .      .
               v                                            +------+
         +---------------------------+            +-------->|      |
         | size = 8                  | data       |         +------+
         | type = NETTYPE_UDP        |------------+         .      .
         +---------------------------+                      .      .
               | next                                       +------+
               v                                     +----->|      |
         +---------------------------+               |      |      |
         | size = 59                 | data          |      .      .
         | type = NETTYPE_UNDEF      |---------------+      .      .
         +---------------------------+                      .      .

To keep data duplication as low as possible the order of the snips in a packet will be reversed depending on if you send the packet or if you received it. For sending the order is from (in the network stack) lowest protocol snip to the highest, for receiving the order is from highest snip to the lowest. This way, if a layer needs to duplicate the packet a tree is created rather than a duplication of the whole package.

A very extreme example for this (we only expect one or two duplications at maximum per package) can be seen here:

 Sending                          Receiving
 =======                          =========

 * Payload                        * L2 header
 ^                                ^
 |                                |
 |\                               |\
 | * L4 header 1                  | * L2.5 header 1
 | * L3 header 1                  | * L3 header 1
 | * netif header 1               | * L4 header 1
 * L4 header 2                    | * Payload 1
 ^                                * L3 header 2
 |                                ^
 |\                               |
 | * L3 header 2                  |\
 | * L2 header 2                  | * L4 header 2
 * L2 header 3                    | * Payload 2
 |\                               * Payload 3
 | * L2 header 3
 * L2 header 4

The first three fields (next, data, size) match iolist_t (named iol_next, iol_base and iol_len there). That means that any pktsnip can be casted to iolist_t for direct passing to e.g., netdev send() functions.

@note This type has no initializer on purpose. Please use @ref net_gnrc_pktbuf as factory.

Aliased Type

struct gnrc_pktsnip_t {
    pub next: *mut gnrc_pktsnip,
    pub data: *mut c_void,
    pub size: u32,
    pub users: u32,
    pub type_: i8,
}

Fields

next: *mut gnrc_pktsnip

< next snip in the packet

data: *mut c_void

< pointer to the data of the snip

size: u32

< the length of the snip in byte

users: u32

@brief Counter of threads currently having control over this packet.

@internal

type_: i8

< protocol of the packet snip

Layout

Note: Most layout information is completely unstable and may even differ between compilations. The only exception is types with certain repr(...) attributes. Please see the Rust Reference's “Type Layout” chapter for details on type layout guarantees.

Size: 20 bytes