All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: kafai@fb.com
Cc: netdev@vger.kernel.org, Eric Dumazet <edumazet@google.com>,
	Neal Cardwell <ncardwell@google.com>,
	Soheil Hassas Yeganeh <soheil.kdev@gmail.com>,
	Willem de Bruijn <willemb@google.com>,
	Yuchung Cheng <ycheng@google.com>,
	Kernel Team <kernel-team@fb.com>
Subject: Re: [RFC PATCH v2 net-next 4/7] tcp: Make use of MSG_EOR flag in tcp_sendmsg
Date: Mon, 18 Apr 2016 17:06:57 -0700	[thread overview]
Message-ID: <1461024417.10638.141.camel@edumazet-glaptop3.roam.corp.google.com> (raw)
In-Reply-To: <20160418234202.GA27948@kafai-mba.local>

On Mon, 2016-04-18 at 16:43 -0700, kafai@fb.com wrote:

> >
> > netperf could then get an option to set this MSG_EOR ;)
> Not sure how it is related.  Can you share how netperf can
> benefit from MSG_EOR in TCP tests without any of the
> SOF_TIMESTAMPING_TX_RECORD_MASK.

Simply setting MSG_EOR would be orthogonal to other timestamping stuff.

Maybe the application does not _want_ to be notified when skb is sent or
acknowledged, but would like some kind of "tcpdump awareness" or
something about burst control, who knows...

It should only be a request from user space to ask TCP to not aggregate
stuff on future sendpage()/sendmsg() on the skb carrying this new flag.

We already have other flags to ask for timestamping stuff, and they
could be used at the same time.

If the stack needs to be changed to properly fragment skb (or
aggregating them at retransmit), this is a separate concern.

Note that you do not need to automatically assert MSG_BOR (Begin of
Request) : MSG_EOR should really control the fact that last byte sent
marks the skb as being a non candidate for aggregation.

This would keep tcp_sendmsg() reasonnably fast.
Your tcp_sendmsg_noappend() is quite expensive :(

  reply	other threads:[~2016-04-19  0:07 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-18 22:46 [RFC PATCH v2 net-next 0/7] tcp: Make use of MSG_EOR in tcp_sendmsg Martin KaFai Lau
2016-04-18 22:46 ` [RFC PATCH v2 net-next 1/7] tcp: Carry txstamp_ack in tcp_fragment_tstamp Martin KaFai Lau
2016-04-19  5:21   ` Soheil Hassas Yeganeh
2016-04-19 17:39     ` Martin KaFai Lau
2016-04-19 17:44       ` Soheil Hassas Yeganeh
2016-04-18 22:46 ` [RFC PATCH v2 net-next 2/7] tcp: Merge tx_flags/tskey/txstamp_ack in tcp_collapse_retrans Martin KaFai Lau
2016-04-19  5:32   ` Soheil Hassas Yeganeh
2016-04-19 17:28     ` Martin KaFai Lau
2016-04-19 17:35       ` Eric Dumazet
2016-04-19 18:18         ` Martin KaFai Lau
2016-04-19 18:24           ` Soheil Hassas Yeganeh
2016-04-21 20:25             ` Willem de Bruijn
2016-04-19 17:42       ` Soheil Hassas Yeganeh
2016-04-18 22:46 ` [RFC PATCH v2 net-next 3/7] tcp: Merge tx_flags/tskey/txstamp_ack in tcp_shifted_skb Martin KaFai Lau
2016-04-19  5:38   ` Soheil Hassas Yeganeh
2016-04-18 22:46 ` [RFC PATCH v2 net-next 4/7] tcp: Make use of MSG_EOR flag in tcp_sendmsg Martin KaFai Lau
2016-04-18 23:18   ` Eric Dumazet
2016-04-18 23:43     ` kafai
2016-04-19  0:06       ` Eric Dumazet [this message]
2016-04-19  2:27         ` Martin KaFai Lau
2016-04-19  2:50           ` Eric Dumazet
2016-04-19  3:18             ` Martin KaFai Lau
2016-04-19  3:25               ` Eric Dumazet
2016-04-19  9:47     ` David Laight
2016-04-19 12:19       ` Eric Dumazet
2016-04-18 22:46 ` [RFC PATCH v2 net-next 5/7] tcp: Make use of MSG_EOR in tcp_sendpage Martin KaFai Lau
2016-04-18 22:46 ` [RFC PATCH v2 net-next 6/7] tcp: Carry eor_info in tcp_fragment_tstamp() and tcp_skb_collapse_tstamp() Martin KaFai Lau
2016-04-18 22:46 ` [RFC PATCH v2 net-next 7/7] tcp: Avoid losing eor_info when collapsing skbs Martin KaFai Lau

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=1461024417.10638.141.camel@edumazet-glaptop3.roam.corp.google.com \
    --to=eric.dumazet@gmail.com \
    --cc=edumazet@google.com \
    --cc=kafai@fb.com \
    --cc=kernel-team@fb.com \
    --cc=ncardwell@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=soheil.kdev@gmail.com \
    --cc=willemb@google.com \
    --cc=ycheng@google.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 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.