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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <552ee6083623bb7fe5e11f33cff654deed8e0982.camel@perches.com>
Date:   Fri, 26 Jun 2020 18:26:56 -0700
From:   Joe Perches <joe@...ches.com>
To:     Jakub Kicinski <kuba@...nel.org>,
        Jeff Kirsher <jeffrey.t.kirsher@...el.com>
Cc:     davem@...emloft.net, Alice Michael <alice.michael@...el.com>,
        netdev@...r.kernel.org, nhorman@...hat.com, sassmann@...hat.com,
        Alan Brady <alan.brady@...el.com>,
        Phani Burra <phani.r.burra@...el.com>,
        Joshua Hay <joshua.a.hay@...el.com>,
        Madhu Chittim <madhu.chittim@...el.com>,
        Pavan Kumar Linga <pavan.kumar.linga@...el.com>,
        Donald Skidmore <donald.c.skidmore@...el.com>,
        Jesse Brandeburg <jesse.brandeburg@...el.com>,
        Sridhar Samudrala <sridhar.samudrala@...el.com>
Subject: Re: [net-next v3 11/15] iecm: Add splitq TX/RX

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?