Netdev List
 help / color / mirror / Atom feed
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

  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