1. Dec 18, 2018
  2. Dec 17, 2018
  3. Dec 16, 2018
    • Sam Protsenko's avatar
      l2tp: Add protocol field decompression · c151acc6
      Sam Protsenko authored
      
      
      When Protocol Field Compression (PFC) is enabled, the "Protocol" field
      in PPP packet will be received without leading 0x00. See section 6.5 in
      RFC 1661 for details. So let's decompress protocol field if needed, the
      same way it's done in drivers/net/ppp/pptp.c.
      
      In case when "nopcomp" pppd option is not enabled, PFC (pcomp) can be
      negotiated during LCP handshake, and L2TP driver in kernel will receive
      PPP packets with compressed Protocol field, which in turn leads to next
      error:
      
          Protocol Rejected (unsupported protocol 0x2145)
      
      because instead of Protocol=0x0021 in PPP packet there will be
      Protocol=0x21. This patch unwraps it back to 0x0021, which fixes the
      issue.
      
      Sending the compressed Protocol field will be implemented in subsequent
      patch, this one is self-sufficient.
      
      Signed-off-by: default avatarSam Protsenko <semen.protsenko@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c151acc6
    • David S. Miller's avatar
      Merge tag 'mlx5e-updates-2018-12-14' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux · 63de273f
      David S. Miller authored
      
      
      Saeed Mahameed says:
      
      ====================
      mlx5e-updates-2018-12-14 (VF Lag)
      
      From Aviv Heller,
      
      Subsequent patches introduce VF LAG, which provdies load-balancing and
      high-availability capabilities for VFs associated with different
      physical ports of the same Connect-X card.
      
      This series consists of the following:
       - mlx5 devcom, driver infrastructure that facilitates operations that involve
         both core devices (physical functions) of the same card, to synchronize and
         communicate between two driver instances of the same card.
       - Infrastructure for TC rule duplication.
       - Changes to LAG logic to enable its use when SR-IOV is enabled
       - PFs in switchdev mode is the only mode currently supported.
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      63de273f
    • David S. Miller's avatar
      Merge branch 'net-mitigate-retpoline-overhead' · bedf3b33
      David S. Miller authored
      Paolo Abeni says:
      
      ====================
      net: mitigate retpoline overhead
      
      The spectre v2 counter-measures, aka retpolines, are a source of measurable
      overhead[1]. We can partially address that when the function pointer refers to
      a builtin symbol resorting to a list of tests vs well-known builtin function and
      direct calls.
      
      Experimental results show that replacing a single indirect call via
      retpoline with several branches and a direct call gives performance gains
      even when multiple branches are added - 5 or more, as reported in [2].
      
      This may lead to some uglification around the indirect calls. In netconf 2018
      Eric Dumazet described a technique to hide the most relevant part of the needed
      boilerplate with some macro help.
      
      This series is a [re-]implementation of such idea, exposing the introduced
      helpers in a new header file. They are later leveraged to avoid the indirect
      call overhead in the GRO path, when possible.
      
      Overall this gives > 10% performance improvement for UDP GRO benchmark and
      smaller but measurable for TCP syn flood.
      
      The added infra can be used in follow-up patches to cope with retpoline overhead
      in other points of the networking stack (e.g. at the qdisc layer) and possibly
      even in other subsystems.
      
      v2  -> v3:
       - fix build error with CONFIG_IPV6=m
      
      v1  -> v2:
       - list explicitly the builtin function names in INDIRECT_CALL_*(),
         as suggested by Ed Cree
       - expand the recipients list
      
      rfc -> v1:
       - use branch prediction hints, as suggested by Eric
      
      [1] http://vger.kernel.org/netconf2018_files/PaoloAbeni_netconf2018.pdf
      [2] https://linuxplumbersconf.org/event/2/contributions/99/attachments/98/117/lpc18_paper_af_xdp_perf-v2.pdf
      
      
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bedf3b33