02 Jul, 2019

36 commits

  • Since this is not really a device with all capabilities, this test
    ensures that it has *enough* to make it through the data path
    without causing unwanted side-effects (read crash!).

    Signed-off-by: Mahesh Bandewar
    Signed-off-by: David S. Miller

    Mahesh Bandewar
     
  • Use blackhole_netdev instead of 'lo' device with lower MTU when marking
    dst "dead".

    Signed-off-by: Mahesh Bandewar
    Tested-by: Michael Chan
    Signed-off-by: David S. Miller

    Mahesh Bandewar
     
  • Create a blackhole net device that can be used for "dead"
    dst entries instead of loopback device. This blackhole device differs
    from loopback in few aspects: (a) It's not per-ns. (b) MTU on this
    device is ETH_MIN_MTU (c) The xmit function is essentially kfree_skb().
    and (d) since it's not registered it won't have ifindex.

    Lower MTU effectively make the device not pass the MTU check during
    the route check when a dst associated with the skb is dead.

    Signed-off-by: Mahesh Bandewar
    Signed-off-by: David S. Miller

    Mahesh Bandewar
     
  • Remove unneeded memset as alloc_etherdev is using kvzalloc which uses
    __GFP_ZERO flag

    Signed-off-by: Hariprasad Kelam
    Signed-off-by: David S. Miller

    Hariprasad Kelam
     
  • Ilias Apalodimas says:

    ====================
    net: netsec: Add XDP Support

    This is a respin of https://www.spinics.net/lists/netdev/msg526066.html
    Since page_pool API fixes are merged into net-next we can now safely use
    it's DMA mapping capabilities.

    First patch changes the buffer allocation from napi/netdev_alloc_frag()
    to page_pool API. Although this will lead to slightly reduced performance
    (on raw packet drops only) we can use the API for XDP buffer recycling.
    Another side effect is a slight increase in memory usage, due to using a
    single page per packet.

    The second patch adds XDP support on the driver.
    There's a bunch of interesting options that come up due to the single
    Tx queue.
    Locking is needed(to avoid messing up the Tx queues since ndo_xdp_xmit
    and the normal stack can co-exist). We also need to track down the
    'buffer type' for TX and properly free or recycle the packet depending
    on it's nature.

    Changes since RFC:
    - Bug fixes from Jesper and Maciej
    - Added page pool API to retrieve the DMA direction

    Changes since v1:
    - Use page_pool_free correctly if xdp_rxq_info_reg() failed
    ====================

    Signed-off-by: David S. Miller

    David S. Miller
     
  • The interface only supports 1 Tx queue so locking is introduced on
    the Tx queue if XDP is enabled to make sure .ndo_start_xmit and
    .ndo_xdp_xmit won't corrupt Tx ring

    - Performance (SMMU off)

    Benchmark XDP_SKB XDP_DRV
    xdp1 291kpps 344kpps
    rxdrop 282kpps 342kpps

    - Performance (SMMU on)
    Benchmark XDP_SKB XDP_DRV
    xdp1 167kpps 324kpps
    rxdrop 164kpps 323kpps

    Signed-off-by: Ilias Apalodimas
    Acked-by: Jesper Dangaard Brouer
    Signed-off-by: David S. Miller

    Ilias Apalodimas
     
  • Since the dma direction is stored in page pool params, offer an API
    helper for driver that choose not to keep track of it locally

    Signed-off-by: Ilias Apalodimas
    Acked-by: Jesper Dangaard Brouer
    Signed-off-by: David S. Miller

    Ilias Apalodimas
     
  • Use page_pool and it's DMA mapping capabilities for Rx buffers instead
    of netdev/napi_alloc_frag()

    Although this will result in a slight performance penalty on small sized
    packets (~10%) the use of the API will allow to easily add XDP support.
    The penalty won't be visible in network testing i.e ipef/netperf etc, it
    only happens during raw packet drops.
    Furthermore we intend to add recycling capabilities on the API
    in the future. Once the recycling is added the performance penalty will
    go away.
    The only 'real' penalty is the slightly increased memory usage, since we
    now allocate a page per packet instead of the amount of bytes we need +
    skb metadata (difference is roughly 2kb per packet).
    With a minimum of 4BG of RAM on the only SoC that has this NIC the
    extra memory usage is negligible (a bit more on 64K pages)

    Signed-off-by: Ilias Apalodimas
    Acked-by: Jesper Dangaard Brouer
    Signed-off-by: David S. Miller

    Ilias Apalodimas
     
  • Signed-off-by: Roman Mashak
    Signed-off-by: David S. Miller

    Roman Mashak
     
  • Roman Mashak says:

    ====================
    Fix batched event generation for mirred action

    When adding or deleting a batch of entries, the kernel sends upto
    TCA_ACT_MAX_PRIO entries in an event to user space. However it does not
    consider that the action sizes may vary and require different skb sizes.

    For example :

    % cat tc-batch.sh
    TC="sudo /mnt/iproute2.git/tc/tc"

    $TC actions flush action mirred
    for i in `seq 1 $1`;
    do
    cmd="action mirred egress redirect dev lo index $i "
    args=$args$cmd
    done
    $TC actions add $args
    %
    % ./tc-batch.sh 32
    Error: Failed to fill netlink attributes while adding TC action.
    We have an error talking to the kernel
    %

    patch 1 adds callback in tc_action_ops of mirred action, which calculates
    the action size, and passes size to tcf_add_notify()/tcf_del_notify().

    patch 2 updates the TDC test suite with relevant test cases.
    ====================

    Signed-off-by: David S. Miller

    David S. Miller
     
  • Signed-off-by: Roman Mashak
    Signed-off-by: David S. Miller

    Roman Mashak
     
  • Add get_fill_size() routine used to calculate the action size
    when building a batch of events.

    Signed-off-by: Roman Mashak
    Signed-off-by: David S. Miller

    Roman Mashak
     
  • People are inclined to stuff random things into cb->args[n] because it
    looks like an array of integers. Sometimes people even put u64s in there
    with comments noting that a certain member takes up two slots. The
    horror! Really this should mirror the usage of skb->cb, which are just
    48 opaque bytes suitable for casting a struct. Then people can create
    their usual casting macros for accessing strongly typed members of a
    struct.

    As a plus, this also gives us the same amount of space on 32bit and 64bit.

    Signed-off-by: Jason A. Donenfeld
    Reviewed-by: Johannes Berg
    Signed-off-by: David S. Miller

    Jason A. Donenfeld
     
  • The macro TIPC_BC_RETR_LIM is always used in combination with 'jiffies',
    so we can just as well perform the addition in the macro itself. This
    way, we get a few shorter code lines and one less line break.

    Signed-off-by: Jon Maloy
    Acked-by: Ying Xue
    Signed-off-by: David S. Miller

    Jon Maloy
     
  • /proc/sys/net/ipv6/flowlabel_reflect assumes written value to be in the
    range of 0 to 3. Use proc_dointvec_minmax instead of proc_dointvec.

    Fixes: 323a53c41292 ("ipv6: tcp: enable flowlabel reflection in some RST packets")
    Signed-off-by: Eiichi Tsukata
    Signed-off-by: David S. Miller

    Eiichi Tsukata
     
  • When user has configured a large number of virtual netdev, such
    as 4K vlans, the carrier on/off operation of the real netdev
    will also cause it's virtual netdev's link state to be processed
    in linkwatch. Currently, the processing is done in a work queue,
    which may cause rtnl locking starvation problem and worker
    starvation problem for other work queue, such as irqfd_inject wq.

    This patch releases the cpu when link watch worker has processed
    a fixed number of netdev' link watch event, and schedule the
    work queue again when there is still link watch event remaining.

    Signed-off-by: Yunsheng Lin
    Signed-off-by: David S. Miller

    Yunsheng Lin
     
  • Ido Schimmel says:

    ====================
    mlxsw: PTP timestamping support

    This is the second patchset adding PTP support in mlxsw. Next patchset
    will add PTP shapers which are required to maintain accuracy under rates
    lower than 40Gb/s, while subsequent patchsets will add tracepoints and
    selftests.

    Petr says:

    This patch set introduces support for retrieving and processing hardware
    timestamps for PTP packets.

    The way PTP timestamping works on Spectrum-1 is that there are two queues
    associated with each front panel port. When a packet is timestamped, the
    timestamp is put to one of the queues: timestamps for transmitted packets
    to one and for received packets to the other. Activity on these queues is
    signaled through the events PTP_ING_FIFO and PTP_EGR_FIFO.

    Packets themselves arrive through two traps: PTP0 and PTP1. It is possible
    to configure which PTP messages should be trapped under which PTP trap. On
    Spectrum systems, mlxsw will use PTP0 for event messages (which need
    timestamping), and PTP1 for general messages (which do not).

    There are therefore four relevant traps: receive of PTP event resp. general
    message, and receive of timestamp for a transmitted resp. received PTP
    packet. The obvious point where to put the new logic is a custom listener
    to the mentioned traps.

    Besides handling ingress traffic (be in packets or timestamps), the driver
    also needs to handle timestamping of transmitted packets. One option would
    be to invoke the relevant logic from mlxsw_core_ptp_transmitted(). However
    on Spectrum-2, the timestamps are actually delivered through the completion
    queue, and for that reason this patchset opts to invoke the logic from the
    PCI code, via core and the driver, to a chip-specific operation. That way
    the invocation will be done in a place where a Spectrum-2 implementation
    will have an opportunity to extract the timestamp.

    As indicated above, the PTP FIFO signaling happens independently from
    packet delivery. A packet corresponding to any given timestamp could be
    delivered sooner or later than the timestamp itself. Additionally, the
    queues are only four elements deep, and it is therefore possible that the
    timestamp for a delivered packet never arrives at all. Similarly a PTP
    packet might be dropped due to CPU traffic pressure, and never be delivered
    even if the corresponding timestamp was.

    The driver thus needs to hold a cache of as-yet-unmatched SKBs and
    timestamps. The first piece to arrive (be it timestamp or SKB) is put to
    this cache. When the other piece arrives, the timestamp is attached to the
    SKB and that is passed on. A delayed work is run at regular intervals to
    prune the old unmatched entries.

    As mentioned above, the mechanism for timestamp delivery changes on
    Spectrum-2, where timestamps are part of completion queue elements, and all
    packets are timestamped. All this bookkeeping is therefore unnecessary on
    Spectrum-2. For this reason, this patchset spends some time introducing
    Spectrum-1 specific artifacts such as a possibility to register a given
    trap only on Spectrum-1.

    Patches #1-#4 describe new registers.

    Patches #5 and #6 introduce the possibility to register certain traps
    only on some systems. The list of Spectrum-1 specific traps is left empty
    at this point.

    Patch #7 hooks into packet receive path by registering PTP traps
    and appropriate handlers (that however do nothing of substance yet).

    Patch #8 adds a helper to allow storing custom data to SKB->cb.

    Patch #9 adds a call into the PCI completion queue handler that invokes,
    via core and spectrum code, a PTP transmit handler. (Which also does not do
    anything interesting yet.)

    Patch #10 introduces code to invoke PTP initialization and adds data types
    for the cache of unmatched entries.

    Patches #11 and #12 implement the timestamping itself. In #11, the PHC
    spin_locks are converted to _bh variants, because unlike normal PHC path,
    which runs in process context, timestamp processing runs as soft interrupt.
    Then #12 introduces the code for saving and retrieval of unmatched entries,
    invokes PTP classifier to identify packets of interest, registers timestamp
    FIFO events, and handles decoding and attaching timestamps to packets.

    Patch #13 introduces a garbage collector for left-behind entries that have
    not been matched for about a second.

    In patch #14, PTP message types are configured to arrive as PTP0
    (events) or PTP1 (everything else) as appropriate. At this point, the PTP
    packets start arriving through the traps, but because PTP is disabled and
    there is no way to enable it yet, they are always just passed to the usual
    receive path right away.

    Finally patches #15 and #16 add the plumbing to actually make it possible
    to enable this code through SIOCSHWTSTAMP ioctl, and to advertise the
    hardware timestamping capabilities through ethtool.

    v2:
    - Patch #12:
    - In mlxsw_sp1_ptp_fifo_event_func(), post-increment when iterating over PTP
    FIFO records.
    - Patch #14:
    - Change namespace of message type enumerators from MLXSW_ to MLXSW_SP_.
    ====================

    Signed-off-by: David S. Miller

    David S. Miller
     
  • The get_ts_info callback is used for obtaining information about
    timestamping capabilities of a network device. On Spectrum-1, implement
    it to advertise the PHC and the capability to do HW timestamping, and
    the supported RX and TX filters.

    Signed-off-by: Petr Machata
    Acked-by: Jiri Pirko
    Signed-off-by: Ido Schimmel
    Signed-off-by: David S. Miller

    Petr Machata
     
  • The SIOCSHWTSTAMP ioctl configures HW timestamping on a given port.
    Dispatch the ioctls to per-chip handler (which add to ptp_ops). Find
    which PTP messages need to be timestamped and configure MTPPPC
    accordingly.

    The SIOCGHWTSTAMP ioctl is getter for the current configuration.

    Signed-off-by: Petr Machata
    Acked-by: Jiri Pirko
    Signed-off-by: Ido Schimmel
    Signed-off-by: David S. Miller

    Petr Machata
     
  • Configure MTPTPT to set which message types should arrive under which
    PTP trap, and MOGCR to clear the timestamp queue after its contents are
    reported through PTP_ING_FIFO or PTP_EGR_FIFO.

    With this configuration, PTP packets start arriving through the PTP
    traps. However since timestamping is disabled by default and there is
    currently no way to enable it, they will not be timestamped.

    Signed-off-by: Petr Machata
    Acked-by: Jiri Pirko
    Signed-off-by: Ido Schimmel
    Signed-off-by: David S. Miller

    Petr Machata
     
  • On Spectrum-1, timestamped PTP packets and the corresponding timestamps
    need to be kept in caches until both are available, at which point they are
    matched up and packets forwarded as appropriate. However, not all packets
    will ever see their timestamp, and not all timestamps will ever see their
    packet. It is therefore necessary to dispose of such abandoned entries.

    To that end, introduce a garbage collector to collect entries that have
    not had their counterpart turn up within about a second. The GC
    maintains a monotonously-increasing value of GC cycle. Every entry that
    is put to the hash table is annotated with the GC cycle at which it
    should be collected. When the GC runs, it walks the hash table, and
    collects the objects according to their GC cycle annotation.

    Signed-off-by: Petr Machata
    Acked-by: Jiri Pirko
    Signed-off-by: Ido Schimmel
    Signed-off-by: David S. Miller

    Petr Machata
     
  • On Spectrum-1, timestamps arrive through a pair of dedicated events:
    MLXSW_TRAP_ID_PTP_ING_FIFO and _EGR_FIFO. The payload delivered with
    those traps is contents of the timestamp FIFO at a given port in a given
    direction. Add a Spectrum-1-specific handler for these two events which
    decodes the timestamps and forwards them to the PTP module.

    Add a function that parses a packet, dispatching to ptp_classify_raw(),
    and decodes PTP message type, domain number, and sequence ID. Add a new
    mlxsw dependency on the PTP classifier.

    Add helpers that can store and retrieve unmatched timestamps and SKBs to
    the hash table added in a preceding patch.

    Add the matching code itself: upon arrival of a timestamp or a packet,
    look up the corresponding unmatched entry, and match it up. If there is
    none, add a new unmatched entry. This logic is the same on ingress as on
    egress.

    Packets and timestamps that never matched need to be eventually disposed
    of. A garbage collector added in a follow-up patch will take care of
    that. Since currently all this code is turned off, no crud will
    accumulate in the hash table.

    Signed-off-by: Petr Machata
    Acked-by: Jiri Pirko
    Signed-off-by: Ido Schimmel
    Signed-off-by: David S. Miller

    Petr Machata
     
  • Up until now, the PTP hardware clock code was only invoked in the process
    context (SYS_clock_adjtime -> do_clock_adjtime -> k_clock::clock_adj ->
    pc_clock_adjtime -> posix_clock_operations::clock_adjtime ->
    ptp_clock_info::adjtime -> mlxsw_spectrum).

    In order to enable HW timestamping, which is tied into trap handling, it
    will be necessary to take the clock lock from the PCI queue handler
    tasklets as well.

    Therefore use the _bh variants when handling the clock lock. Incidentally,
    Documentation/ptp/ptp.txt recommends _irqsave variants, but that's
    unnecessarily strong for our needs.

    Signed-off-by: Petr Machata
    Acked-by: Jiri Pirko
    Signed-off-by: Ido Schimmel
    Signed-off-by: David S. Miller

    Petr Machata
     
  • Add two ptp_ops: init and fini, to initialize and finalize the PTP
    subsystem. Call as appropriate from mlxsw_sp_init() and _fini().

    Lay the groundwork for Spectrum-1 support. On Spectrum-1, the received
    timestamped packets and their corresponding timestamps arrive
    independently, and need to be matched up. Introduce the related data types
    and add to struct mlxsw_sp_ptp_state the hash table that will keep the
    unmatched entries.

    Signed-off-by: Petr Machata
    Acked-by: Jiri Pirko
    Signed-off-by: Ido Schimmel
    Signed-off-by: David S. Miller

    Petr Machata
     
  • On Spectrum-1, timestamps are delivered separately from the packets, and
    need to paired up. Therefore, at some point after mlxsw_sp_port_xmit()
    is invoked, it is necessary to involve the chip-specific driver code to
    allow it to do the necessary bookkeeping and matching.

    On Spectrum-2, timestamps are delivered in CQE. For that reason,
    position the point of driver involvement into mlxsw_pci_cqe_sdq_handle()
    to make it hopefully easier to extend for Spectrum-2 in the future.

    To tell the driver what port the packet was sent on, keep tx_info
    in SKB control buffer.

    Introduce a new driver core interface mlxsw_core_ptp_transmitted(), a
    driver callback ptp_transmitted, and a PTP op transmitted. The callee is
    responsible for taking care of releasing the SKB passed to the new
    interfaces, and correspondingly have the new stub callbacks just call
    dev_kfree_skb_any().

    Follow-up patches will introduce the actual content into
    mlxsw_sp1_ptp_transmitted() in particular.

    Signed-off-by: Petr Machata
    Acked-by: Jiri Pirko
    Signed-off-by: Ido Schimmel
    Signed-off-by: David S. Miller

    Petr Machata
     
  • The SKB control buffer is useful (and used) for bookkeeping of information
    related to that SKB. Add helpers so that the mlxsw driver(s) can safely use
    the buffer as well. The structure is currently empty, individual users will
    add members to it as necessary.

    Note that SKB allocation functions already clear the buffer, so the cleanup
    is only necessary when ndo_start_xmit is called.

    Signed-off-by: Petr Machata
    Acked-by: Jiri Pirko
    Signed-off-by: Ido Schimmel
    Signed-off-by: David S. Miller

    Petr Machata
     
  • When configured, the Spectrum hardware can recognize PTP packets and
    trap them to the CPU using dedicated traps, PTP0 and PTP1.

    One reason to get PTP packets under dedicated traps is to have a
    separate policer suitable for the amount of PTP traffic expected when
    switch is operated as a boundary clock. For this, add two new trap
    groups, MLXSW_REG_HTGT_TRAP_GROUP_SP_PTP0 and _PTP1, and associate the
    two PTP traps with these two groups.

    In the driver, specifically for Spectrum-1, event PTP packets will need
    to be paired up with their timestamps. Those arrive through a different
    set of traps, added later in the patch set. To support this future use,
    introduce a new PTP op, ptp_receive.

    It is possible to configure which PTP messages should be trapped under
    which PTP trap. On Spectrum systems, we will use PTP0 for event
    packets (which need timestamping), and PTP1 for control packets (which
    do not). Thus configure PTP0 trap with a custom callback that defers to
    the ptp_receive op.

    Additionally, L2 PTP packets are actually trapped through the LLDP trap,
    not through any of the PTP traps. So treat the LLDP trap the same way as
    the PTP0 trap. Unlike PTP traps, which are currently still disabled,
    LLDP trap is active. Correspondingly, have all the implementations of
    the ptp_receive op return true, which the handler treats as a signal to
    forward the packet immediately.

    Signed-off-by: Petr Machata
    Acked-by: Jiri Pirko
    Signed-off-by: Ido Schimmel
    Signed-off-by: David S. Miller

    Petr Machata
     
  • On Spectrum-1, timestamps for PTP packets are delivered through queues
    of ingress and egress timestamps. There are two event traps
    corresponding to activity on each of those queues. This mechanism is
    absent on Spectrum-2, and therefore the traps should only be registered
    on Spectrum-1.

    Carry a chip-specific listener array in mlxsw_sp->listeners and
    listeners_count. Register listeners from that array in
    mlxsw_sp_traps_init(). Add a new listener array for Spectrum-1 traps and
    configure the newly-added mlxsw_sp->listeners with this array.

    The listener array is empty for now, the events will be added in a later
    patch.

    Signed-off-by: Petr Machata
    Acked-by: Jiri Pirko
    Signed-off-by: Ido Schimmel
    Signed-off-by: David S. Miller

    Petr Machata
     
  • On Spectrum-1, timestamps for PTP packets are delivered through queues
    of ingress and egress timestamps. There are two event traps
    corresponding to activity on each of those queues. This mechanism is
    absent on Spectrum-2, and therefore the traps should only be registered
    on Spectrum-1.

    Extract out of mlxsw_sp_traps_init() a generic helper,
    mlxsw_sp_traps_register(), and likewise with _unregister(). The new helpers
    will later be called with Spectrum-1-specific traps.

    Signed-off-by: Petr Machata
    Acked-by: Jiri Pirko
    Signed-off-by: Ido Schimmel
    Signed-off-by: David S. Miller

    Petr Machata
     
  • This register serves to configure global parameters of certain
    monitoring operations. The following patches will use it to configure
    that when PTP timestamps are delivered through the PTP FIFO traps, the
    FIFO in question is cleared as well.

    Signed-off-by: Petr Machata
    Acked-by: Jiri Pirko
    Signed-off-by: Ido Schimmel
    Signed-off-by: David S. Miller

    Petr Machata
     
  • The MTPPTR is used for reading the per port PTP timestamp FIFO.

    Signed-off-by: Petr Machata
    Acked-by: Jiri Pirko
    Signed-off-by: Ido Schimmel
    Signed-off-by: David S. Miller

    Petr Machata
     
  • This register is used for configuring under which trap to deliver PTP
    packets depending on type of the packet.

    Signed-off-by: Petr Machata
    Acked-by: Jiri Pirko
    Signed-off-by: Ido Schimmel
    Signed-off-by: David S. Miller

    Petr Machata
     
  • This register serves for configuration of which PTP messages should be
    timestamped. This is a global configuration, despite the register name.

    Signed-off-by: Petr Machata
    Acked-by: Jiri Pirko
    Signed-off-by: Ido Schimmel
    Signed-off-by: David S. Miller

    Petr Machata
     
  • Currently, kernel pktgen has the feature to specify udp destination port
    for sending packet. (e.g. pgset "udp_dst_min 9")

    But on samples, each of the scripts doesn't have any option to achieve this.

    This commit adds the DST_PORT option to specify the target port(s) in the script.

    -p : ($DST_PORT) destination PORT range (e.g. 433-444) is also allowed

    Signed-off-by: Daniel T. Lee
    Acked-by: Jesper Dangaard Brouer
    Signed-off-by: David S. Miller

    Daniel T. Lee
     
  • This commit adds port parsing and port validate helper function to parse
    single or range of port(s) from a given string. (e.g. 1234, 443-444)

    Helpers will be used in prior to set target port(s) in samples/pktgen.

    Signed-off-by: Daniel T. Lee
    Acked-by: Jesper Dangaard Brouer
    Signed-off-by: David S. Miller

    Daniel T. Lee
     
  • Extend flowlabel_reflect bitmask to allow conditional
    reflection of incoming flowlabels in echo replies.

    Note this has precedence against auto flowlabels.

    Add flowlabel_reflect enum to replace hard coded
    values.

    Signed-off-by: Eric Dumazet
    Signed-off-by: David S. Miller

    Eric Dumazet
     

01 Jul, 2019

2 commits

  • Saeed Mahameed says:

    ====================
    mlx5e-updates-2019-06-28

    This series adds some misc updates for mlx5e driver

    1) Allow adding the same mac more than once in MPFS table
    2) Move to HW checksumming advertising
    3) Report netdevice MPLS features
    4) Correct physical port name of the PF representor
    5) Reduce stack usage in mlx5_eswitch_termtbl_create
    6) Refresh TIR improvement for representors
    7) Expose same physical switch_id for all representors
    ====================

    Signed-off-by: David S. Miller

    David S. Miller
     
  • Jeff Kirsher says:

    ====================
    Intel Wired LAN Driver Updates 2019-06-28

    This series contains a smorgasbord of updates to many of the Intel
    drivers.

    Gustavo A. R. Silva updates the ice and iavf drivers to use the
    strcut_size() helper where possible.

    Miguel increases the pause and refresh time for flow control in the
    e1000e driver during reset for certain devices.

    Dann Frazier fixes a potential NULL pointer dereference in ixgbe driver
    when using non-IPSec enabled devices.

    Colin Ian King fixes a potential overflow during a shift in the ixgbe
    driver. Also fixes a potential NULL pointer dereference in the iavf
    driver by adding a check.

    Venkatesh Srinivas converts the e1000 driver to use dma_wmb() instead of
    wmb() for doorbell writes to avoid SFENCEs in the transmit and receive
    paths.

    Arjan updates the e1000e driver to improve boot time by over 100 msec by
    reducing the usleep ranges suring system startup.

    Artem updates the igb driver register dump in ethtool, first prepares
    the register dump for future additions of registers in the dump, then
    secondly, adds the RR2DCDELAY register to the dump. When dealing with
    time-sensitive networks, this register is helpful in determining your
    latency from the device to the ring.

    Alex fixes the ixgbevf driver to use the current cached link state,
    rather than trying to re-check the value from the PF.

    Harshitha adds support for MACVLAN offloads in i40e by using channels as
    MACVLAN interfaces.

    Detlev Casanova updates the e1000e driver to use delayed work instead of
    timers to run the watchdog.

    Vitaly fixes an issue in e1000e, where when disconnecting and
    reconnecting the physical cable connection, the NIC enters a DMoff
    state. This state causes a mismatch in link and duplexing, so check the
    PCIm function state and perform a PHY reset when in this state to
    resolve the issue.
    ====================

    Signed-off-by: David S. Miller

    David S. Miller
     

30 Jun, 2019

2 commits

  • DMA_API_HOWTO.txt includes an example explaining when
    dma_sync_single_for_device() is not needed, and that example matches
    our use case. The buffer isn't changed by the CPU and direction is
    DMA_FROM_DEVICE, so we can remove the call to
    dma_sync_single_for_device().

    Signed-off-by: Heiner Kallweit
    Signed-off-by: David S. Miller

    Heiner Kallweit
     
  • Documentation/DMA-API-HOWTO.txt states:
    By default, the kernel assumes that your device can address 32-bits of
    DMA addressing. For a 64-bit capable device, this needs to be increased,
    and for a device with limitations, it needs to be decreased.

    Therefore we don't need the 32 Bit DMA fallback configuration and can
    remove it.

    Signed-off-by: Heiner Kallweit
    Signed-off-by: David S. Miller

    Heiner Kallweit