Add an option to enable/disable sending and respecting PAUSE frames as defined in
802.3x and 802.3z specifications. We will configure the Link level PAUSEs
(as opposed to PFC).
In simple words Ethernel Flow Control relies on sending/receiving PAUSE (XOFF) MAC frames that
indicate the sender that receiver's buffer is almost full. The idea is to avoid receive buffer overflow. When
receiver's buffer is being freed it will send XON frame to indicate to the sender that it may
transmit again.
- Added DPDK-specific command option to toggle the feature.
- Sending PAUSEs is enabled by default.
Signed-off-by: Vlad Zolotarov <vladz@cloudius-systems.com>
- Added LRO ON/OFF native stack command line parameter.
- Implemented handling the reception of a clustered packet:
- Without hugetlbfs: allocate a single buffer to contain the whole
packet's data and copy its contents into it. If the allocation failed - build
the "packet" directly from the cluster.
- With hugetlbfs: create a packet from cluster mbuf's data buffers.
Signed-off-by: Vlad Zolotarov <vladz@cloudius-systems.com>
New in v3:
- Use RTE_ETHDEV_HAS_LRO_SUPPORT defined in rte_ethdev.h instead of
RTE_ETHDEV_LRO_SUPPORT defined in config/common_linuxapp.
New in v2:
- dpdk_qp<false>::from_mbuf_lro(): Free the cluster after copying
to the allocated buffer.
- Some style cleanups.
Build a 128-entry redirection table to select which cpu services which
packet, when we have more cores than queues (and thus need to dispatch
internally).
Add a --hw-queue-weight to control the relative weight of the hardware queue.
With a weight of 0, the core that services the hardware queue will not
process any packets; with a weight of 1 (default) it will process an equal
share of packets, compared to proxy queues.
The current shared_ptr implementation is efficient, but does not support
polymorphic types.
Rename it in order to make room for a polymorphic shared_ptr.
1) Make --dpdk-pmd parameter to be a flag instead of a (key, value).
2) Default to a default hugetlbfs DPDK settings when --hugepages is not
given and --dpdk-pmd is set.
This will allow a more friendly user experience in general and when one doesn't
want to provide a --hugepages parameter in particular.
Signed-off-by: Vlad Zolotarov <vladz@cloudius-systems.com>
- Move the smp::dpdk_eal_init() code into the dpdk::eal::init() where it belongs.
- Removed the unused "opts" parameter of dpdk::dpdk_device constructor - all its usage
has been moved to dpdk::eal::init().
- Cleanup in reactor.cc: #if HAVE_DPDK -> #ifdef HAVE_DPDK; since we give a -DHAVE_DPDK
option to a compiler.
Signed-off-by: Vlad Zolotarov <vladz@cloudius-systems.com>
This patch introduce a logic to divide cpus between available hw queue
pairs. Each cpu with hw qp gets a set of cpus to distribute traffic
to. The algorithm doesn't take any topology considerations into account yet.
Instead of returning special value from forward() to broadcast arm reply
call arp.learn() on all cpus at arp protocol lever. The ability of
forward() to return special value will be removed by later patches.
Currently dhcp assumes that cpu 0 gets all the packets and redistributes
them by itself. With multiqueue this is not necessary the case, so the
current trick to disable forwarding by installing special dhcp forward()
function will not work. Rework it by installing packet filter on all
cpus before running dhcp and forward all dhcp packets to cpu 0.
This patch adds new class distributed_device which is responsible for
initializing HW device and it is shared between all cpus. Old device
class responsibility becomes managing rx/tx queue pair and it is local
per cpu. Each cpu have to call distributed_device::init_local_queue() to
create its own device. The logic to distribute cpus between available
queues (in case there is no enough queues for each cpu) is in the
distributed_device currently and not really implemented yet, so only one
queue or queues == cpus scenarios are supported currently, but this can
be fixed later.
The plan is to rename "distributed_device" to "device" and "device"
to "queue_pair" in later patches.
- Create a new class dpdk_eal that initializes DPDK EAL.
- Get rid of portmask crap and provide a port index to a dpdk::net_device
constructor.
Signed-off-by: Vlad Zolotarov <vladz@cloudius-systems.com>
Currently each cpu creates network device as part of native networking
stack creation and all cpus create native networking stack independently,
which makes it impossible to use data initialized by one cpu in another
cpu's networking device initialization. For multiqueue devices often some
parts of an initialization have to be handled by one cpu and all other
cpus should wait for the first one before creating their network devices.
Even without multiqueue proxy devices should be created after master
device is created so that proxy device may get a pointer to the master
at creation time (existing code uses global per cpu device pointer and
assume that master device is created on cpu 0 to compensate for the lack
of ordering).
This patch makes it possible to delay native networking stack creation
until network device is created. It allows one cpu to be responsible
for creation of network devices on multiple cpus. Single queue device
initialize master device on one cpu and call other cpus with a pointer
to master device and its cpu id which are used in proxy device creation.
This removes the need for per cpu device pointer and "master on cpu 0"
assumption from the code since now master device and slave devices know
about each other and can communicate directly.
- Added "dpdk-pmd" option:
- Defaulted to FALSE.
- When TRUE - use DPDK PMD drivers.
- Call for dpdk net_device creation function if dpdk-poll option is given
- Added DPDK networking backend options to all options list
Signed-off-by: Vlad Zolotarov <vladz@cloudius-systems.com>
Network device has to be available when network stack is created, but
sometimes network device creation should wait for device initialization
by another cpu. This patch makes it possible to delay network stack
creation until network device is available.
POSIX stack does not allow one to bind more than one socket to given
port. Native stack on the other hand does. The way services are set up
depends on that. For instance, on native stack one might want to start
the service on all cores, but on POSIX stack only on one of them.
If we don't, we start the system before we have an IP address, and when
we actually do get the IP address, we fail an assert on the _config promise,
which was already fulfilled.
Fixes the following link errors when Xen support is disabled:
build/release/net/native-stack.o: In function `net::add_native_net_options_description(boost::program_options::options_description&)':
/seastar/net/native-stack.cc:101: undefined reference to `get_xenfront_net_options_description()'
build/release/net/native-stack.o: In function `net::create_native_net_device(boost::program_options::variables_map)':
/seastar/net/native-stack.cc:93: undefined reference to `create_xenfront_net_device(boost::program_options::variables_map, bool)'
collect2: error: ld returned 1 exit status
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Simple discovery class + usage of it in the native stack init.
DHCP discovery will be default if no other ip options are set on command
line, and not explicitly turned off.
Signed-off-by: Calle Wilund <calle@cloudius-systems.com>
