1. 10 Dec, 2022 1 commit
    • Jakub Kicinski's avatar
      Merge branch '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue · 043cd1e2
      Jakub Kicinski authored
      Tony Nguyen says:
      
      ====================
      Intel Wired LAN Driver Updates 2022-12-08 (ice)
      
      Jacob Keller says:
      
      This series of patches primarily consists of changes to fix some corner
      cases that can cause Tx timestamp failures. The issues were discovered and
      reported by Siddaraju DH and primarily affect E822 hardware, though this
      series also includes some improvements that affect E810 hardware as well.
      
      The primary issue is regarding the way that E822 determines when to generate
      timestamp interrupts. If the driver reads timestamp indexes which do not
      have a valid timestamp, the E822 interrupt tracking logic can get stuck.
      This is due to the way that E822 hardware tracks timestamp index reads
      internally. I was previously unaware of this behavior as it is significantly
      different in E810 hardware.
      
      Most of the fixes target refactors to ensure that the ice driver does not
      read timestamp indexes which are not valid on E822 hardware. This is done by
      using the Tx timestamp ready bitmap register from the PHY. This register
      indicates what timestamp indexes have outstanding timestamps waiting to be
      captured.
      
      Care must be taken in all cases where we read the timestamp registers, and
      thus all flows which might have read these registers are refactored. The
      ice_ptp_tx_tstamp function is modified to consolidate as much of the logic
      relating to these registers as possible. It now handles discarding stale
      timestamps which are old or which occurred after a PHC time update. This
      replaces previously standalone thread functions like the periodic work
      function and the ice_ptp_flush_tx_tracker function.
      
      In addition, some minor cleanups noticed while writing these refactors are
      included.
      
      The remaining patches refactor the E822 implementation to remove the
      "bypass" mode for timestamps. The E822 hardware has the ability to provide a
      more precise timestamp by making use of measurements of the precise way that
      packets flow through the hardware pipeline. These measurements are known as
      "Vernier" calibration. The "bypass" mode disables many of these measurements
      in favor of a faster start up time for Tx and Rx timestamping. Instead, once
      these measurements were captured, the driver tries to reconfigure the PHY to
      enable the vernier calibrations.
      
      Unfortunately this recalibration does not work. Testing indicates that the
      PHY simply remains in bypass mode without the increased timestamp precision.
      Remove the attempt at recalibration and always use vernier mode. This has
      one disadvantage that Tx and Rx timestamps cannot begin until after at least
      one packet of that type goes through the hardware pipeline. Because of this,
      further refactor the driver to separate Tx and Rx vernier calibration.
      Complete the Tx and Rx independently, enabling the appropriate type of
      timestamp as soon as the relevant packet has traversed the hardware
      pipeline. This was reported by Milena Olech.
      
      Note that although these might be considered "bug fixes", the required
      changes in order to appropriately resolve these issues is large. Thus it
      does not feel suitable to send this series to net.
      
      * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue:
        ice: reschedule ice_ptp_wait_for_offset_valid during reset
        ice: make Tx and Rx vernier offset calibration independent
        ice: only check set bits in ice_ptp_flush_tx_tracker
        ice: handle flushing stale Tx timestamps in ice_ptp_tx_tstamp
        ice: cleanup allocations in ice_ptp_alloc_tx_tracker
        ice: protect init and calibrating check in ice_ptp_request_ts
        ice: synchronize the misc IRQ when tearing down Tx tracker
        ice: check Tx timestamp memory register for ready timestamps
        ice: handle discarding old Tx requests in ice_ptp_tx_tstamp
        ice: always call ice_ptp_link_change and make it void
        ice: fix misuse of "link err" with "link status"
        ice: Reset TS memory for all quads
        ice: Remove the E822 vernier "bypass" logic
        ice: Use more generic names for ice_ptp_tx fields
      ====================
      
      Link: https://lore.kernel.org/r/20221208213932.1274143-1-anthony.l.nguyen@intel.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      043cd1e2
  2. 09 Dec, 2022 22 commits
  3. 08 Dec, 2022 17 commits
    • Linus Torvalds's avatar
      Merge tag 'net-6.1-rc9' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net · 010b6761
      Linus Torvalds authored
      Pull networking fixes from Jakub Kicinski:
       "Including fixes from bluetooth, can and netfilter.
      
        Current release - new code bugs:
      
         - bonding: ipv6: correct address used in Neighbour Advertisement
           parsing (src vs dst typo)
      
         - fec: properly scope IRQ coalesce setup during link up to supported
           chips only
      
        Previous releases - regressions:
      
         - Bluetooth fixes for fake CSR clones (knockoffs):
             - re-add ERR_DATA_REPORTING quirk
             - fix crash when device is replugged
      
         - Bluetooth:
             - silence a user-triggerable dmesg error message
             - L2CAP: fix u8 overflow, oob access
             - correct vendor codec definition
             - fix support for Read Local Supported Codecs V2
      
         - ti: am65-cpsw: fix RGMII configuration at SPEED_10
      
         - mana: fix race on per-CQ variable NAPI work_done
      
        Previous releases - always broken:
      
         - af_unix: diag: fetch user_ns from in_skb in unix_diag_get_exact(),
           avoid null-deref
      
         - af_can: fix NULL pointer dereference in can_rcv_filter
      
         - can: slcan: fix UAF with a freed work
      
         - can: can327: flush TX_work on ldisc .close()
      
         - macsec: add missing attribute validation for offload
      
         - ipv6: avoid use-after-free in ip6_fragment()
      
         - nft_set_pipapo: actually validate intervals in fields after the
           first one
      
         - mvneta: prevent oob access in mvneta_config_rss()
      
         - ipv4: fix incorrect route flushing when table ID 0 is used, or when
           source address is deleted
      
         - phy: mxl-gpy: add workaround for IRQ bug on GPY215B and GPY215C"
      
      * tag 'net-6.1-rc9' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (77 commits)
        net: dsa: sja1105: avoid out of bounds access in sja1105_init_l2_policing()
        s390/qeth: fix use-after-free in hsci
        macsec: add missing attribute validation for offload
        net: mvneta: Fix an out of bounds check
        net: thunderbolt: fix memory leak in tbnet_open()
        ipv6: avoid use-after-free in ip6_fragment()
        net: plip: don't call kfree_skb/dev_kfree_skb() under spin_lock_irq()
        net: phy: mxl-gpy: add MDINT workaround
        net: dsa: mv88e6xxx: accept phy-mode = "internal" for internal PHY ports
        xen/netback: don't call kfree_skb() under spin_lock_irqsave()
        dpaa2-switch: Fix memory leak in dpaa2_switch_acl_entry_add() and dpaa2_switch_acl_entry_remove()
        ethernet: aeroflex: fix potential skb leak in greth_init_rings()
        tipc: call tipc_lxc_xmit without holding node_read_lock
        can: esd_usb: Allow REC and TEC to return to zero
        can: can327: flush TX_work on ldisc .close()
        can: slcan: fix freed work crash
        can: af_can: fix NULL pointer dereference in can_rcv_filter
        net: dsa: sja1105: fix memory leak in sja1105_setup_devlink_regions()
        ipv4: Fix incorrect route flushing when table ID 0 is used
        ipv4: Fix incorrect route flushing when source address is deleted
        ...
      010b6761
    • Jakub Kicinski's avatar
      Merge branch 'mlx4-better-big-tcp-support' · ff36c447
      Jakub Kicinski authored
      Eric Dumazet says:
      
      ====================
      mlx4: better BIG-TCP support
      
      mlx4 uses a bounce buffer in TX whenever the tx descriptors
      wrap around the right edge of the ring.
      
      Size of this bounce buffer was hard coded and can be
      increased if/when needed.
      ====================
      
      Link: https://lore.kernel.org/r/20221207141237.2575012-1-edumazet@google.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      ff36c447
    • Eric Dumazet's avatar
      net/mlx4: small optimization in mlx4_en_xmit() · 0e706f79
      Eric Dumazet authored
      Test against MLX4_MAX_DESC_TXBBS only matters if the TX
      bounce buffer is going to be used.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Wei Wang <weiwan@google.com>
      Reviewed-by: default avatarTariq Toukan <tariqt@nvidia.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      0e706f79
    • Eric Dumazet's avatar
      net/mlx4: MLX4_TX_BOUNCE_BUFFER_SIZE depends on MAX_SKB_FRAGS · 26782aad
      Eric Dumazet authored
      Google production kernel has increased MAX_SKB_FRAGS to 45
      for BIG-TCP rollout.
      
      Unfortunately mlx4 TX bounce buffer is not big enough whenever
      an skb has up to 45 page fragments.
      
      This can happen often with TCP TX zero copy, as one frag usually
      holds 4096 bytes of payload (order-0 page).
      
      Tested:
       Kernel built with MAX_SKB_FRAGS=45
       ip link set dev eth0 gso_max_size 185000
       netperf -t TCP_SENDFILE
      
      I made sure that "ethtool -G eth0 tx 64" was properly working,
      ring->full_size being set to 15.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarWei Wang <weiwan@google.com>
      Reviewed-by: default avatarTariq Toukan <tariqt@nvidia.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      26782aad
    • Eric Dumazet's avatar
      net/mlx4: rename two constants · 35f31ff0
      Eric Dumazet authored
      MAX_DESC_SIZE is really the size of the bounce buffer used
      when reaching the right side of TX ring buffer.
      
      MAX_DESC_TXBBS get a MLX4_ prefix.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reviewed-by: default avatarTariq Toukan <tariqt@nvidia.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      35f31ff0
    • Jacob Keller's avatar
      ice: reschedule ice_ptp_wait_for_offset_valid during reset · 95af1f1c
      Jacob Keller authored
      If the ice_ptp_wait_for_offest_valid function is scheduled to run while the
      driver is resetting, it will exit without completing calibration. The work
      function gets scheduled by ice_ptp_port_phy_restart which will be called as
      part of the reset recovery process.
      
      It is possible for the first execution to occur before the driver has
      completely cleared its resetting flags. Ensure calibration completes by
      rescheduling the task until reset is fully completed.
      Reported-by: default avatarSiddaraju DH <siddaraju.dh@intel.com>
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      95af1f1c
    • Siddaraju DH's avatar
      ice: make Tx and Rx vernier offset calibration independent · f029a343
      Siddaraju DH authored
      The Tx and Rx calibration and timestamp generation blocks are independent.
      However, the ice driver waits until both blocks are ready before
      configuring either block.
      
      This can result in delay of configuring one block because we have not yet
      received a packet in the other block.
      
      There is no reason to wait to finish programming Tx just because we haven't
      received a packet. Similarly there is no reason to wait to program Rx just
      because we haven't transmitted a packet.
      
      Instead of checking both offset status before programming either block,
      refactor the ice_phy_cfg_tx_offset_e822 and ice_phy_cfg_rx_offset_e822
      functions so that they perform their own offset status checks.
      Additionally, make them also check the offset ready bit to determine if
      the offset values have already been programmed.
      
      Call the individual configure functions directly in
      ice_ptp_wait_for_offset_valid. The functions will now correctly check
      status, and program the offsets if ready. Once the offset is programmed,
      the functions will exit quickly after just checking the offset ready
      register.
      
      Remove the ice_phy_calc_vernier_e822 in ice_ptp_hw.c, as well as the offset
      valid check functions in ice_ptp.c entirely as they are no longer
      necessary.
      
      With this change, the Tx and Rx blocks will each be enabled as soon as
      possible without waiting for the other block to complete calibration. This
      can enable timestamps faster in setups which have a low rate of transmitted
      or received packets. In particular, it can stop a situation where one port
      never receives traffic, and thus never finishes calibration of the Tx
      block, resulting in continuous faults reported by the ptp4l daemon
      application.
      Signed-off-by: default avatarSiddaraju DH <siddaraju.dh@intel.com>
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      f029a343
    • Jacob Keller's avatar
      ice: only check set bits in ice_ptp_flush_tx_tracker · e3ba5248
      Jacob Keller authored
      The ice_ptp_flush_tx_tracker function is called to clear all outstanding Tx
      timestamp requests when the port is being brought down. This function
      iterates over the entire list, but this is unnecessary. We only need to
      check the bits which are actually set in the ready bitmap.
      
      Replace this logic with for_each_set_bit, and follow a similar flow as in
      ice_ptp_tx_tstamp_cleanup. Note that it is safe to call dev_kfree_skb_any
      on a NULL pointer as it will perform a no-op so we do not need to verify
      that the skb is actually NULL.
      
      The new implementation also avoids clearing (and thus reading!) the PHY
      timestamp unless the index is marked as having a valid timestamp in the
      timestamp status bitmap. This ensures that we properly clear the status
      registers as appropriate.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      e3ba5248
    • Jacob Keller's avatar
      ice: handle flushing stale Tx timestamps in ice_ptp_tx_tstamp · d40fd600
      Jacob Keller authored
      In the event of a PTP clock time change due to .adjtime or .settime, the
      ice driver needs to update the cached copy of the PHC time and also discard
      any outstanding Tx timestamps.
      
      This is required because otherwise the wrong copy of the PHC time will be
      used when extending the Tx timestamp. This could result in reporting
      incorrect timestamps to the stack.
      
      The current approach taken to handle this is to call
      ice_ptp_flush_tx_tracker, which will discard any timestamps which are not
      yet complete.
      
      This is problematic for two reasons:
      
      1) it could lead to a potential race condition where the wrong timestamp is
         associated with a future packet.
      
         This can occur with the following flow:
      
         1. Thread A gets request to transmit a timestamped packet, and picks an
            index and transmits the packet
      
         2. Thread B calls ice_ptp_flush_tx_tracker and sees the index in use,
            marking is as disarded. No timestamp read occurs because the status
            bit is not set, but the index is released for re-use
      
         3. Thread A gets a new request to transmit another timestamped packet,
            picks the same (now unused) index and transmits that packet.
      
         4. The PHY transmits the first packet and updates the timestamp slot and
            generates an interrupt.
      
         5. The ice_ptp_tx_tstamp thread executes and sees the interrupt and a
            valid timestamp but associates it with the new Tx SKB and not the one
            that actual timestamp for the packet as expected.
      
         This could result in the previous timestamp being assigned to a new
         packet producing incorrect timestamps and leading to incorrect behavior
         in PTP applications.
      
         This is most likely to occur when the packet rate for Tx timestamp
         requests is very high.
      
      2) on E822 hardware, we must avoid reading a timestamp index more than once
         each time its status bit is set and an interrupt is generated by
         hardware.
      
         We do have some extensive checks for the unread flag to ensure that only
         one of either the ice_ptp_flush_tx_tracker or ice_ptp_tx_tstamp threads
         read the timestamp. However, even with this we can still have cases
         where we "flush" a timestamp that was actually completed in hardware.
         This can lead to cases where we don't read the timestamp index as
         appropriate.
      
      To fix both of these issues, we must avoid calling ice_ptp_flush_tx_tracker
      outside of the teardown path.
      
      Rather than using ice_ptp_flush_tx_tracker, introduce a new state bitmap,
      the stale bitmap. Start this as cleared when we begin a new timestamp
      request. When we're about to extend a timestamp and send it up to the
      stack, first check to see if that stale bit was set. If so, drop the
      timestamp without sending it to the stack.
      
      When we need to update the cached PHC timestamp out of band, just mark all
      currently outstanding timestamps as stale. This will ensure that once
      hardware completes the timestamp we'll ignore it correctly and avoid
      reporting bogus timestamps to userspace.
      
      With this change, we fix potential issues caused  by calling
      ice_ptp_flush_tx_tracker during normal operation.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      d40fd600
    • Jacob Keller's avatar
      ice: cleanup allocations in ice_ptp_alloc_tx_tracker · c1f3414d
      Jacob Keller authored
      The ice_ptp_alloc_tx_tracker function must allocate the timestamp array and
      the bitmap for tracking the currently in use indexes. A future change is
      going to add yet another allocation to this function.
      
      If these allocations fail we need to ensure that we properly cleanup and
      ensure that the pointers in the ice_ptp_tx structure are NULL.
      
      Simplify this logic by allocating to local variables first. If any
      allocation fails, then free everything and exit. Only update the ice_ptp_tx
      structure if all allocations succeed.
      
      This ensures that we have no side effects on the Tx structure unless all
      allocations have succeeded. Thus, no code will see an invalid pointer and
      we don't need to re-assign NULL on cleanup.
      
      This is safe because kernel "free" functions are designed to be NULL safe
      and perform no action if passed a NULL pointer. Thus its safe to simply
      always call kfree or bitmap_free even if one of those pointers was NULL.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      c1f3414d
    • Jacob Keller's avatar
      ice: protect init and calibrating check in ice_ptp_request_ts · 3ad5c10b
      Jacob Keller authored
      When requesting a new timestamp, the ice_ptp_request_ts function does not
      hold the Tx tracker lock while checking init and calibrating. This means
      that we might issue a new timestamp request just after the Tx timestamp
      tracker starts being deinitialized. This could lead to incorrect access of
      the timestamp structures. Correct this by moving the init and calibrating
      checks under the lock, and updating the flows which modify these fields to
      use the lock.
      
      Note that we do not need to hold the lock while checking for tx->init in
      ice_ptp_tx_tstamp. This is because the teardown function will use
      synchronize_irq after clearing the flag to ensure that the threaded
      interrupt completes. Either a) the tx->init flag will be cleared before the
      ice_ptp_tx_tstamp function starts, thus it will exit immediately, or b) the
      threaded interrupt will be executing and the synchronize_irq will wait
      until the threaded interrupt has completed at which point we know the init
      field has definitely been set and new interrupts will not execute the Tx
      timestamp thread function.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      3ad5c10b
    • Jakub Kicinski's avatar
      Merge branch 'mlx5-Support-tc-police-jump-conform-exceed-attribute' · ddda6326
      Jakub Kicinski authored
      Saeed Mahameed says:
      
      ====================
      Support tc police jump conform-exceed attribute
      
      The tc police action conform-exceed option defines how to handle
      packets which exceed or conform to the configured bandwidth limit.
      One of the possible conform-exceed values is jump, which skips over
      a specified number of actions.
      This series adds support for conform-exceed jump action.
      
      The series adds platform support for branching actions by providing
      true/false flow attributes to the branching action.
      This is necessary for supporting police jump, as each branch may
      execute a different action list.
      
      The first five patches are preparation patches:
      - Patches 1 and 2 add support for actions with no destinations (e.g. drop)
      - Patch 3 refactor the code for subsequent function reuse
      - Patch 4 defines an abstract way for identifying terminating actions
      - Patch 5 updates action list validations logic considering branching actions
      
      The following three patches introduce an interface for abstracting branching
      actions:
      - Patch 6 introduces an abstract api for defining branching actions
      - Patch 7 generically instantiates the branching flow attributes using
        the abstract API
      
      Patch 8 adds the platform support for jump actions, by executing the following
      sequence:
        a. Store the jumping flow attr
        b. Identify the jump target action while iterating the actions list.
        c. Instantiate a new flow attribute after the jump target action.
           This is the flow attribute that the branching action should jump to.
        d. Set the target post action id on:
          d.1. The jumping attribute, thus realizing the jump functionality.
          d.2. The attribute preceding the target jump attr, if not terminating.
      
      The next patches apply the platform's branching attributes to the police
      action:
      - Patch 9 is a refactor patch
      - Patch 10 initializes the post meter table with the red/green flow attributes,
                 as were initialized by the platform
      - Patch 11 enables the offload of meter actions using jump conform-exceed
                 value.
      ====================
      
      Link: https://lore.kernel.org/all/20221203221337.29267-1-saeed@kernel.org/Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      ddda6326
    • Oz Shlomo's avatar
      net/mlx5e: TC, allow meter jump control action · 3603f266
      Oz Shlomo authored
      Separate the matchall police action validation from flower validation.
      Isolate the action validation logic in the police action parser.
      Signed-off-by: default avatarOz Shlomo <ozsh@nvidia.com>
      Reviewed-by: default avatarRoi Dayan <roid@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      Link: https://lore.kernel.org/r/20221203221337.29267-12-saeed@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      3603f266
    • Oz Shlomo's avatar
      net/mlx5e: TC, init post meter rules with branching attributes · 0d8c38d4
      Oz Shlomo authored
      Instantiate the post meter actions with the platform initialized branching
      action attributes.
      Signed-off-by: default avatarOz Shlomo <ozsh@nvidia.com>
      Reviewed-by: default avatarRoi Dayan <roid@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      Link: https://lore.kernel.org/r/20221203221337.29267-11-saeed@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      0d8c38d4
    • Oz Shlomo's avatar
      net/mlx5e: TC, rename post_meter actions · 3fcb94e3
      Oz Shlomo authored
      Currently post meter supports only the pipe/drop conform-exceed policy.
      This assumption is reflected in several variable names.
      Rename the following variables as a pre-step for using the generalized
      branching action platform.
      
      Rename fwd_green_rule/drop_red_rule to green_rule/red_rule respectively.
      Repurpose red_counter/green_counter to act_counter/drop_counter to allow
      police conform-exceed configurations that do not drop.
      Signed-off-by: default avatarOz Shlomo <ozsh@nvidia.com>
      Reviewed-by: default avatarRoi Dayan <roid@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      Link: https://lore.kernel.org/r/20221203221337.29267-10-saeed@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      3fcb94e3
    • Oz Shlomo's avatar
      net/mlx5e: TC, initialize branching action with target attr · c84fa1ab
      Oz Shlomo authored
      Identify the jump target action when iterating the action list.
      Initialize the jump target attr with the jumping attribute during the
      parsing phase. Initialize the jumping attr post action with the target
      during the offload phase.
      Signed-off-by: default avatarOz Shlomo <ozsh@nvidia.com>
      Reviewed-by: default avatarRoi Dayan <roid@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      Link: https://lore.kernel.org/r/20221203221337.29267-9-saeed@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      c84fa1ab
    • Oz Shlomo's avatar
      net/mlx5e: TC, initialize branch flow attributes · f86488cb
      Oz Shlomo authored
      Initialize flow attribute for drop, accept, pipe and jump branching actions.
      
      Instantiate a flow attribute instance according to the specified branch
      control action. Store the branching attributes on the branching action
      flow attribute during the parsing phase. Then, during the offload phase,
      allocate the relevant mod header objects to the branching actions.
      Signed-off-by: default avatarOz Shlomo <ozsh@nvidia.com>
      Reviewed-by: default avatarRoi Dayan <roid@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      Link: https://lore.kernel.org/r/20221203221337.29267-8-saeed@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      f86488cb