Ali Gholami Rudi wrote: > "Duyck, Alexander H" <[email protected]> wrote: >> The problem is that there is only one register. As a result when you >> read the E1000_RXSTMP[LH] you end up reading the last timestamp that >> was recorded, not necessarily the one for your packet. This is due >> to the fact that all locking of the registers is disabled when set to >> 100b. > > But, AFAIR, in my tests the timestamp registers were not updated for > anything other than ptp packets. Reading E1000_RXSTMP[LH] when > .._STAT_TS was not set resulted in some constant (I think it was > zero). I can check it once more if necessary. > Actually after looking over the code I just realized that there is a bug there. The problem is that the current RX cleanup path relies on the TS bit being set in order for it to determine if it needs to read the timestamp from the packet. Since this is now not being set for any of the packets no timestamps are being returned by the TX path when we are attempting to timestamp all packets.
I will see about generating a patch to address this. >> The next version of the hardware, the 82580 MAC, will have support >> for placing the timestamps into the packet header itself so then >> when you > > Thanks for the info. Just had a look at it; 82580 support seems to be > added just a few days ago to the mainline kernel. > The current driver is still using the old path for the 82580 version of things. The standalone driver will be the first to support the per packet timestamping feature via a build option. The reason for this approach is due to the fact that adding the timestamp information to the header data increases the overall RX dma size and RX buffer allocations which has an overall negative effect on performance. >> enable the timestamp all mode you will be able to differentiate the >> timestamps between packets. > > Then I think igb_hwtstamp_ioctl() can be changed to return -ERANGE for > models not supporting them. I am thinking we might need to head this route. I am going to look over things and do some testing on this end. Once I can verify the functionality or lack thereof here I will see about generating a patch for this. > Thanks, > Ali ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ E1000-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/e1000-devel
