1. 13 Sep, 2019 31 commits
  2. 12 Sep, 2019 5 commits
  3. 11 Sep, 2019 4 commits
    • Dirk van der Merwe's avatar
      nfp: read chip model from the PluDevice register · 421bceb2
      Dirk van der Merwe authored
      The PluDevice register provides the authoritative chip model/revision.
      
      Since the model number is purely used for reporting purposes, follow
      the hardware team convention of subtracting 0x10 from the PluDevice
      register to obtain the chip model/revision number.
      Suggested-by: default avatarFrancois H. Theron <francois.theron@netronome.com>
      Signed-off-by: default avatarDirk van der Merwe <dirk.vandermerwe@netronome.com>
      Signed-off-by: default avatarSimon Horman <simon.horman@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      421bceb2
    • Eric Dumazet's avatar
      tcp: force a PSH flag on TSO packets · 051ba674
      Eric Dumazet authored
      When tcp sends a TSO packet, adding a PSH flag on it
      reduces the sojourn time of GRO packet in GRO receivers.
      
      This is particularly the case under pressure, since RX queues
      receive packets for many concurrent flows.
      
      A sender can give a hint to GRO engines when it is
      appropriate to flush a super-packet, especially when pacing
      is in the picture, since next packet is probably delayed by
      one ms.
      
      Having less packets in GRO engine reduces chance
      of LRU eviction or inflated RTT, and reduces GRO cost.
      
      We found recently that we must not set the PSH flag on
      individual full-size MSS segments [1] :
      
       Under pressure (CWR state), we better let the packet sit
       for a small delay (depending on NAPI logic) so that the
       ACK packet is delayed, and thus next packet we send is
       also delayed a bit. Eventually the bottleneck queue can
       be drained. DCTCP flows with CWND=1 have demonstrated
       the issue.
      
      This patch allows to slowdown the aggregate traffic without
      involving high resolution timers on senders and/or
      receivers.
      
      It has been used at Google for about four years,
      and has been discussed at various networking conferences.
      
      [1] segments smaller than MSS already have PSH flag set
          by tcp_sendmsg() / tcp_mark_push(), unless MSG_MORE
          has been requested by the user.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Soheil Hassas Yeganeh <soheil@google.com>
      Cc: Neal Cardwell <ncardwell@google.com>
      Cc: Yuchung Cheng <ycheng@google.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Tariq Toukan <tariqt@mellanox.com>
      Acked-by: default avatarSoheil Hassas Yeganeh <soheil@google.com>
      Acked-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      051ba674
    • Stefano Brivio's avatar
      ipv6: Don't use dst gateway directly in ip6_confirm_neigh() · cbfd6891
      Stefano Brivio authored
      This is the equivalent of commit 2c6b55f4 ("ipv6: fix neighbour
      resolution with raw socket") for ip6_confirm_neigh(): we can send a
      packet with MSG_CONFIRM on a raw socket for a connected route, so the
      gateway would be :: here, and we should pick the next hop using
      rt6_nexthop() instead.
      
      This was found by code review and, to the best of my knowledge, doesn't
      actually fix a practical issue: the destination address from the packet
      is not considered while confirming a neighbour, as ip6_confirm_neigh()
      calls choose_neigh_daddr() without passing the packet, so there are no
      similar issues as the one fixed by said commit.
      
      A possible source of issues with the existing implementation might come
      from the fact that, if we have a cached dst, we won't consider it,
      while rt6_nexthop() takes care of that. I might just not be creative
      enough to find a practical problem here: the only way to affect this
      with cached routes is to have one coming from an ICMPv6 redirect, but
      if the next hop is a directly connected host, there should be no
      topology for which a redirect applies here, and tests with redirected
      routes show no differences for MSG_CONFIRM (and MSG_PROBE) packets on
      raw sockets destined to a directly connected host.
      
      However, directly using the dst gateway here is not consistent anymore
      with neighbour resolution, and, in general, as we want the next hop,
      using rt6_nexthop() looks like the only sane way to fetch it.
      Reported-by: default avatarGuillaume Nault <gnault@redhat.com>
      Signed-off-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Acked-by: default avatarGuillaume Nault <gnault@redhat.com>
      Acked-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cbfd6891
    • Jose Abreu's avatar
      net: stmmac: pci: Add HAPS support using GMAC5 · ebecb860
      Jose Abreu authored
      Add the support for Synopsys HAPS board that uses GMAC5.
      Signed-off-by: default avatarJose Abreu <joabreu@synopsys.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ebecb860