On 05/12/2015 05:44 AM, Arnd Bergmann wrote:
On Monday 11 May 2015 21:00:25 Ed Cashin wrote:
...
In that case, there is still information about the timing embedded in
the AoE tag. The send time in jiffies is a rough-grained record of the
send time, and it's extracted from the tag. For these "
Thanks for the expanded motivation. I'll return to your ideas tonight, but I
wanted to mention that it is possible for round trips to take well over five
seconds, partly because the disk on the target might be resetting.
If the rough-grained mechanism in the AoE tag still works, though, that's
On Monday 11 May 2015 21:00:25 Ed Cashin wrote:
> First, thanks for the patch. I do appreciate the attempt to simplify
> this part of the driver, but I don't think that this patch is good to merge.
>
> I'll make some comments inline below.
>
> On 05/10/2015 10:35 PM, Tina Ruchandani wrote:
> > '
First, thanks for the patch. I do appreciate the attempt to simplify
this part of the driver, but I don't think that this patch is good to merge.
I'll make some comments inline below.
On 05/10/2015 10:35 PM, Tina Ruchandani wrote:
'struct frame' uses two variables to store the sent timestamp -
I would like to see some performance measurements for this patch on a system
with fast storage and multiple 10 GbE links.
If not, at least a good analysis of the expected performance impact the patch
will have on major architectures.
Tonight I will think about whether the 2038 thing even matt
On Monday 11 May 2015 08:05:05 Tina Ruchandani wrote:
> 'struct frame' uses two variables to store the sent timestamp - 'struct
> timeval' and jiffies. jiffies is used to avoid discrepancies caused by
> updates to system time. 'struct timeval' uses 32-bit representation for
> seconds which will ove
6 matches
Mail list logo
