From: Alexander Stein <alexander.stein@systec-electronic.com>
To: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: linux-can@vger.kernel.org,
"Daniel Krüger" <daniel.krueger@systec-electronic.com>
Subject: Re: wrong CAN frame order in network layer due to SMP?
Date: Wed, 30 Nov 2016 08:23:41 +0100 [thread overview]
Message-ID: <2577568.MH2UfL0Ils@ws-stein> (raw)
In-Reply-To: <45353231-7efa-7feb-b52d-569a88317cdf@hartkopp.net>
On Tuesday 29 November 2016 20:48:09, Oliver Hartkopp wrote:
> Hello Alexander,
>
> On 11/29/2016 11:30 AM, Alexander Stein wrote:
> > On Monday 28 November 2016 21:36:09, Oliver Hartkopp wrote:
> >> IIRC Wireshark puts the PF_PACKET socket into some special 'tpacket'
> >> mode and I don't know whether this has any impact on frame ordering.
> >>
> >> At least you may check for:
> >> https://github.com/linux-can/can-tests/blob/master/tst-packet.c
> >>
> >> ... if there's a difference between PF_PACKET and PF_CAN with your OOO
> >> setup.
> >
> > Nope, apparently there is no difference. Got similar results.
> >
> > On a side note: I captured an 30 seconds iperf3 run with wireshark 2.2.2
> > using the "ASIX Electronics Corp. AX88179 Gigabit Ethernet" adapter
> > (driver: ax88179_178a).
> > AFAICS this driver (well usbnet in the end) doesn't use NAPI either and
> > therefore unsurprisingly I got OOO of TCP frames.
> > IMHO this is not acceptable at all.
>
> Did you have a TCP socket on the receiving host as endpoint for your
> communication?
Yep. straight iperf3 run. Here is a snippet from the wireshark capture:
82102 0.759823467 192.168.8.7 192.168.8.128 TCP 34564→5201 [ACK] Seq=79054502 Ack=1 Win=29312 Len=1448 TSval=409657 TSecr=411321992
82103 0.759823627 192.168.8.7 192.168.8.128 TCP 34564→5201 [ACK] Seq=79055950 Ack=1 Win=29312 Len=1448 TSval=409657 TSecr=411321992
82104 0.759831475 192.168.8.128 192.168.8.7 TCP 5201→34564 [ACK] Seq=1 Ack=79057398 Win=677760 Len=0 TSval=411321994 TSecr=409657
82105 0.759823818 192.168.8.7 192.168.8.128 TCP 34564→5201 [ACK] Seq=79057398 Ack=1 Win=29312 Len=1448 TSval=409657 TSecr=411321992
82106 0.759823894 192.168.8.7 192.168.8.128 TCP 34564→5201 [ACK] Seq=79058846 Ack=1 Win=29312 Len=1448 TSval=409657 TSecr=411321992
82107 *REF* 192.168.8.128 192.168.8.7 TCP 5201→34564 [ACK] Seq=1 Ack=79060294 Win=677760 Len=0 TSval=411321994 TSecr=409657
82108 -0.000012137 192.168.8.7 192.168.8.128 TCP [TCP Out-Of-Order] 34564→5201 [ACK] Seq=78738838 Ack=1 Win=29312 Len=1448 TSval=409657 TSecr=411321992
82109 0.000003981 192.168.8.128 192.168.8.7 TCP [TCP Dup ACK 82107#1] 5201→34564 [ACK] Seq=1 Ack=79060294 Win=677760 Len=0 TSval=411321994 TSecr=409657 SLE=78738838 SRE=78740286
82110 -0.000011999 192.168.8.7 192.168.8.128 TCP [TCP Out-Of-Order] 34564→5201 [ACK] Seq=78740286 Ack=1 Win=29312 Len=1448 TSval=409657 TSecr=411321992
82111 0.000007932 192.168.8.128 192.168.8.7 TCP [TCP Dup ACK 82107#2] 5201→34564 [ACK] Seq=1 Ack=79060294 Win=677760 Len=0 TSval=411321994 TSecr=409657 SLE=78740286 SRE=78741734
82112 0.000066782 192.168.8.7 192.168.8.128 TCP [TCP Out-Of-Order] 34564→5201 [ACK] Seq=78741734 Ack=1 Win=29312 Len=1448 TSval=409657 TSecr=411321992
82113 0.000069480 192.168.8.128 192.168.8.7 TCP [TCP Dup ACK 82107#3] 5201→34564 [ACK] Seq=1 Ack=79060294 Win=677760 Len=0 TSval=411321995 TSecr=409657 SLE=78741734 SRE=78743182
82114 0.000066949 192.168.8.7 192.168.8.128 TCP [TCP Out-Of-Order] 34564→5201 [ACK] Seq=78743182 Ack=1 Win=29312 Len=1448 TSval=409657 TSecr=411321992
82115 0.000071730 192.168.8.128 192.168.8.7 TCP [TCP Dup ACK 82107#4] 5201→34564 [ACK] Seq=1 Ack=79060294 Win=677760 Len=0 TSval=411321995 TSecr=409657 SLE=78743182 SRE=78744630
192.168.8.128 is the receiver
192.168.8.128 is the sender
direct connection without any switch
TCP is used
I put a time ref at packet 82107 so you can see more easily the negative relative timestamp of some following packets.
> Maybe this could be named a 'general regression' then. And when this is
> fixed our problem hopefully gets fixed too ;-)
I guess the network guys will also say: Use NAPI. IMHO there shouldn't be an API which allows OOO in the first place.
Best regards,
Alexander
--
Dipl.-Inf. Alexander Stein
SYS TEC electronic GmbH
alexander.stein@systec-electronic.com
Legal and Commercial Address:
Am Windrad 2
08468 Heinsdorfergrund
Germany
Office: +49 (0) 3765 38600-0
Fax: +49 (0) 3765 38600-4100
Managing Directors:
Director Technology/CEO: Dipl.-Phys. Siegmar Schmidt;
Director Commercial Affairs/COO: Dipl. Ing. (FH) Armin von Collrepp
Commercial Registry:
Amtsgericht Chemnitz, HRB 28082; USt.-Id Nr. DE150534010
prev parent reply other threads:[~2016-11-30 7:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-24 15:49 wrong CAN frame order in network layer due to SMP? Alexander Stein
2016-11-25 11:46 ` Oliver Hartkopp
2016-11-28 9:01 ` Alexander Stein
2016-11-28 20:36 ` Oliver Hartkopp
2016-11-29 10:30 ` Alexander Stein
2016-11-29 19:48 ` Oliver Hartkopp
2016-11-30 7:23 ` Alexander Stein [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2577568.MH2UfL0Ils@ws-stein \
--to=alexander.stein@systec-electronic.com \
--cc=daniel.krueger@systec-electronic.com \
--cc=linux-can@vger.kernel.org \
--cc=socketcan@hartkopp.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.