[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD6jFURNbY4BkcUeykrkO2PU17+G_mOD7Dw3KrEx0BAaOpqiSA@mail.gmail.com>
Date: Wed, 7 Nov 2012 19:26:24 +0100
From: Daniel Borkmann <danborkmann@...earbox.net>
To: Ronny Meeus <ronny.meeus@...il.com>
Cc: netdev <netdev@...r.kernel.org>
Subject: Re: mmap RX_RING socket issue 32b application running on 64b kernel.
On Wed, Nov 7, 2012 at 6:58 PM, Ronny Meeus <ronny.meeus@...il.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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists