lib: use log helper with prefix

Use RTE_LOG_LINE_PREFIX instead of RTE_LOG_LINE in macro expansions
which allows a prefix and arguments to be inserted into the log line
without the need to use the #

lib: use log helper with prefix

Use RTE_LOG_LINE_PREFIX instead of RTE_LOG_LINE in macro expansions
which allows a prefix and arguments to be inserted into the log line
without the need to use the ## args variadic argument pack extension.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>

show more ...

lib: use per line logging in helpers

Use RTE_LOG_LINE in existing macros that append a \n.
This will help catching unwanted newline character or multilines
in log messages.

Signed-off-by: David Mar

lib: use per line logging in helpers

Use RTE_LOG_LINE in existing macros that append a \n.
This will help catching unwanted newline character or multilines
in log messages.

Signed-off-by: David Marchand <david.marchand@redhat.com>
Reviewed-by: Chengwen Feng <fengchengwen@huawei.com>
Reviewed-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>

show more ...

lib: replace logging helpers

This is a preparation step before the next change.

Many libraries have their own logging helpers that do not add a newline
in their format string.
Some previous changes

lib: replace logging helpers

This is a preparation step before the next change.

Many libraries have their own logging helpers that do not add a newline
in their format string.
Some previous changes fixed places where some of those helpers are
called without a trailing newline.
Using RTE_LOG_LINE in the existing helpers will ensure we don't
introduce new issues in the future.

The problem is that if we simply convert to the RTE_LOG_LINE helper,
a future fix may introduce a regression since the logging helper
change won't be backported.

To address this concern, rename existing helpers: backporting a call to
them will trigger some conflict or build issue in LTS branches.

Note:
- bpf and vhost that still has some debug multilines messages, a direct
call to RTE_LOG/RTE_LOG_DP is used: this will make it easier to notice
such special cases,
- about previously publicly exposed logging helpers, when such helper is
not publicly used (iow in public inline API), it is removed from the
public API (this is the case for the member library),

Signed-off-by: David Marchand <david.marchand@redhat.com>
Reviewed-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>

show more ...

lib: restrict use of keyword extern

Variable declarations in header files are using extern, it is valid.
But function declarations do not need the keyword extern.

Also, extern "C" should have a spa

lib: restrict use of keyword extern

Variable declarations in header files are using extern, it is valid.
But function declarations do not need the keyword extern.

Also, extern "C" should have a space after the keyword extern.

Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>

show more ...

bpf: rename functions to avoid conflict with libpcap

The library libpcap has their function 'bpf_validate' either
so there would be a multiple definition issue when linking
with librte_bpf.a and lib

bpf: rename functions to avoid conflict with libpcap

The library libpcap has their function 'bpf_validate' either
so there would be a multiple definition issue when linking
with librte_bpf.a and libpcap.a statically
(Same as http://dpdk.org/patch/52631).
So just rename the function names to avoid such issue.

Signed-off-by: J.J. Martzki <mars14850@gmail.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>

show more ...

bpf: fix build with some libpcap version on FreeBSD

This is something caught in UNH FreeBSD env.

For some reason [1], the pcap/bpf.h header started to define _BPF_H_.

It happens that the bpf_impl.

bpf: fix build with some libpcap version on FreeBSD

This is something caught in UNH FreeBSD env.

For some reason [1], the pcap/bpf.h header started to define _BPF_H_.

It happens that the bpf_impl.h internal DPDK header uses this define as
an internal guard.
This triggers a build failure in bpf_convert.c which can't find
RTE_BPF_LOG macro.

Fix the include guard to use the filename and remove _.

1: https://github.com/the-tcpdump-group/libpcap/pull/1074

Fixes: 94972f35a02e ("bpf: add BPF loading and execution framework")
Cc: stable@dpdk.org

Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>

show more ...

lib: remove C++ include guard from private headers

The private headers are compiled internally with a C compiler.
Thus extern "C" declaration is useless in such files.

Signed-off-by: Thomas Monjalo

lib: remove C++ include guard from private headers

The private headers are compiled internally with a C compiler.
Thus extern "C" declaration is useless in such files.

Signed-off-by: Thomas Monjalon <thomas@monjalon.net>

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 ...