History log of /freebsd/sys/dev/virtio/network/if_vtnetvar.h (Results 1 – 25 of 72)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# d9e0e426 05-Feb-2024 Warner Losh <imp@FreeBSD.org>

vtnet: Account for the padding when selecting allocation size

While we account for the padding in the length of the mbuf we use, we do
not account for it when we 'guess' the size of the mbuf to allo

vtnet: Account for the padding when selecting allocation size

While we account for the padding in the length of the mbuf we use, we do
not account for it when we 'guess' the size of the mbuf to allocate
based in the MTU of the device. This leads to a situation where we might
fail if the mtu is close to a bucket size (say 2018) such that the added
padding would push us over the edge for a full-sized packet. mtu of 2018
is super rare (2016 and 2020 would both work), but fix it none-the-less.
It's a shame we can't just set VTNET_RX_HEADER_PAD to 2 in this case. The 4
seems hard-coded somewhere I've not found documented (I think it's in the
protocol given the comments about VIRTIO_F_ANY_LAYOUT).

Sponsored by: Netflix
Reviewed by: bz
Differential Revision: https://reviews.freebsd.org/D43656

show more ...


Revision tags: release/14.0.0
# 95ee2897 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

sys: Remove $FreeBSD$: two-line .h pattern

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


# 4d846d26 10-May-2023 Warner Losh <imp@FreeBSD.org>

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix

show more ...


Revision tags: release/13.2.0, release/12.4.0, release/13.1.0
# 4ee96792 01-Mar-2022 Justin Hibbits <jhibbits@FreeBSD.org>

Mechanically convert if_vtnet(4) to IfAPI

Reviewed By: bryanv
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D37799


Revision tags: release/12.3.0, release/13.0.0, release/12.2.0, release/11.4.0, release/12.1.0, release/11.3.0, release/12.0.0, release/11.2.0
# 5afe81a7 26-Oct-2017 Luiz Otavio O Souza <loos@FreeBSD.org>

virtio: enable VTNET_LEGACY_TX when ALTQ is enabled.

ALTQ only works on network drivers which use if_start (rather than
if_transmit). vtnet uses if_start if built with VTNET_LEGACY_TX. Default
to th

virtio: enable VTNET_LEGACY_TX when ALTQ is enabled.

ALTQ only works on network drivers which use if_start (rather than
if_transmit). vtnet uses if_start if built with VTNET_LEGACY_TX. Default
to that the kernel is built with ALTQ enabled, to reduce user surprise.

MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")

show more ...


# c1b554c8 22-Feb-2021 Alex Richardson <arichardson@FreeBSD.org>

if_vtnet: Fix pointer-sign and used parameter warnings

Reviewed By: grehan
Differential Revision: https://reviews.freebsd.org/D28726


# 2bfab357 19-Jan-2021 Bryan Venteicher <bryanv@FreeBSD.org>

if_vtnet: Add counter for received host LRO

Reviewed by: grehan (mentor)
Differential Revision: https://reviews.freebsd.org/D27928


# 475a60ae 19-Jan-2021 Bryan Venteicher <bryanv@FreeBSD.org>

if_vtnet: Misc Tx path cleanup

- Add and fix a few error path counters
- Improve sysctl descriptions
- Use flags consistently to determine IPv4 vs IPv6

Reviewed by: grehan (mentor)
Differenti

if_vtnet: Misc Tx path cleanup

- Add and fix a few error path counters
- Improve sysctl descriptions
- Use flags consistently to determine IPv4 vs IPv6

Reviewed by: grehan (mentor)
Differential Revision: https://reviews.freebsd.org/D27926

show more ...


# 74cd316a 19-Jan-2021 Bryan Venteicher <bryanv@FreeBSD.org>

if_vtnet: Resort softc fields

Reviewed by: grehan (mentor)
Differential Revision: https://reviews.freebsd.org/D27925


# c3187190 19-Jan-2021 Bryan Venteicher <bryanv@FreeBSD.org>

if_vtnet: Disable F_MTU feature if MTU is invalid

Reviewed by: grehan (mentor)
Differential Revision: https://reviews.freebsd.org/D27931


# b470419e 19-Jan-2021 Bryan Venteicher <bryanv@FreeBSD.org>

if_vtnet: Rework 4be723f63 max multiqueue pairs check

Verify the max_virtqueue_pairs is within the range allowed by
the spec.

Reviewed by: grehan (mentor)
Differential Revision: https://reviews.fre

if_vtnet: Rework 4be723f63 max multiqueue pairs check

Verify the max_virtqueue_pairs is within the range allowed by
the spec.

Reviewed by: grehan (mentor)
Differential Revision: https://reviews.freebsd.org/D27920

show more ...


# 42343a63 19-Jan-2021 Bryan Venteicher <bryanv@FreeBSD.org>

if_vtnet: Add support for software LRO

This useful when running on hosts that support checksum offloading
but not the GUEST_TSO (LRO) feature. Or potentially, some GRO-like
support when doing forwar

if_vtnet: Add support for software LRO

This useful when running on hosts that support checksum offloading
but not the GUEST_TSO (LRO) feature. Or potentially, some GRO-like
support when doing forwarding.

Only enable SW LRO when the host LRO is not available since both
tends to be harmful, and difficult to enable/disable selectively
with only a single IFCAP_LRO flag.

Reviewed by: grehan (mentor)
Differential Revision: https://reviews.freebsd.org/D27919

show more ...


# e36a6b1b 19-Jan-2021 Bryan Venteicher <bryanv@FreeBSD.org>

if_vtnet: Add support for CTRL_GUEST_OFFLOADS feature

This allows the Rx checksum and LRO to be modified without a full
reinit of the device.

Remove IFCAP_RXCSUM_IPV6 from the interface capabilitie

if_vtnet: Add support for CTRL_GUEST_OFFLOADS feature

This allows the Rx checksum and LRO to be modified without a full
reinit of the device.

Remove IFCAP_RXCSUM_IPV6 from the interface capabilities since in
VirtIO Rx checksums are just enabled or disabled for all protocols.

Properly update IFCAP_LRO if LRO is becomes disabled when Rx
checksums are disabled.

Reviewed by: grehan (mentor)
Differential Revision: https://reviews.freebsd.org/D27916

show more ...


# 44559b26 19-Jan-2021 Bryan Venteicher <bryanv@FreeBSD.org>

if_vtnet: Cleanup the reinit process

In modern VirtIO, the virtqueues cannot be notified before setting
DRIVER_OK status.

Reviewed by: grehan (mentor)
Differential Revision: https://reviews.freebsd

if_vtnet: Cleanup the reinit process

In modern VirtIO, the virtqueues cannot be notified before setting
DRIVER_OK status.

Reviewed by: grehan (mentor)
Differential Revision: https://reviews.freebsd.org/D27932

show more ...


# baa5234f 19-Jan-2021 Bryan Venteicher <bryanv@FreeBSD.org>

if_vtnet: Move the Tx interrupt threshold into the Txq structure

Reviewed by: grehan (mentor)
Differential Revision: https://reviews.freebsd.org/D27911


# 6a733393 19-Jan-2021 Bryan Venteicher <bryanv@FreeBSD.org>

if_vtnet: Support VIRTIO_NET_F_SPEED_DUPLEX

This features lets the guest driver know the speed and duplex of
the "link". Instead of trying to support many media types based
on the possible/likely sp

if_vtnet: Support VIRTIO_NET_F_SPEED_DUPLEX

This features lets the guest driver know the speed and duplex of
the "link". Instead of trying to support many media types based
on the possible/likely speeds/duplexes, only use the speed to
set the interface baudrate.

Cleanup ifmedia code to match other drivers.

Reviewed by: grehan (mentor)
Differential Revision: https://reviews.freebsd.org/D27908

show more ...


# aabdf5b6 19-Jan-2021 Bryan Venteicher <bryanv@FreeBSD.org>

if_vtnet: Support VIRTIO_NET_F_MTU

This feature lets the guest driver know the maximum MTU size
supported by the host device. If set, use this to limit the
acceptable MTUs, and improve how the recei

if_vtnet: Support VIRTIO_NET_F_MTU

This feature lets the guest driver know the maximum MTU size
supported by the host device. If set, use this to limit the
acceptable MTUs, and improve how the receive mbuf cluster size
then is selected.

Reviewed by: grehan (mentor)
Differential Revision: https://reviews.freebsd.org/D27907

show more ...


# fa7ca1e3 19-Jan-2021 Bryan Venteicher <bryanv@FreeBSD.org>

if_vtnet: Rx path cleanup

- Fix the NEEDS_CSUM and DATA_VALID checksum flags. The NEEDS_CSUM
checksum is incomplete (partial) so offer a fallback for the driver
to calculate the checksum.

if_vtnet: Rx path cleanup

- Fix the NEEDS_CSUM and DATA_VALID checksum flags. The NEEDS_CSUM
checksum is incomplete (partial) so offer a fallback for the driver
to calculate the checksum. Simplify DATA_VALID because we know
the host has validated the checksum.

- Default 4K mbuf clusters for mergeable buffers. May need to
scale this down to 2K clusters in certain configurations such
many queue pairs, big queues (like 4096 in GCP), and low memory.

- Use the MTU when calculated the receive mbuf cluster size
when not doing TSO/LRO. This will need more adjustment once
the MTU feature is supported.

Reviewed by: grehan (mentor)
Differential Revision: https://reviews.freebsd.org/D27906

show more ...


# 5e220811 19-Jan-2021 Bryan Venteicher <bryanv@FreeBSD.org>

if_vtnet: Add initial modern (V1) support

Very basic support to get packets flowing on modern QEMU but still
several conformance issues remain that will be addressed in later
commits.

First of many

if_vtnet: Add initial modern (V1) support

Very basic support to get packets flowing on modern QEMU but still
several conformance issues remain that will be addressed in later
commits.

First of many passes at cleaning up various accumulated cruft

Reviewed by: grehan (mentor)
Differential Revision: https://reviews.freebsd.org/D27904

show more ...


# 1cd1ed3f 19-Jan-2021 Bryan Venteicher <bryanv@FreeBSD.org>

Revert: virtio: Support non-legacy network device and queue

And subsequent fix 576b099a.

By adding the mergable header to the vtnet_rx_header structure, the size
was increased by 2 bytes, breaking

Revert: virtio: Support non-legacy network device and queue

And subsequent fix 576b099a.

By adding the mergable header to the vtnet_rx_header structure, the size
was increased by 2 bytes, breaking the alignment of this structure as
described the in preceding comments.

Furthermore, the mergable header does not belong the structure. With the
mergable feature, the header is placed in line with the data, so there is
no need for a separate segment, and misleading to follow the mergable
header with any padding.

The V1 header is effectively identical to mergable header, and the driver
has long supported the mergable feature. Revert this so the later changes
that add V1 support can show how V1 is derived from the existing mergable
buffers support, and to facilitate a later MFC.

Reviewed by: grehan (mentor)
Differential Revision: https://reviews.freebsd.org/D27855

show more ...


# 16f224b5 14-Jun-2020 Vincenzo Maffione <vmaffione@FreeBSD.org>

netmap: vtnet: fix races in vtnet_netmap_reg()

The nm_register callback needs to call nm_set_native_flags()
or nm_clear_native_flags() once the device has been stopped.
However, in the current imple

netmap: vtnet: fix races in vtnet_netmap_reg()

The nm_register callback needs to call nm_set_native_flags()
or nm_clear_native_flags() once the device has been stopped.
However, in the current implementation this is not true,
as the device is stopped by vtnet_init_locked(). This causes
race conditions where the driver crashes as soon as it
dequeues netmap buffers assuming they are mbufs (or the other
way around).
To fix the issue, we extend vtnet_init_locked() with a second
argument that, if not zero, will set/clear the netmap flags.
This results in a huge simplification of the nm_register
callback itself.
Also, use netmap_reset() to check if a ring is going to be
re-initialized in netmap mode.

MFC after: 1 week

show more ...


# 8c3988df 08-Jun-2020 Jessica Clarke <jrtc27@FreeBSD.org>

virtio: Support non-legacy network device and queue

The non-legacy interface always defines num_buffers in the header,
regardless of whether VIRTIO_NET_F_MRG_RXBUF, just leaving it unused. We
also n

virtio: Support non-legacy network device and queue

The non-legacy interface always defines num_buffers in the header,
regardless of whether VIRTIO_NET_F_MRG_RXBUF, just leaving it unused. We
also need to ensure our virtqueue doesn't filter out VIRTIO_F_VERSION_1
during negotiation, as it supports non-legacy transports just fine. This
fixes network packet transmission on TinyEMU.

Reviewed by: br, brooks (mentor), jhb (mentor)
Approved by: br, brooks (mentor), jhb (mentor)
Differential Revision: https://reviews.freebsd.org/D25132

show more ...


# 2d769e25 03-Jun-2020 Vincenzo Maffione <vmaffione@FreeBSD.org>

netmap: vtnet: add vtnrx_nm_refill index to receive queues

The new index tracks the next netmap slot that is going
to be enqueued into the virtqueue. The index is necessary
to prevent the receive VQ

netmap: vtnet: add vtnrx_nm_refill index to receive queues

The new index tracks the next netmap slot that is going
to be enqueued into the virtqueue. The index is necessary
to prevent the receive VQ and the netmap rx ring from going
out of sync, considering that we never enqueue N slots, but
at most N-1. This change fixes a bug that causes the VQ
and the netmap ring to go out of sync after N-1 packets
have been received.

MFC after: 1 week

show more ...


# ed6cbf48 10-Jan-2020 Gleb Smirnoff <glebius@FreeBSD.org>

Add pfil(9) hook to vtnet(4).

The patch could be simplier, using only the second chunk to
vtnet_rxq_eof(), that passes full mbufs to pfil(9). Packet
filter would m_free() them in case of returning P

Add pfil(9) hook to vtnet(4).

The patch could be simplier, using only the second chunk to
vtnet_rxq_eof(), that passes full mbufs to pfil(9). Packet
filter would m_free() them in case of returning PFIL_DROPPED.

However, we pretend to be a hardware driver, so we first try
to pass a memory buffer via PFIL_MEMPTR feature. This is mostly
done for debugging purposes, so that one can experiment in bhyve
with packet filters utilizing same features as a true driver.

show more ...


# 7648bc9f 13-May-2019 Alan Somers <asomers@FreeBSD.org>

MFHead @347527

Sponsored by: The FreeBSD Foundation


123