History log of /freebsd/sys/net/iflib.c (Results 151 – 175 of 1916)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: vendor/unbound/1.8.1, vendor/subversion/subversion-1.10.2, vendor/apr-util/apr-util-1.6.1, vendor/apr/apr-1.6.5, vendor/serf/serf-1.3.9, vendor/acpica/20181003, vendor/acpica/20180927, vendor/libevent/2.1.18, vendor/libevent/2.1.8
# 0c919c23 20-Sep-2018 Stephen Hurd <shurd@FreeBSD.org>

Fix capabilities handling for iflib drivers

Various capabilities were not being handled correctly in the
SIOCSIFCAP handler. Specifically:

IFCAP_RXCSUM and IFCAP_RXCSUM_IPV6 could be set even if no

Fix capabilities handling for iflib drivers

Various capabilities were not being handled correctly in the
SIOCSIFCAP handler. Specifically:

IFCAP_RXCSUM and IFCAP_RXCSUM_IPV6 could be set even if not supported

It was impossible to disable IFCAP_RXCSUM and/or IFCAP_RXCSUM_IPV6 via
ifconfig since it does ioctl() per command-line flag rather than combine
them into a single call.

IFCAP_VLAN_HWCSUM could not be modified via the ioctl()

Setting any combination of the three IFCAP_WOL flags would set only
IFCAP_WOL_MCAST | IFCAP_WOL_MAGIC. For example, setting only
IFCAP_WOL_UCAST would result in both IFCAP_WOL_MCAST and IFCAP_WOL_MAGIC
being enabled, but IFCAP_WOL_UCAST would not be enabled.

Because if_vlancap() was called before if_togglecapenable(), vlan flags
were sometimes not applied correctly.

Interfaces were being unnecessarily stopped and restarted for WoL

PR: 231151
Submitted by: Kaho Toshikazu <kaho@elam.kais.kyoto-u.ac.jp>
Reported by: Shirkdog <mshirk@daemon-security.com>
Reviewed by: galladin
Approved by: re (gjb)
Sponsored by: Limelight Networks
Differential Revision: https://reviews.freebsd.org/D17158

show more ...


Revision tags: vendor/mandoc/1.14.4, vendor/lld/lld-release_700-r342383, vendor/clang/clang-release_700-r342383, vendor/openssl/1.1.1, vendor/lld/lld-release_70-r341916, vendor/libc++/libc++-release_70-r341916, vendor/libc++/libc++-release_70-r346007, vendor/libc++/libc++-release_70-r348011, vendor/libc++/libc++-release_700-r342383, vendor/compiler-rt/compiler-rt-release_70-r341916, vendor/compiler-rt/compiler-rt-release_70-r346007, vendor/compiler-rt/compiler-rt-release_70-r348011, vendor/compiler-rt/compiler-rt-release_70-r348686, vendor/compiler-rt/compiler-rt-release_700-r342383, vendor/compiler-rt/compiler-rt-release_701-r349250, vendor/clang/clang-release_70-r341916, vendor/llvm/llvm-release_70-r341916, vendor/llvm/llvm-release_700-r342383, vendor/unbound/1.8.0, vendor/unbound/1.7.3, vendor/unbound/1.7.2, zfs-0.8.0-rc1, vendor/libarchive/3.3.3
# 64e6fc13 06-Sep-2018 Stephen Hurd <shurd@FreeBSD.org>

Clean up iflib sysctls

Remove sysctls:
txq_drain_encapfail - now a duplicate of encap_txd_encap_fail
intr_link - was never incremented
intr_msix - was never incremented
rx_zero_len - was never incre

Clean up iflib sysctls

Remove sysctls:
txq_drain_encapfail - now a duplicate of encap_txd_encap_fail
intr_link - was never incremented
intr_msix - was never incremented
rx_zero_len - was never incremented

The following were not incremented in all code-paths that apply:
m_pullups, mbuf_defrag, rxd_flush, tx_encap, rx_intr_enables, tx_frees,
encap_txd_encap_fail.

Fixes:
Replace the broken collapse_pkthdr() implementation with an MPASS().
fl_refills and fl_refills_large were not incremented when using netmap.

Reviewed by: gallatin
Approved by: re (marius)
Sponsored by: Limelight Networks
Differential Revision: https://reviews.freebsd.org/D16733

show more ...


Revision tags: vendor/lld/lld-release_70-r340910, vendor/libc++/libc++-release_70-r340910, vendor/compiler-rt/compiler-rt-release_70-r340910, vendor/clang/clang-release_70-r340910, vendor/llvm/llvm-release_70-r340910
# bc0e855b 29-Aug-2018 Stephen Hurd <shurd@FreeBSD.org>

Fix compile error due to missing parenthesis in r338372

Approved by: re (gjb)


# a520f8b6 29-Aug-2018 Stephen Hurd <shurd@FreeBSD.org>

Fix potential data corruption in iflib

The MP ring may have txq pointers enqueued. Previously, these were
passed to m_free() when IFC_QFLUSH was set. This patch checks for
the value and doesn't ca

Fix potential data corruption in iflib

The MP ring may have txq pointers enqueued. Previously, these were
passed to m_free() when IFC_QFLUSH was set. This patch checks for
the value and doesn't call m_free().

Reviewed by: gallatin
Approved by: re (gjb)
Sponsored by: Limelight Networks
Differential Revision: https://reviews.freebsd.org/D16882

show more ...


Revision tags: vendor/openssh/7.8p1, vendor/ntp/4.2.8p12, vendor/lldb/lldb-release_70-r339999, vendor/lldb/lldb-release_70-r340910, vendor/lldb/lldb-release_70-r341916, vendor/lldb/lldb-release_70-r346007, vendor/lldb/lldb-release_700-r342383, vendor/lld/lld-release_70-r339999, vendor/libc++/libc++-release_70-r339999, vendor/clang/clang-release_70-r339999, vendor/llvm/llvm-release_70-r339999, vendor/openssl/1.0.2p, vendor/device-tree/4.18, vendor/tzdb/tzcode2018e, vendor/lldb/lldb-release_70-r339355, vendor/lld/lld-release_70-r339355, vendor/compiler-rt/compiler-rt-release_70-r339355, vendor/compiler-rt/compiler-rt-release_70-r339999, vendor/clang/clang-release_70-r339355, vendor/llvm/llvm-release_70-r339355, vendor/lua/5.3.5, vendor/acpica/20180810, vendor/ck/20180809, vendor/libc++/libc++-release_70-r338892, vendor/libc++/libc++-release_70-r339355, vendor/compiler-rt/compiler-rt-release_70-r338892, vendor/clang/clang-release_70-r338892, vendor/llvm/llvm-release_70-r338892
# 8f410865 04-Aug-2018 Patrick Kelsey <pkelsey@FreeBSD.org>

Mark the send queue ready so ALTQ is available.


Revision tags: vendor/lldb/lldb-release_70-r338892, vendor/lldb/lldb-trunk-r338536, vendor/lld/lld-release_70-r338892, vendor/lld/lld-trunk-r338536, vendor/libc++/libc++-trunk-r338536, vendor/compiler-rt/compiler-rt-trunk-r338536, vendor/clang/clang-trunk-r338536, vendor/llvm/llvm-trunk-r338536, vendor/file/5.34, vendor/lldb/lldb-trunk-r338150, vendor/lld/lld-trunk-r338150, vendor/libc++/libc++-trunk-r338150, vendor/compiler-rt/compiler-rt-trunk-r338150, vendor/clang/clang-trunk-r338150, vendor/llvm/llvm-trunk-r338150, vendor/bsnmp/1.13
# b8ca4756 25-Jul-2018 Patrick Kelsey <pkelsey@FreeBSD.org>

ALTQ support for iflib.

Reviewed by: jmallett, mmacy
Differential Revision: https://reviews.freebsd.org/D16433


# c9a49a4f 24-Jul-2018 Marius Strobl <marius@FreeBSD.org>

Since r336611, n is only used for INET in iflib_parse_header().
Reported by: rpokala


Revision tags: vendor/libfdt/1.4.7, vendor/ck/20180711
# 7474544b 22-Jul-2018 Marius Strobl <marius@FreeBSD.org>

Use the maximum of isc_tx_{nsegments,tso_segments_max} for MAX_TX_DESC.
Since r336313, TSO support for LEM-class devices is removed again as it
was before the conversion of {l,}em(4) to iflib(4) in r

Use the maximum of isc_tx_{nsegments,tso_segments_max} for MAX_TX_DESC.
Since r336313, TSO support for LEM-class devices is removed again as it
was before the conversion of {l,}em(4) to iflib(4) in r311849 and as a
result, isc_tx_tso_segments_max is 0 for LEM-class devices now. Thus,
inappropriate watermarks were used for this class.

This is really only a band-aid, though, because so far iflib(9) doesn't
fully take into account that DMA engines can support different maxima
of segments for transfers of TSO and non-TSO packets. For example, the
DESC_RECLAIMABLE macro is based on isc_tx_nsegments while MAX_TX_DESC
used isc_tx_tso_segments_max only. For most in-tree consumers that
doesn't make a difference as the maxima are the same for both kinds of
transfers (that is, apart from the fact that TSO may require up to 2
sentinel descriptors but also not with every MAC supported). However,
isc_tx_nsegments is 8 but isc_tx_tso_segments_max is 85 by default
with ixl(4).

show more ...


# 8b8d9093 22-Jul-2018 Marius Strobl <marius@FreeBSD.org>

- Given that the controlling expression of the receive loop in iflib_rxeof()
tests for avail > 0, avail can never be 0 within that loop. Thus, move
decrementing avail and budget_left into the loo

- Given that the controlling expression of the receive loop in iflib_rxeof()
tests for avail > 0, avail can never be 0 within that loop. Thus, move
decrementing avail and budget_left into the loop and before the code which
checks for additional descriptors having become available in case all the
previous ones have been processed but there still is budget left so the
latter code works as expected. [1]
- In iflib_{busdma_load_mbuf_sg,parse_header}(), remove dead stores to m
and n respectively. [2, 3]
- In collapse_pkthdr(), ensure that m_next isn't NULL before dereferencing
it. [4]
- Remove a duplicate assignment of segs in iflib_encap().

Reported by: Coverity
CID: 1356027 [1], 1356047 [2], 1368205 [3], 1356028 [4]

show more ...


# fe51d4cd 20-Jul-2018 Stephen Hurd <shurd@FreeBSD.org>

Add knob to control tx ring abdication.

r323954 changed the mp ring behaviour when 64-bit atomics were
available to abdicate the TX ring rather than having one become a
consumer thereby running to c

Add knob to control tx ring abdication.

r323954 changed the mp ring behaviour when 64-bit atomics were
available to abdicate the TX ring rather than having one become a
consumer thereby running to completion on TX. The consumer of the mp
ring was then triggered in the tx task rather than blocking the TX call.
While this significantly lowered the number of RX drops in small-packet
forwarding, it also negatively impacts TX performance.

With this change, the default behaviour is reverted, causing one TX ring
to become a consumer during the enqueue call. A new sysctl,
dev.X.Y.iflib.tx_abdicate is added to control this behaviour.

Reviewed by: gallatin
Sponsored by: Limelight Networks
Differential Revision: https://reviews.freebsd.org/D16302

show more ...


# dd7fbcf1 20-Jul-2018 Stephen Hurd <shurd@FreeBSD.org>

Improve netmap TX handling when TX IRQs are not used/supported

Use the timer to poll for TX completions when there are
outstanding TX slots. Track when the last driver timer was called
to prevent ov

Improve netmap TX handling when TX IRQs are not used/supported

Use the timer to poll for TX completions when there are
outstanding TX slots. Track when the last driver timer was called
to prevent overcalling it. Also clean up some kring vs NIC ring
usage.

Reviewed by: marius, Johannes Lundberg <johalun0@gmail.com>
Sponsored by: Limelight Networks
Differential Revision: https://reviews.freebsd.org/D16300

show more ...


# 7f87c040 15-Jul-2018 Marius Strobl <marius@FreeBSD.org>

Assorted TSO fixes for em(4)/iflib(9) and dead code removal:
- Ever since the workaround for the silicon bug of TSO4 causing MAC hangs
was committed in r295133, CSUM_TSO always got disabled uncondi

Assorted TSO fixes for em(4)/iflib(9) and dead code removal:
- Ever since the workaround for the silicon bug of TSO4 causing MAC hangs
was committed in r295133, CSUM_TSO always got disabled unconditionally
by em(4) on the first invocation of em_init_locked(). However, even with
that problem fixed, it turned out that for at least e. g. 82579 not all
necessary TSO workarounds are in place, still causing MAC hangs even at
Gigabit speed. Thus, for stable/11, TSO usage was deliberately disabled
in r323292 (r323293 for stable/10) for the EM-class by default, allowing
users to turn it on if it happens to work with their particular EM MAC
in a Gigabit-only environment.
In head, the TSO workaround for speeds other than Gigabit was lost with
the conversion to iflib(9) in r311849 (possibly along with another one
or two TSO workarounds). Yet at the same time, for EM-class MACs TSO4
got enabled by default again, causing device hangs. Therefore, change the
default for this hardware class back to have TSO4 off, allowing users
to turn it on manually if it happens to work in their environment as
we do in stable/{10,11}. An alternative would be to add a whitelist of
EM-class devices where TSO4 actually is reliable with the workarounds in
place, but given that the advantage of TSO at Gigabit speed is rather
limited - especially with the overhead of these workarounds -, that's
really not worth it. [1]
This change includes the addition of an isc_capabilities to struct
if_softc_ctx so iflib(9) can also handle interface capabilities that
shouldn't be enabled by default which is used to handle the default-off
capabilities of e1000 as suggested by shurd@ and moving their handling
from em_setup_interface() to em_if_attach_pre() accordingly.
- Although 82543 support TSO4 in theory, the former lem(4) didn't have
support for TSO4, presumably because TSO4 is even more broken in the
LEM-class of MACs than the later EM ones. Still, TSO4 for LEM-class
devices was enabled as part of the conversion to iflib(9) in r311849,
causing device hangs. So revert back to the pre-r311849 behavior of
not supporting TSO4 for LEM-class at all, which includes not creating
a TSO DMA tag in iflib(9) for devices not having IFCAP_TSO4 set. [2]
- In fact, the FreeBSD TCP stack can handle a TSO size of IP_MAXPACKET
(65535) rather than FREEBSD_TSO_SIZE_MAX (65518). However, the TSO
DMA must have a maxsize of the maximum TSO size plus the size of a
VLAN header for software VLAN tagging. The iflib(9) converted em(4),
thus, first correctly sets scctx->isc_tx_tso_size_max to EM_TSO_SIZE
in em_if_attach_pre(), but later on overrides it with IP_MAXPACKET
in em_setup_interface() (apparently, left-over from pre-iflib(9)
times). So remove the later and correct iflib(9) to correctly cap
the maximum TSO size reported to the stack at IP_MAXPACKET. While at
it, let iflib(9) use if_sethwtsomax*().
This change includes the addition of isc_tso_max{seg,}size DMA engine
constraints for the TSO DMA tag to struct if_shared_ctx and letting
iflib_txsd_alloc() automatically adjust the maxsize of that tag in case
IFCAP_VLAN_MTU is supported as requested by shurd@.
- Move the if_setifheaderlen(9) call for adjusting the maximum Ethernet
header length from {ixgbe,ixl,ixlv,ixv,em}_setup_interface() to iflib(9)
so adjustment is automatically done in case IFCAP_VLAN_MTU is supported.
As a consequence, this adjustment now is also done in case of bnxt(4)
which missed it previously.
- Move the reduction of the maximum TSO segment count reported to the
stack by the number of m_pullup(9) calls (which in the worst case,
can add another mbuf and, thus, the requirement for another DMA
segment each) in the transmit path for performance reasons from
em_setup_interface() to iflib_txsd_alloc() as these pull-ups are now
done in iflib_parse_header() rather than in the no longer existing
em_xmit(). Moreover, this optimization applies to all drivers using
iflib(9) and not just em(4); all in-tree iflib(9) consumers still
have enough room to handle full size TSO packets. Also, reduce the
adjustment to the maximum number of m_pullup(9)'s now performed in
iflib_parse_header().
- Prior to the conversion of em(4)/igb(4)/lem(4) and ixl(4) to iflib(9)
in r311849 and r335338 respectively, these drivers didn't enable
IFCAP_VLAN_HWFILTER by default due to VLAN events not being passed
through by lagg(4). With iflib(9), IFCAP_VLAN_HWFILTER was turned on
by default but also lagg(4) was fixed in that regard in r203548. So
just remove the now redundant and defunct IFCAP_VLAN_HWFILTER handling
in {em,ixl,ixlv}_setup_interface().
- Nuke other redundant IFCAP_* setting in {em,ixl,ixlv}_setup_interface()
which is (more completely) already done in {em,ixl,ixlv}_if_attach_pre()
now.
- Remove some redundant/dead setting of scctx->isc_tx_csum_flags in
em_if_attach_pre().
- Remove some IFCAP_* duplicated either directly or indirectly (e. g.
via IFCAP_HWCSUM) in {EM,IGB,IXL}_CAPS.
- Don't bother to fiddle with IFCAP_HWSTATS in ixgbe(4)/ixgbev(4) as
iflib(9) adds that capability unconditionally.
- Remove some unused macros from em(4).
- Bump __FreeBSD_version as some of the above changes require the modules
of drivers using iflib(9) to be recompiled.

Okayed by: sbruno@ at 201806 DevSummit Transport Working Group [1]
Reviewed by: sbruno (earlier version), erj
PR: 219428 (part of; comment #10) [1], 220997 (part of; comment #3) [2]
Differential Revision: https://reviews.freebsd.org/D15720

show more ...


Revision tags: vendor/acpica/20180629, vendor/lldb/lldb-release_601-r335540, vendor/lld/lld-release_601-r335540, vendor/libc++/libc++-release_601-r335540, vendor/compiler-rt/compiler-rt-release_601-r335540, vendor/clang/clang-release_601-r335540, vendor/llvm/llvm-release_601-r335540, release/11.2.0, upstream/11.2.0
# dfae03b5 18-Jun-2018 Eric Joyner <erj@FreeBSD.org>

iflib: Style fixes

MFC after: 1 week


# e4defe55 17-Jun-2018 Marius Strobl <marius@FreeBSD.org>

Assorted fixes to MSI-X/MSI/INTx setup in iflib(9):
- In iflib_msix_init(), VMMs with broken MSI-X activation are trying
to be worked around by manually enabling PCIM_MSIXCTRL_MSIX_ENABLE
before

Assorted fixes to MSI-X/MSI/INTx setup in iflib(9):
- In iflib_msix_init(), VMMs with broken MSI-X activation are trying
to be worked around by manually enabling PCIM_MSIXCTRL_MSIX_ENABLE
before calling pci_alloc_msix(9). Apart from constituting a layering
violation, this has the problem of leaving PCIM_MSIXCTRL_MSIX_ENABLE
enabled when falling back to MSI or INTx when e. g. MSI-X is black-
listed and initially also when disabled via hw.pci.enable_msix. The
later in turn was incorrectly worked around in r325166.
Since r310806, pci(4) itself has code to deal with broken MSI-X
handling of VMMs, so all of these workarounds in iflib(9) can go,
fixing non-working interrupts when falling back to MSI/INTx. In
any case, possibly further adjustments to broken MSI-X activation
of VMMs like enabling r310806 by default in VM environments need to
be placed into pci(4), not iflib(9). [1]
- Also remove the pci_enable_busmaster(9) call from iflib_msix_init(),
which is already more properly invoked from iflib_device_attach().
- When falling back to MSI/INTx, release the MSI-X BAR resource again.
- When falling back to INTx, ensure scctx->isc_vectors is set to 1 and
not to something higher from a device with more than one MSI message
supported.
- Make the nearby ring_state(s) stuff (static) const.

Discussed with: jhb at BSDCan 2018 [1]
Reviewed by: imp, jhb
Differential Revision: https://reviews.freebsd.org/D15729

show more ...


Revision tags: vendor/device-tree/4.17
# 3ab4a960 08-Jun-2018 Stephen Hurd <shurd@FreeBSD.org>

Remove tx task spinning added in r333686

This caused issues with PASTE. Just remove the reschedule since the DELAY()
should be enough for use cases such as pkt-gen which were failing before the
cha

Remove tx task spinning added in r333686

This caused issues with PASTE. Just remove the reschedule since the DELAY()
should be enough for use cases such as pkt-gen which were failing before the
change.

Reported by: Michio Honda
Sponsored by: Limelight Networks

show more ...


# a06424dd 07-Jun-2018 Eric Joyner <erj@FreeBSD.org>

iflib: Record TCP checksum info in iflib when TCP checksum is requested

ixl(4) (when it switches over to using iflib) devices need the TCP header
length in order to do TCP checksum offload.

Reviewe

iflib: Record TCP checksum info in iflib when TCP checksum is requested

ixl(4) (when it switches over to using iflib) devices need the TCP header
length in order to do TCP checksum offload.

Reviewed by: gallatin@, shurd@
MFC after: 1 week
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D15558

show more ...


Revision tags: vendor/acpica/20180531
# 3e0e6330 29-May-2018 Stephen Hurd <shurd@FreeBSD.org>

iflib: mark irq allocation name parameter as constant

The *name parameter passed to iflib_irq_alloc_generic and
iflib_softirq_alloc_generic is never modified. Many places in code pass
string literal

iflib: mark irq allocation name parameter as constant

The *name parameter passed to iflib_irq_alloc_generic and
iflib_softirq_alloc_generic is never modified. Many places in code pass
string literals and thus should not be modified.

Mark the *name parameter as a const char * instead, so that we enforce
that the name is not modified before passing to bus_describe_intr()

Submitted by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed by: kmacy
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D15343

show more ...


# 6c3c3194 29-May-2018 Matt Macy <mmacy@FreeBSD.org>

iflib: hold context lock across detach for drivers that need it


# 1d7ef186 26-May-2018 Eric Joyner <erj@FreeBSD.org>

iflib: Add new shared flag: IFLIB_ADMIN_ALWAYS_RUN

ixl(4)'s nvmupdate utility expects the nvmupdate process to run
while the interface is down; these nvm update commands use the
admin queue, so the

iflib: Add new shared flag: IFLIB_ADMIN_ALWAYS_RUN

ixl(4)'s nvmupdate utility expects the nvmupdate process to run
while the interface is down; these nvm update commands use the
admin queue, so the admin queue needs to be able to generate
interrupts and be processed while the interface is down.

So add a flag that ixl(4) sets that lets the entire admin task
run even when the interface is marked down/IFF_DRV_RUNNING isn't set.

With this change, nvmupdate should function like it did pre-iflib.

Reviewed by: gallatin@, sbruno@
MFC after: 1 week
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D15575

show more ...


Revision tags: vendor/ck/20180524, vendor/Juniper/libxo/0.9.0, vendor/file/5.33
# f6cb0dea 19-May-2018 Matt Macy <mmacy@FreeBSD.org>

net: fix uninitialized variable warning


# 46d0f824 19-May-2018 Matt Macy <mmacy@FreeBSD.org>

net: fix set but not used


Revision tags: vendor/NetBSD/bmake/20180512, vendor/xz/5.2.4, vendor/ck/20180517
# 2aa6f526 16-May-2018 Matt Macy <mmacy@FreeBSD.org>

Fix !netmap build post r333686

Approved by: sbruno


# 5ee36c68 16-May-2018 Stephen Hurd <shurd@FreeBSD.org>

Work around lack of TX IRQs in iflib for netmap

When poll() is called via netmap, txsync is initially called,
and if there are no available buffers to reclaim, it waits for the driver
to notify of n

Work around lack of TX IRQs in iflib for netmap

When poll() is called via netmap, txsync is initially called,
and if there are no available buffers to reclaim, it waits for the driver
to notify of new buffers. Since the TX IRQ is generally not used in iflib
drivers, this ends up causing a timeout.

Work around this by having the reclaim DELAY(1) if it's initially unable
to reclaim anything, then schedule the tx task, which will spin by
continuously rescheduling itself until some buffers are reclaimed. In
general, the delay is enough to allow some buffers to be reclaimed, so
spinning is minimized.

Reported by: Johannes Lundberg <johalun0@gmail.com>
Reviewed by: sbruno
Sponsored by: Limelight Networks
Differential Revision: https://reviews.freebsd.org/D15455

show more ...


Revision tags: vendor/unbound/1.7.1, vendor/unbound/1.7.0, vendor/unbound/1.6.8, vendor/unbound/1.6.7, vendor/unbound/1.6.6, vendor/unbound/1.6.5, vendor/unbound/1.6.4, vendor/unbound/1.6.3, vendor/unbound/1.6.2, vendor/unbound/1.6.1
# 09f6ff4f 11-May-2018 Matt Macy <mmacy@FreeBSD.org>

iflib(9): Add support for cloning pseudo interfaces

Part 3 of many ...
The VPC framework relies heavily on cloning pseudo interfaces
(vmnics, vpc switch, vcpswitch port, hostif, vxlan if, etc).

Thi

iflib(9): Add support for cloning pseudo interfaces

Part 3 of many ...
The VPC framework relies heavily on cloning pseudo interfaces
(vmnics, vpc switch, vcpswitch port, hostif, vxlan if, etc).

This pulls in that piece. Some ancillary changes get pulled
in as a side effect.

Reviewed by: shurd@
Approved by: sbruno@
Sponsored by: Joyent, Inc.
Differential Revision: https://reviews.freebsd.org/D15347

show more ...


Revision tags: vendor/ena-com/1.1.4.5, vendor/acpica/20180508
# ac88e6da 08-May-2018 Stephen Hurd <shurd@FreeBSD.org>

iflib: print message when iflib_tx_structures_setup fails

Print a message when iflib_tx_structures_setup fails, like we do for
iflib_rx_structures_setup.

Now that we always print a message from wit

iflib: print message when iflib_tx_structures_setup fails

Print a message when iflib_tx_structures_setup fails, like we do for
iflib_rx_structures_setup.

Now that we always print a message from within
iflib_qset_structures_setup when it fails, stop printing one in
iflib_device_register() at the call site.

Submitted by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed by: gallatin
MFC after: 3 days
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D15300

show more ...


12345678910>>...77