From: Daniel Borkmann <danborkmann@iogearbox.net>
To: Ronny Meeus <ronny.meeus@gmail.com>
Cc: netdev <netdev@vger.kernel.org>
Subject: Re: mmap RX_RING socket issue 32b application running on 64b kernel.
Date: Wed, 7 Nov 2012 19:26:24 +0100 [thread overview]
Message-ID: <CAD6jFURNbY4BkcUeykrkO2PU17+G_mOD7Dw3KrEx0BAaOpqiSA@mail.gmail.com> (raw)
In-Reply-To: <CAMJ=MEfeMDC3H2bjKz9XA4072Vo7U17108N4bK77q0GvUEF09w@mail.gmail.com>
On Wed, Nov 7, 2012 at 6:58 PM, Ronny Meeus <ronny.meeus@gmail.com> wrote:
> I have an application using raw Ethernet sockets in combination with
> the mmaped RX_RING.
> The application is running on a Cavium MIPS processor (64bit) and the
> application code is compiled with the N32 ABI.
>
> Since the ring buffer is shared between the Linux kernel and the
> application there is a conflict in the way the data is presented.
> Each buffer in the ring has a header that has following structure:
> (File http://lxr.free-electrons.com/source/include/linux/if_packet.h )
> 103 struct tpacket_hdr {
> 104 unsigned long tp_status;
> 105 unsigned int tp_len;
> 106 unsigned int tp_snaplen;
> 107 unsigned short tp_mac;
> 108 unsigned short tp_net;
> 109 unsigned int tp_sec;
> 110 unsigned int tp_usec;
> 111 };
>
> The status field indicates that the buffer belongs to the kernel or to
> the user. Note that an unsigned long is used to represent the field.
> In the kernel the long is 64 bit while in application space the long
> is only 32bit, so the bits do not match.
>
> After adapting the code to take this into account my program works well.
> In my test program I have defined a new struct where I change the
> “unsigned long” into an “unsigned long long”:
>
> struct tpacket_hdr_64 {
> unsigned long long tp_status;
> unsigned int tp_len;
> unsigned int tp_snaplen;
> unsigned short tp_mac;
> unsigned short tp_net;
> unsigned int tp_sec;
> unsigned int tp_usec;
> };
>
> In my opinion this is not a correct solution. It should be solved
> somewhere in the include file I used so that it is transparent for the
> application.
> Please comment.
Have you tried to use packet_mmap with TPACKET version 2 [1]?
In my understanding, it was introduced because of such issues that you
described.
[1] E.g. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=bbd6ef87c544d88c30e4b762b1b61ef267a7d279
next prev parent reply other threads:[~2012-11-07 18:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-07 17:58 mmap RX_RING socket issue 32b application running on 64b kernel Ronny Meeus
2012-11-07 18:26 ` Daniel Borkmann [this message]
2012-11-07 18:54 ` Ronny Meeus
2012-11-08 7:32 ` Ronny Meeus
2012-11-08 8:00 ` Daniel Borkmann
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=CAD6jFURNbY4BkcUeykrkO2PU17+G_mOD7Dw3KrEx0BAaOpqiSA@mail.gmail.com \
--to=danborkmann@iogearbox.net \
--cc=netdev@vger.kernel.org \
--cc=ronny.meeus@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox