Re: [net-next v3 11/15] iecm: Add splitq TX/RX

[Joe Perches <joe@perches.com>]

On Fri, 2020-06-26 at 12:58 -0700, Jakub Kicinski wrote:
> On Thu, 25 Jun 2020 19:07:33 -0700 Jeff Kirsher wrote:
> > @@ -1315,7 +1489,18 @@ iecm_tx_splitq_clean(struct iecm_queue *tx_q, u16 end, int napi_budget,
> >   */
> >  static inline void iecm_tx_hw_tstamp(struct sk_buff *skb, u8 *desc_ts)
> 
> Pretty sure you don't need the inline here. It's static function with
> one caller.
> 
> >  {
> > -	/* stub */
> > +	struct skb_shared_hwtstamps hwtstamps;
> > +	u64 tstamp;
> > +
> > +	/* Only report timestamp to stack if requested */
> > +	if (!likely(skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP))
> > +		return;

Is this supposed to be unlikely?

> > +	tstamp = (desc_ts[0] | (desc_ts[1] << 8) | (desc_ts[2] & 0x3F) << 16);

btw: there are inconsistent parentheses for the ORs vs shifts here.

I think this might read better as

	tstamp = desc_ts[0] | (desc_ts[1] << 8) | ((desc_ts[2] & 0x3F) << 16);

This is a u64 result, but the ORs are int

23 bits of timestamp isn't very many at 100Gb.

> > +	hwtstamps.hwtstamp =
> > +		ns_to_ktime(tstamp << IECM_TW_TIME_STAMP_GRAN_512_DIV_S);
> > +
> > +	skb_tstamp_tx(skb, &hwtstamps);
> >  }
> 
> Why is there time stamp reading support if you have no ts_info
> configuration on ethtool side at all and no PHC support?