1. 22 7月, 2021 2 次提交
  2. 17 6月, 2021 1 次提交
  3. 03 6月, 2021 2 次提交
  4. 31 3月, 2021 1 次提交
  5. 17 3月, 2021 1 次提交
  6. 24 8月, 2020 1 次提交
  7. 21 8月, 2020 1 次提交
  8. 14 7月, 2020 1 次提交
    • P
      net: sched: Pass qdisc reference in struct flow_block_offload · c40f4e50
      Petr Machata 提交于
      Previously, shared blocks were only relevant for the pseudo-qdiscs ingress
      and clsact. Recently, a qevent facility was introduced, which allows to
      bind blocks to well-defined slots of a qdisc instance. RED in particular
      got two qevents: early_drop and mark. Drivers that wish to offload these
      blocks will be sent the usual notification, and need to know which qdisc it
      is related to.
      
      To that end, extend flow_block_offload with a "sch" pointer, and initialize
      as appropriate. This prompts changes in the indirect block facility, which
      now tracks the scheduler in addition to the netdevice. Update signatures of
      several functions similarly.
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c40f4e50
  9. 20 6月, 2020 3 次提交
  10. 02 6月, 2020 1 次提交
  11. 28 5月, 2020 1 次提交
  12. 31 3月, 2020 1 次提交
    • J
      net: sched: expose HW stats types per action used by drivers · 93a129eb
      Jiri Pirko 提交于
      It may be up to the driver (in case ANY HW stats is passed) to select
      which type of HW stats he is going to use. Add an infrastructure to
      expose this information to user.
      
      $ tc filter add dev enp3s0np1 ingress proto ip handle 1 pref 1 flower dst_ip 192.168.1.1 action drop
      $ tc -s filter show dev enp3s0np1 ingress
      filter protocol ip pref 1 flower chain 0
      filter protocol ip pref 1 flower chain 0 handle 0x1
        eth_type ipv4
        dst_ip 192.168.1.1
        in_hw in_hw_count 2
              action order 1: gact action drop
               random type none pass val 0
               index 1 ref 1 bind 1 installed 10 sec used 10 sec
              Action statistics:
              Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
              backlog 0b 0p requeues 0
              used_hw_stats immediate     <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      93a129eb
  13. 20 12月, 2019 4 次提交
  14. 29 8月, 2019 1 次提交
  15. 20 8月, 2019 1 次提交
  16. 09 8月, 2019 1 次提交
  17. 07 8月, 2019 3 次提交
    • J
      nfp: flower: verify pre-tunnel rules · 120ffd84
      John Hurley 提交于
      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: NJohn Hurley <john.hurley@netronome.com>
      Reviewed-by: NSimon Horman <simon.horman@netronome.com>
      Acked-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      120ffd84
    • J
      nfp: flower: detect potential pre-tunnel rules · f5c977ee
      John Hurley 提交于
      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: NJohn Hurley <john.hurley@netronome.com>
      Reviewed-by: NSimon Horman <simon.horman@netronome.com>
      Acked-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f5c977ee
    • J
      nfp: flower: push vlan after tunnel in merge · 4b10c53d
      John Hurley 提交于
      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: NJohn Hurley <john.hurley@netronome.com>
      Reviewed-by: NSimon Horman <simon.horman@netronome.com>
      Acked-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4b10c53d
  18. 20 7月, 2019 2 次提交
  19. 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
  20. 10 7月, 2019 5 次提交
  21. 28 6月, 2019 2 次提交
  22. 15 6月, 2019 3 次提交