> Now that I know the issue is only in TCP, I can speculate that all bytes are
> > being reported, but done with fewer messages. It may warrant some
> > investigation in case there is some kind of bug.
>
> This would definitely still be a bug and should not happen. We have
> quite a bit of
On Tue, May 28, 2019 at 12:57 PM Fred Klassen wrote:
>
>
>
> > On May 28, 2019, at 8:08 AM, Willem de Bruijn
> > wrote:
> >
>
> I will push up latest patches soon.
>
> I did some testing and discovered that only TCP audit tests failed. They
> failed much less often when enabling poll. Once in
> On May 28, 2019, at 8:08 AM, Willem de Bruijn
> wrote:
>
I will push up latest patches soon.
I did some testing and discovered that only TCP audit tests failed. They
failed much less often when enabling poll. Once in about 20 runs
still failed. Therefore I commented out the TCP audit
> >> I have been wondering about xmit_more
> >> myself. I don’t think it changes anything for software timestamps,
> >> but it may with hardware timestamps.
> >
> > It arguably makes the software timestamp too early if taken on the
> > first segment, as the NIC is only informed of all the new
> On May 27, 2019, at 6:15 PM, Willem de Bruijn
> wrote:
>> I wanted to discuss whether or not to attach a buffer to the
>> recvmsg(fd, , MSG_ERRQUEUE). Without it, I have
>> MSG_TRUNC errors in my msg_flags. Either I have to add
>> a buffer, or ignore that error flag.
>
> Either sounds
On Mon, May 27, 2019 at 6:56 PM Fred Klassen wrote:
>
>
>
> > On May 27, 2019, at 2:46 PM, Willem de Bruijn
> > wrote:
> >> Also, I my v2 fix in net is still up for debate. In its current state, it
> >> meets my application’s requirements, but may not meet all of yours.
>
> > I gave more
> On May 27, 2019, at 2:46 PM, Willem de Bruijn
> wrote:
>> Also, I my v2 fix in net is still up for debate. In its current state, it
>> meets my application’s requirements, but may not meet all of yours.
> I gave more specific feedback on issues with it (referencing zerocopy
> and IP_TOS,
On Mon, May 27, 2019 at 5:30 PM Fred Klassen wrote:
>
> Willem,
>
> Thanks for spending so much time with me on this patch. I’m pretty
> new to this, so I know I am making lots of mistakes. I have been
> working on a v2 of the selftests in net-next, but want to review the
> layout of the report
Willem,
Thanks for spending so much time with me on this patch. I’m pretty
new to this, so I know I am making lots of mistakes. I have been
working on a v2 of the selftests in net-next, but want to review the
layout of the report before I submit (see below).
Also, I my v2 fix in net is still up
On Thu, May 23, 2019 at 9:27 PM Fred Klassen wrote:
>
> Willem, this is only my 2nd patch, and my last one was a one liner.
> I’ll try to work through this, but let me know if I am doing a rookie
> mistake (learning curve and all).
Not at all. The fix makes perfect sense.
The test patches 2 and
Willem, this is only my 2nd patch, and my last one was a one liner.
I’ll try to work through this, but let me know if I am doing a rookie
mistake (learning curve and all).
> On May 23, 2019, at 2:56 PM, Willem de Bruijn
> wrote:
>
> On Thu, May 23, 2019 at 5:11 PM Fred Klassen wrote:
>>
>>
On Thu, May 23, 2019 at 5:11 PM Fred Klassen wrote:
>
> This enhancement adds the '-a' option, which will count all CMSG
> messages on the error queue and print a summary report.
>
> Fixes: 3a687bef148d ("selftests: udp gso benchmark")
Also not a fix, but an extension.
>
> Example:
>
> #
This enhancement adds the '-a' option, which will count all CMSG
messages on the error queue and print a summary report.
Fixes: 3a687bef148d ("selftests: udp gso benchmark")
Example:
# ./udpgso_bench_tx -4uT -a -l5 -S 1472 -D 172.16.120.189
udp tx:492 MB/s 8354 calls/s 8354
13 matches
Mail list logo
