1. 11 10月, 2018 3 次提交
  2. 13 9月, 2018 1 次提交
  3. 08 8月, 2018 1 次提交
  4. 13 7月, 2018 1 次提交
  5. 25 5月, 2018 5 次提交
  6. 26 4月, 2018 2 次提交
  7. 13 4月, 2018 1 次提交
  8. 30 3月, 2018 1 次提交
    • J
      nfp: flower: offload phys port MTU change · 29a5dcae
      John Hurley 提交于
      Trigger a port mod message to request an MTU change on the NIC when any
      physical port representor is assigned a new MTU value. The driver waits
      10 msec for an ack that the FW has set the MTU. If no ack is received the
      request is rejected and an appropriate warning flagged.
      
      Rather than maintain an MTU queue per repr, one is maintained per app.
      Because the MTU ndo is protected by the rtnl lock, there can never be
      contention here. Portmod messages from the NIC are also protected by
      rtnl so we first check if the portmod is an ack and, if so, handle outside
      rtnl and the cmsg work queue.
      
      Acks are detected by the marking of a bit in a portmod response. They are
      then verfied by checking the port number and MTU value expected by the
      app. If the expected MTU is 0 then no acks are currently expected.
      
      Also, ensure that the packet headroom reserved by the flower firmware is
      considered when accepting an MTU change on any repr.
      Signed-off-by: NJohn Hurley <john.hurley@netronome.com>
      Reviewed-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      29a5dcae
  9. 17 2月, 2018 1 次提交
  10. 04 1月, 2018 1 次提交
  11. 20 12月, 2017 2 次提交
  12. 17 11月, 2017 2 次提交
  13. 02 11月, 2017 1 次提交
  14. 27 9月, 2017 5 次提交
  15. 04 9月, 2017 1 次提交
  16. 17 8月, 2017 1 次提交
  17. 08 8月, 2017 3 次提交
  18. 01 7月, 2017 6 次提交
  19. 11 2月, 2017 2 次提交