From: Edgar Toernig <froese@gmx.de>
To: kambo@home.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: CONFIG_PACKET_MMAP help
Date: Thu, 19 Apr 2001 06:41:20 +0200 [thread overview]
Message-ID: <3ADE6C70.5A12D80A@gmx.de> (raw)
In-Reply-To: <10336.010418@home.com>
Hi,
kambo@home.com wrote:
>
> 1. for tp_frame_size, I dont want to truncate any data on ethernet, I
> need 1514 bytes, is this the best way to do it and not waste space?
>
> static const int TURBO_FRAME_SIZE=
> TPACKET_ALIGN(TPACKET_ALIGN(sizeof(tpacket_hdr)) +
> TPACKET_ALIGN(sizeof(struct sockaddr_ll)+ETH_HLEN) + 1500);
Looks OK. Maybe instead of ETH_HLEN min(ETH_HLEN,16)? The framesize
calculation is really strange...
> 2. what is tp_block_nr for? I dont understand it, I just set it to 1
> and make tp_block_size big enough for all the frames I need, so its
> just one contiguous space, all I need is about a megabyte I think.
Better go the other way around - set tb_block_size to PAGE_SIZE and
tb_block_nr appropriate. tb_block_size is the contiguous physical memory
the kernel tries to allocate. Anything above PAGE_SIZE is likely to fail.
For you that would mean only 2 packets per 4k-page. You could try to
start with bigger (power of 2) block sizes and go down to smaller ones if
it fails (ENOMEM). [1]. Btw, there's in implicit limit on tb_block_nr.
The vector to manage the blocks is kmalloc'ed and may not be larger than
128kb giving max 32768 blocks. Hmm... moment... seems there's a similar
limit for tp_frame_nr (max 32768 frames). I'm pretty sure _that_ limit
was not there when I worked with this during 2.3. Not so nice on gigabit
ethernet :-(
> 3. is this the general approach for the api?
> [...]
Looks OK too.
> if (tp->status == 0) poll() for pollin on the socket /* is there a
> race here? */
No race.
> 4. what does the copy threshold setsockopt tuning accomplish? doesnt it always
> have to copy anyway, to the mmaped area?
I haven't used it myself. Reading the sources it does something different.
Afaics when active if there's a packet that has been truncated by the
framesize it is additionally stored in the socket's receive queue to be
fetched by a normal read/recv. It notifies you about this by setting
the TP_STATUS_COPY bit. So it seems to mean: copy to socket if threshold
(framesize) exceeded.
Ciao, ET.
[1] The PACKET_RX_RING sockopt accepts all block sizes that are a multiple
of PAGE_SIZE but always allocates a power of 2 size chunk. So using non
power of 2 sizes will waste locked kernel memory.
next prev parent reply other threads:[~2001-04-19 20:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-18 12:04 CONFIG_PACKET_MMAP help kambo
2001-04-19 4:41 ` Edgar Toernig [this message]
2001-04-20 16:03 ` kuznet
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=3ADE6C70.5A12D80A@gmx.de \
--to=froese@gmx.de \
--cc=kambo@home.com \
--cc=linux-kernel@vger.kernel.org \
/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.