Re: [PATCH bpf-next v2 06/20] ice: Support HW timestamp hint

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07/10, Larysa Zaremba wrote:
> On Thu, Jul 06, 2023 at 09:39:29AM -0700, Stanislav Fomichev wrote:
> > On Thu, Jul 6, 2023 at 7:27 AM Larysa Zaremba <larysa.zaremba@xxxxxxxxx> wrote:
> > >
> > > On Wed, Jul 05, 2023 at 10:30:56AM -0700, Stanislav Fomichev wrote:
> > > > On 07/03, Larysa Zaremba wrote:
> > > > > Use previously refactored code and create a function
> > > > > that allows XDP code to read HW timestamp.
> > > > >
> > > > > Also, move cached_phctime into packet context, this way this data still
> > > > > stays in the ring structure, just at the different address.
> > > > >
> > > > > HW timestamp is the first supported hint in the driver,
> > > > > so also add xdp_metadata_ops.
> > > > >
> > > > > Signed-off-by: Larysa Zaremba <larysa.zaremba@xxxxxxxxx>
> > > > > ---
> > > > >  drivers/net/ethernet/intel/ice/ice.h          |  2 ++
> > > > >  drivers/net/ethernet/intel/ice/ice_ethtool.c  |  2 +-
> > > > >  drivers/net/ethernet/intel/ice/ice_lib.c      |  2 +-
> > > > >  drivers/net/ethernet/intel/ice/ice_main.c     |  1 +
> > > > >  drivers/net/ethernet/intel/ice/ice_ptp.c      |  2 +-
> > > > >  drivers/net/ethernet/intel/ice/ice_txrx.h     |  2 +-
> > > > >  drivers/net/ethernet/intel/ice/ice_txrx_lib.c | 24 +++++++++++++++++++
> > > > >  7 files changed, 31 insertions(+), 4 deletions(-)
> > > > >
> > > > > diff --git a/drivers/net/ethernet/intel/ice/ice.h b/drivers/net/ethernet/intel/ice/ice.h
> > > > > index 4ba3d99439a0..7a973a2229f1 100644
> > > > > --- a/drivers/net/ethernet/intel/ice/ice.h
> > > > > +++ b/drivers/net/ethernet/intel/ice/ice.h
> > > > > @@ -943,4 +943,6 @@ static inline void ice_clear_rdma_cap(struct ice_pf *pf)
> > > > >     set_bit(ICE_FLAG_UNPLUG_AUX_DEV, pf->flags);
> > > > >     clear_bit(ICE_FLAG_RDMA_ENA, pf->flags);
> > > > >  }
> > > > > +
> > > > > +extern const struct xdp_metadata_ops ice_xdp_md_ops;
> > > > >  #endif /* _ICE_H_ */
> > > > > diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool.c b/drivers/net/ethernet/intel/ice/ice_ethtool.c
> > > > > index 8d5cbbd0b3d5..3c3b9cbfbcd3 100644
> > > > > --- a/drivers/net/ethernet/intel/ice/ice_ethtool.c
> > > > > +++ b/drivers/net/ethernet/intel/ice/ice_ethtool.c
> > > > > @@ -2837,7 +2837,7 @@ ice_set_ringparam(struct net_device *netdev, struct ethtool_ringparam *ring,
> > > > >             /* clone ring and setup updated count */
> > > > >             rx_rings[i] = *vsi->rx_rings[i];
> > > > >             rx_rings[i].count = new_rx_cnt;
> > > > > -           rx_rings[i].cached_phctime = pf->ptp.cached_phc_time;
> > > > > +           rx_rings[i].pkt_ctx.cached_phctime = pf->ptp.cached_phc_time;
> > > > >             rx_rings[i].desc = NULL;
> > > > >             rx_rings[i].rx_buf = NULL;
> > > > >             /* this is to allow wr32 to have something to write to
> > > > > diff --git a/drivers/net/ethernet/intel/ice/ice_lib.c b/drivers/net/ethernet/intel/ice/ice_lib.c
> > > > > index 00e3afd507a4..eb69b0ac7956 100644
> > > > > --- a/drivers/net/ethernet/intel/ice/ice_lib.c
> > > > > +++ b/drivers/net/ethernet/intel/ice/ice_lib.c
> > > > > @@ -1445,7 +1445,7 @@ static int ice_vsi_alloc_rings(struct ice_vsi *vsi)
> > > > >             ring->netdev = vsi->netdev;
> > > > >             ring->dev = dev;
> > > > >             ring->count = vsi->num_rx_desc;
> > > > > -           ring->cached_phctime = pf->ptp.cached_phc_time;
> > > > > +           ring->pkt_ctx.cached_phctime = pf->ptp.cached_phc_time;
> > > > >             WRITE_ONCE(vsi->rx_rings[i], ring);
> > > > >     }
> > > > >
> > > > > diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
> > > > > index 93979ab18bc1..f21996b812ea 100644
> > > > > --- a/drivers/net/ethernet/intel/ice/ice_main.c
> > > > > +++ b/drivers/net/ethernet/intel/ice/ice_main.c
> > > > > @@ -3384,6 +3384,7 @@ static void ice_set_ops(struct ice_vsi *vsi)
> > > > >
> > > > >     netdev->netdev_ops = &ice_netdev_ops;
> > > > >     netdev->udp_tunnel_nic_info = &pf->hw.udp_tunnel_nic;
> > > > > +   netdev->xdp_metadata_ops = &ice_xdp_md_ops;
> > > > >     ice_set_ethtool_ops(netdev);
> > > > >
> > > > >     if (vsi->type != ICE_VSI_PF)
> > > > > diff --git a/drivers/net/ethernet/intel/ice/ice_ptp.c b/drivers/net/ethernet/intel/ice/ice_ptp.c
> > > > > index a31333972c68..70697e4829dd 100644
> > > > > --- a/drivers/net/ethernet/intel/ice/ice_ptp.c
> > > > > +++ b/drivers/net/ethernet/intel/ice/ice_ptp.c
> > > > > @@ -1038,7 +1038,7 @@ static int ice_ptp_update_cached_phctime(struct ice_pf *pf)
> > > > >             ice_for_each_rxq(vsi, j) {
> > > > >                     if (!vsi->rx_rings[j])
> > > > >                             continue;
> > > > > -                   WRITE_ONCE(vsi->rx_rings[j]->cached_phctime, systime);
> > > > > +                   WRITE_ONCE(vsi->rx_rings[j]->pkt_ctx.cached_phctime, systime);
> > > > >             }
> > > > >     }
> > > > >     clear_bit(ICE_CFG_BUSY, pf->state);
> > > > > diff --git a/drivers/net/ethernet/intel/ice/ice_txrx.h b/drivers/net/ethernet/intel/ice/ice_txrx.h
> > > > > index d0ab2c4c0c91..4237702a58a9 100644
> > > > > --- a/drivers/net/ethernet/intel/ice/ice_txrx.h
> > > > > +++ b/drivers/net/ethernet/intel/ice/ice_txrx.h
> > > > > @@ -259,6 +259,7 @@ enum ice_rx_dtype {
> > > > >
> > > > >  struct ice_pkt_ctx {
> > > > >     const union ice_32b_rx_flex_desc *eop_desc;
> > > > > +   u64 cached_phctime;
> > > > >  };
> > > > >
> > > > >  struct ice_xdp_buff {
> > > > > @@ -354,7 +355,6 @@ struct ice_rx_ring {
> > > > >     struct ice_tx_ring *xdp_ring;
> > > > >     struct xsk_buff_pool *xsk_pool;
> > > > >     dma_addr_t dma;                 /* physical address of ring */
> > > > > -   u64 cached_phctime;
> > > > >     u16 rx_buf_len;
> > > > >     u8 dcb_tc;                      /* Traffic class of ring */
> > > > >     u8 ptp_rx;
> > > > > diff --git a/drivers/net/ethernet/intel/ice/ice_txrx_lib.c b/drivers/net/ethernet/intel/ice/ice_txrx_lib.c
> > > > > index beb1c5bb392a..463d9e5cbe05 100644
> > > > > --- a/drivers/net/ethernet/intel/ice/ice_txrx_lib.c
> > > > > +++ b/drivers/net/ethernet/intel/ice/ice_txrx_lib.c
> > > > > @@ -546,3 +546,27 @@ void ice_finalize_xdp_rx(struct ice_tx_ring *xdp_ring, unsigned int xdp_res,
> > > > >                     spin_unlock(&xdp_ring->tx_lock);
> > > > >     }
> > > > >  }
> > > > > +
> > > > > +/**
> > > > > + * ice_xdp_rx_hw_ts - HW timestamp XDP hint handler
> > > > > + * @ctx: XDP buff pointer
> > > > > + * @ts_ns: destination address
> > > > > + *
> > > > > + * Copy HW timestamp (if available) to the destination address.
> > > > > + */
> > > > > +static int ice_xdp_rx_hw_ts(const struct xdp_md *ctx, u64 *ts_ns)
> > > > > +{
> > > > > +   const struct ice_xdp_buff *xdp_ext = (void *)ctx;
> > > > > +   u64 cached_time;
> > > > > +
> > > > > +   cached_time = READ_ONCE(xdp_ext->pkt_ctx.cached_phctime);
> > > >
> > > > I believe we have to have something like the following here:
> > > >
> > > > if (!ts_ns)
> > > >       return -EINVAL;
> > > >
> > > > IOW, I don't think verifier guarantees that those pointer args are
> > > > non-NULL.
> > >
> > > Oh, that's a shame.
> > >
> > > > Same for the other ice kfunc you're adding and veth changes.
> > > >
> > > > Can you also fix it for the existing veth kfuncs? (or lmk if you prefer me
> > > > to fix it).
> > >
> > > I think I can send fixes for RX hash and timestamp in veth separately, before
> > > v3 of this patchset, code probably doesn't intersect.
> > >
> > > But argument checks in kfuncs are a little bit a gray area for me, whether they
> > > should be sent to stable tree or not?
> > 
> > Add a Fixes tag and they will get into the stable trees automatically I believe?
> 
> What about declaring XDP hints kfuncs with
> 
> BTF_ID_FLAGS(func, name, KF_TRUSTED_ARGS)
> 
> instead of BTF_ID_FLAGS(func, name, 0)
> ?
> 
> I have tested this just now and xdp_metadata passes just fine (so both stack 
> and data_meta destination pointers work), but if I replace &timestamp with NULL,
> verifier rejects the program with a descriptive message "Possibly NULL pointer 
> passed to trusted arg1", so it serves our purpose. I do not see many ways this 
> could limit the users, but it definitely benefits driver developers.
> 
> The only concern I see is that if we ever decide to allow NULL arguments for 
> kfuncs, we'd need to add support for a "_or_null" suffix [0]. But it doesn't 
> sound too hard?
> 
> I have dug into this, because adding
> 
> if (unlikely(!hash || &rss_type))
> 	return -EINVAL;
> 
> or something similar to every .xmo_ handler in existence starts to look ugly.
> 
> [0] 
> https://lore.kernel.org/lkml/20230120054441.arj5h6yrnh5jsrgr@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/

SG! Let's add KF_TRUSTED_ARGS. That is munch nicer indeed!





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux