From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
To: Johann Baudy <johaahn@gmail.com>
Cc: David Miller <davem@davemloft.net>, netdev@vger.kernel.org
Subject: Re: Packet mmap: TX RING and zero copy
Date: Wed, 3 Sep 2008 20:43:51 +0400 [thread overview]
Message-ID: <20080903164346.GA6729@2ka.mipt.ru> (raw)
In-Reply-To: <7e0dd21a0809030858h7fdc454dj33acc6be25a0aab@mail.gmail.com>
Hi Johann.
On Wed, Sep 03, 2008 at 05:58:50PM +0200, Johann Baudy (johaahn@gmail.com) wrote:
> > What is the bus width and is there burst mode support?
> > Not to point to the error in the speed calculation, just out of curiosity :)
> > Always liked such tiny systems...
>
> 32 bits with burst support. This is a PPC 405 embedded into Xilinx V4
> FPGA . (PLB bus)
So small PLB? Not OPB? Weird hardware :)
But nevertheless at most 400 MB/s with 100mhz, so looks like either
there is no burst mode or weird NIC hardware (or something else :)
I used to easily saturate 100mbit channel with 405gp(r) and emac driver,
which are better numbers than what you have with gige and sockets...
Actually even 405gp had much wider plb, so this could be an issue.
Likley your project will just dma data from some sensor to the
preallocated buffer, you will add headers and send the data, so very
small memory bus speed will not allow to use sockets and thus TCP.
Having splice-friendly setup is possible, but I think raw socket
approach is simpler for you.
> > But why sendfile/splice does not work the same?
> > It is (supposed to be) a zero-copy sending interface, which should be even
> > more optimal, than your ring buffer approach, since uses just single
> > syscall and no initialization of the data (well, there is page
> > population and so on, but if file is in the ramdisk, it is effectively
> > zero overhead). Can you run oprofile during sendfile() data transfer or
> > describe behaviour (i.e. CPU usage and tcpdump).
>
> I've never used oprofile before. I will get more logs and let you know.
> Just a question: I don't want to use TCP for final application.
> Is it expected that the kernel execute packet_sendmsg() when using
> packet socket with splice()? (because this function is doing a memcpy
> from a buffer to a socket buffer).
No, it will use sendpage() if hardware and driver support scatter/gather
and checksumm ofloading. Since you say they do, then there should be no
copies at all.
> Or is there a dedicated path for splicing? or maybe only in TCP read
> (I can see that splice_read operator is redefined with
> tcp_splice_read())?
It will endup with generic_splice_sendpage() and pipe_to_sendpage().
> And I've also faced some issues with the size of packet (it seems to
> be limited to page size). It is really important for me to send large
> packet. I've just decreased the packet size of pktgen script from 7200
> to 4096 and the bitrate has fallen from 85Mbytes/s to 50Mbytes/s.
> I understand that this is not a problem with TCP when sending a file,
> we don't really care about accuracy of the packet size.
> Do you know if there is way to adjust the size ?
What do you mean by packet size? MTU/MSS? In pktgen it means size of the
allocated skb, so it will be eventually split into smaller chunks and the
bigger size you have, the less allocations will be performed. Actually
the fact, that 7200 works at all, is a bit surprising: your small
machine has lots of ram and is effectively unused during tests (i.e. no
other allocations). Changing it do 4k should not decrease performance at
all... Do you have jumbo frames enabled?
--
Evgeniy Polyakov
next prev parent reply other threads:[~2008-09-03 16:44 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-02 18:27 Packet mmap: TX RING and zero copy Johann Baudy
2008-09-02 19:46 ` Evgeniy Polyakov
2008-09-03 7:56 ` Johann Baudy
2008-09-03 10:38 ` Johann Baudy
2008-09-03 11:06 ` David Miller
2008-09-03 13:05 ` Johann Baudy
2008-09-03 13:27 ` Evgeniy Polyakov
2008-09-03 14:57 ` Christoph Lameter
2008-09-03 15:00 ` Johann Baudy
2008-09-03 15:13 ` Evgeniy Polyakov
2008-09-03 15:58 ` Johann Baudy
2008-09-03 16:43 ` Evgeniy Polyakov [this message]
2008-09-03 20:30 ` Johann Baudy
2008-09-03 22:03 ` Evgeniy Polyakov
2008-09-04 14:44 ` Johann Baudy
2008-09-05 7:17 ` Evgeniy Polyakov
[not found] ` <7e0dd21a0809050216r65b8f08fm1ad0630790a13a54@mail.gmail.com>
2008-09-05 9:17 ` Fwd: " Johann Baudy
2008-09-05 11:31 ` Evgeniy Polyakov
2008-09-05 12:44 ` Johann Baudy
2008-09-05 13:16 ` Evgeniy Polyakov
2008-09-05 13:29 ` Johann Baudy
2008-09-05 13:37 ` Evgeniy Polyakov
2008-09-05 13:55 ` Johann Baudy
2008-09-05 14:19 ` Evgeniy Polyakov
2008-09-05 14:45 ` Johann Baudy
2008-09-05 14:59 ` Evgeniy Polyakov
2008-09-05 15:30 ` Johann Baudy
2008-09-05 15:38 ` Evgeniy Polyakov
2008-09-05 16:01 ` Johann Baudy
2008-09-05 16:34 ` Evgeniy Polyakov
2008-09-08 10:21 ` Johann Baudy
2008-09-08 11:26 ` Evgeniy Polyakov
2008-09-08 13:01 ` Johann Baudy
2008-09-08 15:28 ` Evgeniy Polyakov
2008-09-08 15:38 ` Evgeniy Polyakov
2008-09-09 23:11 ` Johann Baudy
2008-09-10 6:09 ` Evgeniy Polyakov
2008-09-05 10:28 ` Robert Iakobashvili
2008-09-05 13:06 ` Johann Baudy
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=20080903164346.GA6729@2ka.mipt.ru \
--to=johnpol@2ka.mipt.ru \
--cc=davem@davemloft.net \
--cc=johaahn@gmail.com \
--cc=netdev@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).