MFC r303971:

Fix vtnet hang with max_virtqueue_pairs > VTNET_MAX_QUEUE_PAIRS

Sponsored by: Multiplay

MFC r284348: Fix panic when adding vtnet interfaces to a bridge

vtnet interfaces are always in promiscuous mode (at least if the
VIRTIO_NET_F_CTRL_RX feature is not negotiated with the host). if_promisc() on
a vtnet interface returned ENOTSUP although it has IFF_PROMISC set. This
confused the bridge code. Instead we now accept all enable/disable promiscuous
commands (and always keep IFF_PROMISC set).

There are also two issues with the if_bridge error handling.

If if_promisc() fails it uses bridge_delete_member() to clean up. This tries to
disable promiscuous mode on the interface. That runs into an assert, because
promiscuous mode was never set in the first place. (That's the panic reported in
PR 200210.)
We can only unset promiscuous mode if the interface actually is promiscuous.
This goes against the reference counting done by if_promisc(), but only the
first/last if_promic() calls can actually fail, so this is safe.

A second issue is a double free of bif. It's already freed by
bridge_delete_member().

PR: 200210

MFC 282241:
Don't free mbufs when stopping an interface in netmap mode.

Currently if you ifconfig down a vtnet interface while it is being used
via netmap, the kernel panics due to trying to treat the cookie values
in the virtio rings as mbufs to be freed. When netmap is enabled, these
cookie values are pointers to something else.

Note that other netmap-aware drivers don't seem to need this as they
store the mbuf pointers in the software rings that mirror the hardware
descriptor rings, and since netmap doesn't touch those, the software
state always has NULL mbuf pointers causing the loops to free mbufs to
not do anything. However, vtnet reuses the same state area for both
netmap and non-netmap mode, so it needs to explicitly avoid looking at
the rings and treating the cookie values as mbufs if netmap is
enabled.

Sponsored by: Norse Corp, Inc.

MFC r275358 r275483 r276982 - Removing M_FLOWID by hps@

r275358:
Start process of removing the use of the deprecated "M_FLOWID" flag
from the FreeBSD network code. The flag is still kept around in the
"sys/mbuf.h" header file, but does no longer have any users. Instead
the "m_pkthdr.rsstype" field in the mbuf structure is now used to
decide the meaning of the "m_pkthdr.flowid" field. To modify the
"m_pkthdr.rsstype" field please use the existing "M_HASHTYPE_XXX"
macros as defined in the "sys/mbuf.h" header file.

This patch introduces new behaviour in the transmit direction.
Previously network drivers checked if "M_FLOWID" was set in "m_flags"
before using the "m_pkthdr.flowid" field. This check has now now been
replaced by checking if "M_HASHTYPE_GET(m)" is different from
"M_HASHTYPE_NONE". In the future more hashtypes will be added, for
example hashtypes for hardware dedicated flows.

"M_HASHTYPE_OPAQUE" indicates that the "m_pkthdr.flowid" value is
valid and has no particular type. This change removes the need for an
"if" statement in TCP transmit code checking for the presence of a
valid flowid value. The "if" statement mentioned above is now a direct
variable assignment which is then later checked by the respective
network drivers like before.

r275483:
Remove M_FLOWID from SCTP code.

r276982:
Remove no longer used "M_FLOWID" flag from mbuf.h and update the netisr
manpage.

Note: The FreeBSD version has been bumped.

Reviewed by: hps, tuexen
Sponsored by: Limelight Networks

MFC r276491:

Add softc flag for when the indirect descriptor feature was negotiated

MFC r276489:

Use the appropriate IPv4 or IPv6 TSO HW assist flag

MFC r274325:

Enable LRO by default when available on vtnet interfaces

The prior change to not enable LRO by default has confused several
people. The configurations where LRO is problematic is not the
typical use case for VirtIO, and due to other issues, this often
requires checksum offloading to be disabled anyways.

MFC r270063 (vtnet)

The vtnet changes were not originally merged in r270252 since
r268480 and r268481 had not been MFC'ed.

MFC r268481:

Rework when the Tx queue completion interrupt is enabled

The Tx interrupt is now kept disabled in the common case, only
enabled when the number of free descriptors in the queue falls
below a threshold. Transmitted frames are cleared from the VQ
before subsequent transmit, or in the watchdog timer.

This was a very big performance improvement for an experimental
Netmap bhyve backend.

MFC r267520, r267521, r267522, r267523, r267524:

- Remove two write-only local variables
- Remove unused element in the vtnet_rxq structure
- Remove kernel specific macro out of the VirtIO PCI header file
- Move the VIRTIO_RING_F_* defines out of virtqueue.h into
virtio_config.h
- Make the feature negotiation code easier to follow
- Force two byte alignment for all control message headers

MFC svn 267065 and 267187

make sure ifp->if_transmit returns 0 if a buffer is enqueued.
This should also be merged to stable/9.

After this fix, drivers still known to have this bug are igxbe/ixv
and i40e.

Drivers using if_transmit are correct, and so are most of the
other drivers that reassing if_transmit.

Among other things, this bug causes panics when using netmap emulation
on top of generic drivers.

MFC r261150, r261151, r261164, r261166, r261167, r261168, r261394, r261395:

- Read and write the MAC address in the config space byte by byte
- Also include the mbuf's csum_flags in an assert message
- Remove stray space
- Move duplicated transmit start code into a single function
- Avoid queue unlock followed by relock when the enable interrupt race
is lost
- Check for a full virtqueue in the multiqueue transmit path
- Do not place the sglist used for Rx/Tx on the stack
- Use m_defrag() instead of m_collapse() to compact a long mbuf chain

MFC r284348: Fix panic when adding vtnet interfaces to a bridge

vtnet interfaces are always in promiscuous mode (at least if the
VIRTIO_NET_F_CTRL_RX feature is not negotiated with the host). if_promisc() on
a vtnet interface returned ENOTSUP although it has IFF_PROMISC set. This
confused the bridge code. Instead we now accept all enable/disable promiscuous
commands (and always keep IFF_PROMISC set).

There are also two issues with the if_bridge error handling.

If if_promisc() fails it uses bridge_delete_member() to clean up. This tries to
disable promiscuous mode on the interface. That runs into an assert, because
promiscuous mode was never set in the first place. (That's the panic reported in
PR 200210.)
We can only unset promiscuous mode if the interface actually is promiscuous.
This goes against the reference counting done by if_promisc(), but only the
first/last if_promic() calls can actually fail, so this is safe.

A second issue is a double free of bif. It's already freed by
bridge_delete_member().

PR: 200210

MFC 282241:
Don't free mbufs when stopping an interface in netmap mode.

Currently if you ifconfig down a vtnet interface while it is being used
via netmap, the kernel panics due to trying to treat the cookie values
in the virtio rings as mbufs to be freed. When netmap is enabled, these
cookie values are pointers to something else.

Note that other netmap-aware drivers don't seem to need this as they
store the mbuf pointers in the software rings that mirror the hardware
descriptor rings, and since netmap doesn't touch those, the software
state always has NULL mbuf pointers causing the loops to free mbufs to
not do anything. However, vtnet reuses the same state area for both
netmap and non-netmap mode, so it needs to explicitly avoid looking at
the rings and treating the cookie values as mbufs if netmap is
enabled.

Sponsored by: Norse Corp, Inc.

MFC r275358 r275483 r276982 - Removing M_FLOWID by hps@

r275358:
Start process of removing the use of the deprecated "M_FLOWID" flag
from the FreeBSD network code. The flag is still kept around in the
"sys/mbuf.h" header file, but does no longer have any users. Instead
the "m_pkthdr.rsstype" field in the mbuf structure is now used to
decide the meaning of the "m_pkthdr.flowid" field. To modify the
"m_pkthdr.rsstype" field please use the existing "M_HASHTYPE_XXX"
macros as defined in the "sys/mbuf.h" header file.

This patch introduces new behaviour in the transmit direction.
Previously network drivers checked if "M_FLOWID" was set in "m_flags"
before using the "m_pkthdr.flowid" field. This check has now now been
replaced by checking if "M_HASHTYPE_GET(m)" is different from
"M_HASHTYPE_NONE". In the future more hashtypes will be added, for
example hashtypes for hardware dedicated flows.

"M_HASHTYPE_OPAQUE" indicates that the "m_pkthdr.flowid" value is
valid and has no particular type. This change removes the need for an
"if" statement in TCP transmit code checking for the presence of a
valid flowid value. The "if" statement mentioned above is now a direct
variable assignment which is then later checked by the respective
network drivers like before.

r275483:
Remove M_FLOWID from SCTP code.

r276982:
Remove no longer used "M_FLOWID" flag from mbuf.h and update the netisr
manpage.

Note: The FreeBSD version has been bumped.

Reviewed by: hps, tuexen
Sponsored by: Limelight Networks

MFC r276491:

Add softc flag for when the indirect descriptor feature was negotiated

MFC r276489:

Use the appropriate IPv4 or IPv6 TSO HW assist flag

MFC r274325:

Enable LRO by default when available on vtnet interfaces

The prior change to not enable LRO by default has confused several
people. The configurations where LRO is problematic is not the
typical use case for VirtIO, and due to other issues, this often
requires checksum offloading to be disabled anyways.

MFC r270063 (vtnet)

The vtnet changes were not originally merged in r270252 since
r268480 and r268481 had not been MFC'ed.

MFC r268481:

Rework when the Tx queue completion interrupt is enabled

The Tx interrupt is now kept disabled in the common case, only
enabled when the number of free descriptors in the queue falls
below a threshold. Transmitted frames are cleared from the VQ
before subsequent transmit, or in the watchdog timer.

This was a very big performance improvement for an experimental
Netmap bhyve backend.

MFC r267520, r267521, r267522, r267523, r267524:

- Remove two write-only local variables
- Remove unused element in the vtnet_rxq structure
- Remove kernel specific macro out of the VirtIO PCI header file
- Move the VIRTIO_RING_F_* defines out of virtqueue.h into
virtio_config.h
- Make the feature negotiation code easier to follow
- Force two byte alignment for all control message headers

MFC svn 267065 and 267187

make sure ifp->if_transmit returns 0 if a buffer is enqueued.
This should also be merged to stable/9.

After this fix, drivers still known to have this bug are igxbe/ixv
and i40e.

Drivers using if_transmit are correct, and so are most of the
other drivers that reassing if_transmit.

Among other things, this bug causes panics when using netmap emulation
on top of generic drivers.

MFC r261150, r261151, r261164, r261166, r261167, r261168, r261394, r261395:

- Read and write the MAC address in the config space byte by byte
- Also include the mbuf's csum_flags in an assert message
- Remove stray space
- Move duplicated transmit start code into a single function
- Avoid queue unlock followed by relock when the enable interrupt race
is lost
- Check for a full virtqueue in the multiqueue transmit path
- Do not place the sglist used for Rx/Tx on the stack
- Use m_defrag() instead of m_collapse() to compact a long mbuf chain