History log of /freebsd-current/tools/tools/netmap/bridge.c
Revision Date Author Comments
# b3e76948 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

Remove $FreeBSD$: two-line .h pattern

Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/


# e81ecab4 31-Dec-2022 Vincenzo Maffione <vmaffione@FreeBSD.org>

netmap: bridge: fix -Wdate-time compilation issue

MFC after: 3 days


# 51cc3108 30-Mar-2021 Vincenzo Maffione <vmaffione@FreeBSD.org>

netmap: bridge: fix transmission in busy-wait mode

In busy-wait mode (BUSYWAIT defined), NIOCTXSYNC should be
performed after packets have been moved to the TX ring
(rather than before).
Before the change, moved packets may stall for an indefinite
time in the TX ring.

MFC after: 1 week


# 163f4f15 07-Jan-2021 Vincenzo Maffione <vmaffione@FreeBSD.org>

netmap: bridge: fix NS_MOREFRAG support

Support for NS_MOREFRAG is broken, as NS_MOREFRAG is copied from
the TX slot to the RX slot rather than the other way around.
Also, the NS_MOREFRAG must be copied also in case of packet
copy (no zerocopy).

Reported by: rajesh1.kumar_amd.com
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D27980


# 7ebc0ac4 22-Nov-2020 Vincenzo Maffione <vmaffione@FreeBSD.org>

netmap: bridge: improve readability

Multiple cosmetic changes, plus a fix to a verbose print
(indicating wrong net->host/host->net direction).

MFC after: 3 days


# ecfd9756 22-Nov-2020 Vincenzo Maffione <vmaffione@FreeBSD.org>

netmap: bridge: switch to libnetmap

Use the newer libnetmap (included in base) rather than the older
nm_open()/nm_close() defined in netmap_user.h


# 7eb32dc8 03-Oct-2020 Vincenzo Maffione <vmaffione@FreeBSD.org>

netmap: tools: fix several compiler warnings

MFC after: 1 week


# 1a7d3c05 23-Oct-2018 Vincenzo Maffione <vmaffione@FreeBSD.org>

netmap: add man page for the bridge program

Added bridge(8).
Also, minor fixes to the netmap "bridge" application:
- indentation fixes and code cleanup
- better usage description
- better processing of netmap flags

Reviewed by: 0mp
Approved by: gnn (mentor)
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D17664


# 37e3a6d3 16-Oct-2016 Luigi Rizzo <luigi@FreeBSD.org>

Import the current version of netmap, aligned with the one on github.

This commit, long overdue, contains contributions in the last 2 years
from Stefano Garzarella, Giuseppe Lettieri, Vincenzo Maffione, including:
+ fixes on monitor ports
+ the 'ptnet' virtual device driver, and ptnetmap backend, for
high speed virtual passthrough on VMs (bhyve fixes in an upcoming commit)
+ improved emulated netmap mode
+ more robust error handling
+ removal of stale code
+ various fixes to code and documentation (some mixup between RX and TX
parameters, and private and public variables)

We also include an additional tool, nmreplay, which is functionally
equivalent to tcpreplay but operating on netmap ports.


# f0ea3689 14-Feb-2014 Luigi Rizzo <luigi@FreeBSD.org>

This new version of netmap brings you the following:

- netmap pipes, providing bidirectional blocking I/O while moving
100+ Mpps between processes using shared memory channels
(no mistake: over one hundred million. But mind you, i said
*moving* not *processing*);

- kqueue support (BHyVe needs it);

- improved user library. Just the interface name lets you select a NIC,
host port, VALE switch port, netmap pipe, and individual queues.
The upcoming netmap-enabled libpcap will use this feature.

- optional extra buffers associated to netmap ports, for applications
that need to buffer data yet don't want to make copies.

- segmentation offloading for the VALE switch, useful between VMs.

and a number of bug fixes and performance improvements.

My colleagues Giuseppe Lettieri and Vincenzo Maffione did a substantial
amount of work on these features so we owe them a big thanks.

There are some external repositories that can be of interest:

https://code.google.com/p/netmap
our public repository for netmap/VALE code, including
linux versions and other stuff that does not belong here,
such as python bindings.

https://code.google.com/p/netmap-libpcap
a clone of the libpcap repository with netmap support.
With this any libpcap client has access to most netmap
feature with no recompilation. E.g. tcpdump can filter
packets at 10-15 Mpps.

https://code.google.com/p/netmap-ipfw
a userspace version of ipfw+dummynet which uses netmap
to send/receive packets. Speed is up in the 7-10 Mpps
range per core for simple rulesets.

Both netmap-libpcap and netmap-ipfw will be merged upstream at some
point, but while this happens it is useful to have access to them.

And yes, this code will be merged soon. It is infinitely better
than the version currently in 10 and 9.

MFC after: 3 days


# f2637526 15-Jan-2014 Luigi Rizzo <luigi@FreeBSD.org>

netmap_user.h:
add separate rx/tx ring indexes
add ring specifier in nm_open device name

netmap.c, netmap_vale.c
more consistent errno numbers

netmap_generic.c
correctly handle failure in registering interfaces.

tools/tools/netmap/
massive cleanup of the example programs
(a lot of common code is now in netmap_user.h.)

nm_util.[ch] are going away soon.
pcap.c will also go when i commit the native netmap support for libpcap.


# 17885a7b 05-Jan-2014 Luigi Rizzo <luigi@FreeBSD.org>

It is 2014 and we have a new version of netmap.
Most relevant features:

- netmap emulation on any NIC, even those without native netmap support.

On the ixgbe we have measured about 4Mpps/core/queue in this mode,
which is still a lot more than with sockets/bpf.

- seamless interconnection of VALE switch, NICs and host stack.

If you disable accelerations on your NIC (say em0)

ifconfig em0 -txcsum -txcsum

you can use the VALE switch to connect the NIC and the host stack:

vale-ctl -h valeXX:em0

allowing sharing the NIC with other netmap clients.

- THE USER API HAS SLIGHTLY CHANGED (head/cur/tail pointers
instead of pointers/count as before). This was unavoidable to support,
in the future, multiple threads operating on the same rings.
Netmap clients require very small source code changes to compile again.
On the plus side, the new API should be easier to understand
and the internals are a lot simpler.

The manual page has been updated extensively to reflect the current
features and give some examples.

This is the result of work of several people including Giuseppe Lettieri,
Vincenzo Maffione, Michio Honda and myself, and has been financially
supported by EU projects CHANGE and OPENLAB, from NetApp University
Research Fund, NEC, and of course the Universita` di Pisa.


# 0dea02f3 30-May-2013 Luigi Rizzo <luigi@FreeBSD.org>

add a compile-time option to copy packets instead of doing
the buffer swapping.


# f8e4e36a 16-Feb-2013 Luigi Rizzo <luigi@FreeBSD.org>

update the netmap example programs merging some common code in nm_util.c

pkt-gen now implements several functions (unlimited transmit, receive,
ping-pong) and can operate on a 'tap' device.


# f067248f 28-Jun-2012 Ed Maste <emaste@FreeBSD.org>

Fix ioctl type for compiling with clang


# d76bf4ff 13-Apr-2012 Luigi Rizzo <luigi@FreeBSD.org>

A bit of cleanup in the names of fields of netmap-related structures.
Use the name 'ring' instead of 'queue' in all fields.
Bump NETMAP_API.


# aaca8f41 12-Apr-2012 Luigi Rizzo <luigi@FreeBSD.org>

use getopt to parse options, add one option to set
the wait time for link-up events


# 64ae02c3 27-Feb-2012 Luigi Rizzo <luigi@FreeBSD.org>

A bunch of netmap fixes:

USERSPACE:
1. add support for devices with different number of rx and tx queues;

2. add better support for zero-copy operation, adding an extra field
to the netmap ring to indicate how many buffers we have already processed
but not yet released (with help from Eddie Kohler);

3. The two changes above unfortunately require an API change, so while
at it add a version field and some spares to the ioctl() argument
to help detect mismatches.

4. update the manual page for the two changes above;

5. update sample applications in tools/tools/netmap

KERNEL:

1. simplify the internal structures moving the global wait queues
to the 'struct netmap_adapter';

2. simplify the functions that map kring<->nic ring indexes

3. normalize device-specific code, helps mainteinance;

4. start exploring the impact of micro-optimizations (prefetch etc.)
in the ixgbe driver.
Use 'legacy' descriptors on the tx ring and prefetch slots gives
about 20% speedup at 900 MHz. Another 7-10% would come from removing
the explict calls to bus_dmamap* in the core (they are effectively
NOPs in this case, but it takes expensive load of the per-buffer
dma maps to figure out that they are all NULL.

Rx performance not investigated.

I am postponing the MFC so i can import a few more improvements
before merging.


# 8ce070c1 29-Dec-2011 Ulrich Spörlein <uqs@FreeBSD.org>

Spelling fixes for tools/

Add some $FreeBSD$ tags so svn will allow the commit.


# 68b8534b 16-Nov-2011 Luigi Rizzo <luigi@FreeBSD.org>

Bring in support for netmap, a framework for very efficient packet
I/O from userspace, capable of line rate at 10G, see

http://info.iet.unipi.it/~luigi/netmap/

At this time I am bringing in only the generic code (sys/dev/netmap/
plus two headers under sys/net/), and some sample applications in
tools/tools/netmap. There is also a manpage in share/man/man4 [1]

In order to make use of the framework you need to build a kernel
with "device netmap", and patch individual drivers with the code
that you can find in

sys/dev/netmap/head.diff

The file will go away as the relevant pieces are committed to
the various device drivers, which should happen in a few days
after talking to the driver maintainers.

Netmap support is available at the moment for Intel 10G and 1G
cards (ixgbe, em/lem/igb), and for the Realtek 1G card ("re").
I have partial patches for "bge" and am starting to work on "cxgbe".
Hopefully changes are trivial enough so interested third parties
can submit their patches. Interested people can contact me
for advice on how to add netmap support to specific devices.

CREDITS:
Netmap has been developed by Luigi Rizzo and other collaborators
at the Universita` di Pisa, and supported by EU project CHANGE
(http://www.change-project.eu/)
The code is distributed under a BSD Copyright.

[1] In my opinion is a bad idea to have all manpage in one directory.
We should place kernel documentation in the same dir that contains
the code, which would make it much simpler to keep doc and code
in sync, reduce the clutter in share/man/ and incidentally is
the policy used for all of userspace code.
Makefiles and doc tools can be trivially adjusted to find the
manpages in the relevant subdirs.