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?
