1. 20 7月, 2019 2 次提交
  2. 13 7月, 2019 2 次提交
    • J
      nfp: flower: ensure ip protocol is specified for L4 matches · 103b7c25
      John Hurley 提交于
      Flower rules on the NFP firmware are able to match on an IP protocol
      field. When parsing rules in the driver, unknown IP protocols are only
      rejected when further matches are to be carried out on layer 4 fields, as
      the firmware will not be able to extract such fields from packets.
      
      L4 protocol dissectors such as FLOW_DISSECTOR_KEY_PORTS are only parsed if
      an IP protocol is specified. This leaves a loophole whereby a rule that
      attempts to match on transport layer information such as port numbers but
      does not explicitly give an IP protocol type can be incorrectly offloaded
      (in this case with wildcard port numbers matches).
      
      Fix this by rejecting the offload of flows that attempt to match on L4
      information, not only when matching on an unknown IP protocol type, but
      also when the protocol is wildcarded.
      
      Fixes: 2a047845 ("nfp: flower: check L4 matches on unknown IP protocols")
      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>
      103b7c25
    • J
      nfp: flower: fix ethernet check on match fields · fd262a6d
      John Hurley 提交于
      NFP firmware does not explicitly match on an ethernet type field. Rather,
      each rule has a bitmask of match fields that can be used to infer the
      ethernet type.
      
      Currently, if a flower rule contains an unknown ethernet type, a check is
      carried out for matches on other fields of the packet. If matches on
      layer 3 or 4 are found, then the offload is rejected as firmware will not
      be able to extract these fields from a packet with an ethernet type it
      does not currently understand.
      
      However, if a rule contains an unknown ethernet type without any L3 (or
      above) matches then this will effectively be offloaded as a rule with a
      wildcarded ethertype. This can lead to misclassifications on the firmware.
      
      Fix this issue by rejecting all flower rules that specify a match on an
      unknown ethernet type.
      
      Further ensure correct offloads by moving the 'L3 and above' check to any
      rule that does not specify an ethernet type and rejecting rules with
      further matches. This means that we can still offload rules with a
      wildcarded ethertype if they only match on L2 fields but will prevent
      rules which match on further fields that we cannot be sure if the firmware
      will be able to extract.
      
      Fixes: af9d842c ("nfp: extend flower add flow offload")
      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>
      fd262a6d
  3. 10 7月, 2019 5 次提交
  4. 28 6月, 2019 2 次提交
  5. 15 6月, 2019 3 次提交
  6. 08 5月, 2019 1 次提交
  7. 06 5月, 2019 1 次提交
  8. 17 4月, 2019 1 次提交
  9. 16 4月, 2019 6 次提交
  10. 23 3月, 2019 2 次提交
  11. 13 2月, 2019 1 次提交
  12. 07 2月, 2019 2 次提交
  13. 18 12月, 2018 1 次提交
    • J
      nfp: flower: fix cb_ident duplicate in indirect block register · b12c97d4
      John Hurley 提交于
      Previously the identifier used for indirect block callback registry and
      for block rule cb registry (when done via indirect blocks) was the pointer
      to the netdev we were interested in receiving updates on. This worked fine
      if a single app existed that registered one callback per netdev of
      interest. However, if multiple cards are in place and, in turn, multiple
      apps, then each app may register the same callback with the same
      identifier to both the netdev's indirect block cb list and to a block's cb
      list. This can lead to EEXIST errors and/or incorrect cb deletions.
      
      Prevent this conflict by using the app pointer as the identifier for
      netdev indirect block cb registry, allowing each app to register a unique
      callback per netdev. For block cb registry, the same app may register
      multiple cbs to the same block if using TC shared blocks. Instead of the
      app, use the pointer to the allocated cb_priv data as the identifier here.
      This means that there can be a unique block callback for each app/netdev
      combo.
      
      Fixes: 3166dd07 ("nfp: flower: offload tunnel decap rules via indirect TC blocks")
      Reported-by: NEdward Cree <ecree@solarflare.com>
      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>
      b12c97d4
  14. 11 12月, 2018 1 次提交
  15. 01 12月, 2018 2 次提交
  16. 12 11月, 2018 4 次提交
  17. 12 10月, 2018 1 次提交
  18. 11 10月, 2018 2 次提交
  19. 13 9月, 2018 1 次提交