[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1461024417.10638.141.camel@edumazet-glaptop3.roam.corp.google.com>
Date: Mon, 18 Apr 2016 17:06:57 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: kafai@...com
Cc: netdev@...r.kernel.org, Eric Dumazet <edumazet@...gle.com>,
Neal Cardwell <ncardwell@...gle.com>,
Soheil Hassas Yeganeh <soheil.kdev@...il.com>,
Willem de Bruijn <willemb@...gle.com>,
Yuchung Cheng <ycheng@...gle.com>,
Kernel Team <kernel-team@...com>
Subject: Re: [RFC PATCH v2 net-next 4/7] tcp: Make use of MSG_EOR flag in
tcp_sendmsg
On Mon, 2016-04-18 at 16:43 -0700, kafai@...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 :(
Powered by blists - more mailing lists