1. 09 Aug, 2019 1 commit
  2. 06 Aug, 2019 3 commits
    • John Hurley's avatar
      nfp: flower: verify pre-tunnel rules · 120ffd84
      John Hurley authored
      
      
      Pre-tunnel rules must direct packets to an internal port based on L2
      information. Rules that egress to an internal port are already indicated
      by a non-NULL device in its nfp_fl_payload struct. Verfiy the rest of the
      match fields indicate that the rule is a pre-tunnel rule. This requires a
      full match on the destination MAC address, an option VLAN field, and no
      specific matches on other lower layer fields (with the exception of L4
      proto and flags).
      
      If a rule is identified as a pre-tunnel rule then mark it for offload to
      the pre-tunnel table. Similarly, remove it from the pre-tunnel table on
      rule deletion. The actual offloading of these commands is left to a
      following patch.
      Signed-off-by: default avatarJohn Hurley <john.hurley@netronome.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@netronome.com>
      Acked-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      120ffd84
    • John Hurley's avatar
      nfp: flower: detect potential pre-tunnel rules · f5c977ee
      John Hurley authored
      
      
      Pre-tunnel rules are used when the tunnel end-point is on an 'internal
      port'. These rules are used to direct the tunnelled packets (based on outer
      header fields) to the internal port where they can be detunnelled. The
      rule must send the packet to ingress the internal port at the TC layer.
      
      Currently FW does not support an action to send to ingress so cannot
      offload such rules. However, in preparation for populating the pre-tunnel
      table to represent such rules, check for rules that send to the ingress of
      an internal port and mark them as such. Further validation of such rules
      is left to subsequent patches.
      Signed-off-by: default avatarJohn Hurley <john.hurley@netronome.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@netronome.com>
      Acked-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f5c977ee
    • John Hurley's avatar
      nfp: flower: push vlan after tunnel in merge · 4b10c53d
      John Hurley authored
      
      
      NFP allows the merging of 2 flows together into a single offloaded flow.
      In the kernel datapath the packet must match 1 flow, impliment its
      actions, recirculate, match the 2nd flow and also impliment its actions.
      Merging creates a single flow with all actions from the 2 original flows.
      
      Firmware impliments a tunnel header push as the packet is about to egress
      the card. Therefore, if the first merge rule candiate pushes a tunnel,
      then the second rule can only have an egress action for a valid merge to
      occur (or else the action ordering will be incorrect). This prevents the
      pushing of a tunnel header followed by the pushing of a vlan header.
      
      In order to support this behaviour, firmware allows VLAN information to
      be encoded in the tunnel push action. If this is non zero then the fw will
      push a VLAN after the tunnel header push meaning that 2 such flows with
      these actions can be merged (with action order being maintained).
      
      Support tunnel in VLAN pushes by encoding VLAN information in the tunnel
      push action of any merge flow requiring this.
      Signed-off-by: default avatarJohn Hurley <john.hurley@netronome.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@netronome.com>
      Acked-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4b10c53d
  3. 20 Jul, 2019 2 commits
  4. 12 Jul, 2019 2 commits
    • John Hurley's avatar
      nfp: flower: ensure ip protocol is specified for L4 matches · 103b7c25
      John Hurley authored
      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: default avatarJohn Hurley <john.hurley@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      103b7c25
    • John Hurley's avatar
      nfp: flower: fix ethernet check on match fields · fd262a6d
      John Hurley authored
      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: default avatarJohn Hurley <john.hurley@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fd262a6d
  5. 09 Jul, 2019 5 commits
  6. 28 Jun, 2019 2 commits
  7. 15 Jun, 2019 3 commits
  8. 07 May, 2019 1 commit
  9. 06 May, 2019 1 commit
  10. 17 Apr, 2019 1 commit
  11. 15 Apr, 2019 6 commits
  12. 22 Mar, 2019 2 commits
  13. 12 Feb, 2019 1 commit
  14. 06 Feb, 2019 2 commits
  15. 18 Dec, 2018 1 commit
    • John Hurley's avatar
      nfp: flower: fix cb_ident duplicate in indirect block register · b12c97d4
      John Hurley authored
      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: default avatarEdward Cree <ecree@solarflare.com>
      Signed-off-by: default avatarJohn Hurley <john.hurley@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b12c97d4
  16. 11 Dec, 2018 1 commit
  17. 30 Nov, 2018 2 commits
  18. 11 Nov, 2018 4 commits