lib: replace packed attributes

MSVC struct packing is not compatible with GCC. Replace macro
__rte_packed with __rte_packed_begin to push existing pack value
and set packing to 1-byte and macro __rt

lib: replace packed attributes

MSVC struct packing is not compatible with GCC. Replace macro
__rte_packed with __rte_packed_begin to push existing pack value
and set packing to 1-byte and macro __rte_packed_end to restore
the pack value prior to the push.

Macro __rte_packed_end is deliberately utilized to trigger a
MSVC compiler warning if no existing packing has been pushed allowing
easy identification of locations where the __rte_packed_begin is
missing.

Signed-off-by: Andre Muezerie <andremue@linux.microsoft.com>

show more ...

use C linkage where appropriate in headers

Assure that 'extern "C" { /../ }' do not cover files included from a
particular header file, and address minor issues resulting from this
change of order.

use C linkage where appropriate in headers

Assure that 'extern "C" { /../ }' do not cover files included from a
particular header file, and address minor issues resulting from this
change of order.

Dealing with C++ should delegate to the individual include file level,
rather than being imposed by the user of that file. For example,
forcing C linkage prevents __Generic macros being replaced with
overloaded static inline functions in C++ translation units.

Eliminate 'extern "C"' from files which do not declare any symbols
(e.g., only macros or struct types).

On the other hand, the headers check is too naive in assuming that all
headers must contain a 'extern "C"'. Such a check was added in commit
1ee492bdc4ff ("buildtools/chkincs: check missing C++ guards").
Since this current change results in many headers not containing such
a token, remove the check for 'extern "C"' until we have a better
implementation.

Signed-off-by: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Signed-off-by: David Marchand <david.marchand@redhat.com>

show more ...

net: extend VXLAN header to support more extensions

VXLAN and VXLAN-GPE were supported with similar header structures.
In order to add VXLAN-GBP, which is another extension to VXLAN, both
extensions

net: extend VXLAN header to support more extensions

VXLAN and VXLAN-GPE were supported with similar header structures.
In order to add VXLAN-GBP, which is another extension to VXLAN, both
extensions are merged in the original VXLAN header structure for an easier
usage. More VXLAN extensions may be added in the future in the same single
structure.

VXLAN and VXLAN-GBP use the same UDP port (4789), while VXLAN-GPE uses a
different port (4790).
The three protocols have the same header length and overall a similar
header structure as below.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|R|R|R|I|R|R|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VXLAN Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: VXLAN Header

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|R|Ver|I|P|B|O| Reserved |Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VXLAN Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: VXLAN-GPE Header

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|R|R|R|I|R|R|R|R|D|R|R|A|R|R|R| Group Policy ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VXLAN Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: VXLAN-GBP Extension

Both GPE and GBP are extending VXLAN by using some reserved bits.
It means the packets can be processed with the same pattern and most of
the code can be reused.

The old field names are kept with the use of anonymous unions.
The Group Policy ID (GBP) and the Next Protocol (GPE) fields are
overlapping so they are in a union as well.

Another improvement is defining and documenting each bit.

Instead of adding flow items, a single VXLAN flow item is more flexible
as it uses the same header anyway.
GBP can be matches with the G bit.
GPE can be matched with the UDP port number.

VXLAN-GPE flow item and specific header are marked as deprecated.
A removal of the deprecated structures and macros may be proposed later.

Signed-off-by: Gavin Li <gavinl@nvidia.com>
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>

show more ...

ethdev: add VXLAN last reserved field

Add "uint8_t last_rsvd" as union with origin rsvd1.
Add RTE_FLOW_FIELD_VXLAN_LAST_RSVD into rte flow packet
field.

The new union is used by testpmd matching it

ethdev: add VXLAN last reserved field

Add "uint8_t last_rsvd" as union with origin rsvd1.
Add RTE_FLOW_FIELD_VXLAN_LAST_RSVD into rte flow packet
field.

The new union is used by testpmd matching item VXLAN
"last_rsvd" and modify target RTE_FLOW_FIELD_VXLAN_LAST_RSVD.

Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
Acked-by: Dariusz Sosnowski <dsosnowski@nvidia.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>

show more ...

net: add smaller fields for VXLAN

The VXLAN and VXLAN-GPE headers were including reserved fields
with other fields in big uint32_t struct members.

Some more precise definitions are added as union o

net: add smaller fields for VXLAN

The VXLAN and VXLAN-GPE headers were including reserved fields
with other fields in big uint32_t struct members.

Some more precise definitions are added as union of the old ones.

The new struct members are smaller in size and in names.

Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: Ferruh Yigit <ferruh.yigit@amd.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>

show more ...

lib: remove librte_ prefix from directory names

There is no reason for the DPDK libraries to all have 'librte_' prefix on
the directory names. This prefix makes the directory names longer and also
m

lib: remove librte_ prefix from directory names

There is no reason for the DPDK libraries to all have 'librte_' prefix on
the directory names. This prefix makes the directory names longer and also
makes it awkward to add features referring to individual libraries in the
build - should the lib names be specified with or without the prefix.
Therefore, we can just remove the library prefix and use the library's
unique name as the directory name, i.e. 'eal' rather than 'librte_eal'

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>

show more ...