From: Carsten Andrich <carsten.andrich-hs6bpBdVsEZfm0AUMx9V0g@public.gmane.org>
To: Willem de Bruijn <willemb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Cc: Daniel Borkmann
<dborkman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
"Michael Kerrisk (man-pages)"
<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>,
jbrouer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
Subject: Re: Improving PACKET_{RX,TX}_RING documentation
Date: Mon, 26 May 2014 12:49:30 +0200 [thread overview]
Message-ID: <f892062de194e1414fec56672a423eea@localhost> (raw)
In-Reply-To: <CA+FuTSfpORKtm_kdG+CycoPiq+Gxf58=nXqKApFEmR+xZs69_g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Willem de Bruijn schrieb:
>>> I would describe such points in a positive manner (optimization) as
>>> opposed to a negative (inferior performance).
>>
>> Using positive wording is always a good idea, but packet_mmap.txt
>> already tricked me into believing that PACKET_TX_RING should be faster
>> than plain sendto(). The user should be allowed to make an informed
>> decision,
>
> Indeed. The document should not contain any simple statements about
> one option being faster than another, because this invariably depends on
> workload details (packet size, rate, threading, ...).
>
> Instead, it should just explain the technical details and their implications:
> an mmapped ring reduces the number of system calls, as does
> recvmmsg/sendmmsg. It does not necessarily reduce the number of
> data copies (a common misconception). Etcetera.
>
>> which requires the manpage to tell the (ugly) truth that
>> sendto() currently outperforms TX_RING.
>
> I would not make such statements either way, then.
You're right. I'll just a note regarding the necessity of careful
performance considerations/evaluations :)
Maybe, eventually, some of Jesper's findings regarding *_RING
performance should end up in packet_mmap.txt.
>>>> Absolutely, perhaps explaining differences from TPACKET_V1 -> V3 API and the
>>>> like.
>>>
>>> That would be very interesting. The packet -> block batching mechanism
>>> likely was tested with small packet performance, but may have little
>>> benefit for larger packets. A discussion of the trade offs from a user
>>> point of view would be very interesting.
>>
>> Actually I intended to deal only with TPACKET_V2 for now, since it is
>> simpler than TPACKET_V3 and can be use for RX and TX. TPACKET_V3 can be
>> added later on or could remain in packet_mmap.txt.
>
> Sure, let's leave that.
>
> Your plan sounds good to me, Carsten.
Okay, it might take me a few weeks to come up with a first draft.
Cheers,
Carsten
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2014-05-26 10:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-17 13:13 Improving PACKET_{RX,TX}_RING documentation Carsten Andrich
[not found] ` <1400332406.2395.35.camel-FQO4gtnRtnzkVFMGpb/cPg@public.gmane.org>
2014-05-19 4:54 ` Michael Kerrisk (man-pages)
[not found] ` <53798E97.1000505-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-05-19 10:14 ` Daniel Borkmann
[not found] ` <5379D9A2.1070008-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-05-19 15:05 ` Willem de Bruijn
[not found] ` <CA+FuTSeWh_iQGqc-4usL7vr28OrkHTnBvHvXvVO=LcGsNRgtMA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-19 16:01 ` Daniel Borkmann
2014-05-22 12:22 ` Carsten Andrich
2014-05-22 13:13 ` Michael Kerrisk (man-pages)
2014-05-22 13:37 ` Jesper Dangaard Brouer
2014-05-22 14:51 ` Willem de Bruijn
[not found] ` <CA+FuTSfpORKtm_kdG+CycoPiq+Gxf58=nXqKApFEmR+xZs69_g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-26 10:49 ` Carsten Andrich [this message]
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=f892062de194e1414fec56672a423eea@localhost \
--to=carsten.andrich-hs6bpbdvsezfm0aumx9v0g@public.gmane.org \
--cc=dborkman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=jbrouer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org \
--cc=willemb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.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.