Hello Olivier and Slava,
On Tue, Jul 7, 2020 at 10:47 AM Olivier Matz wrote:
> For the pmd pcap part, the dynamic Tx timestamp flag that is being
> introduced by Slava [1] may fit your needs: ie. when the flag is set, it
> uses the provided timestamp which should be in nanosecs.
>
> [1] https://p
Hi Patrick,
On Mon, Jul 06, 2020 at 02:36:30PM -0400, PATRICK KEROULAS wrote:
> On Fri, Jun 26, 2020 at 2:48 AM Olivier Matz wrote:
> > I don't get why you expect that timestamp to be in nanoseconds.
> > The conversion is done in librte_pdump (in the previous patch),
> > but it won't work if the
On Fri, Jun 26, 2020 at 2:48 AM Olivier Matz wrote:
> I don't get why you expect that timestamp to be in nanoseconds.
> The conversion is done in librte_pdump (in the previous patch),
> but it won't work if the library is not used, right?
>
You're right Olivier. I took advantage of the definition
On Thu, 25 Jun 2020 15:01:19 -0400
Vivien Didelot wrote:
> + struct timeval cur_time = {
> + .tv_sec = cycles / hz,
> + .tv_usec = (cycles % hz) * NSEC_PER_SEC / hz,
This is hot path, use rte_reciprocal_divide rather than slow divide instructio
When hardware timestamping is enabled on Rx path, system time should
no longer be used to calculate the timestamps when dumping packets.
Instead, use the value stored by the driver in mbuf->timestamp
and assume it is already converted to nanoseconds (otherwise the
application may edit the packet h
On Thu, Jun 25, 2020 at 03:01:19PM -0400, Vivien Didelot wrote:
> When hardware timestamping is enabled on Rx path, system time should
> no longer be used to calculate the timestamps when dumping packets.
>
> Instead, use the value stored by the driver in mbuf->timestamp
> and assume it is already
6 matches
Mail list logo
