sendfile(2) SF_NOPUSH flag proposal

[Igor Sysoev]

On Tue, 27 May 2003, Peter Jeremy wrote:

> On Tue, May 27, 2003 at 02:49:35PM +0400, Igor Sysoev wrote:
> >Actually 6 vs. 6 for this 8K file. But I said about another thing.
> >Let's see 48K file and 250 bytes header. sendfile() usually sends
> >it as 4K or 8K hunks so there are 48/8 * 6 + 1 (header) = 37 packets.
> >But (48K + 250) / 1460 = 33 * 1460 + 1270 i.e. 34 packets.
> >It's 8% decrease of data packets. Add here the possible retransmitions.
> 
> Why is the number of data packets so important?  If you repeat the
> calculation considering bytes across the wire (assuming Ethernet),
> then the saving is closer to 0.4% - this is in the noise.

When there's the simple way to avoid the partially filled packets
I do not see any reason not to use it.

> For that matter, have you considered the impact of Path MTU discovery?

What impact ?

> I think possible retransmissions are irrelevant here.  If your packet
> loss is anything above negligible then you have other problems.  If
> the retransmission is caused by transmission noise, then the smaller
> packets are less likely to get hit.  And the sender is likely to
> retransmit a full packet rather than the small packet originally sent.
> 
> >> Really: it's in the noise.  Unless you are paying by packet
> >> count, you probably shouldn't care.
> >
> >So do you consider that IP fragmentation is the good thing ?
> 
> "IP fragmentation" normally refers to a single IP packet being
> split up into multiple smaller packets by a router.  It has nothing
> to do with the topic under discussion.  If anything, transmitting

I know what is IP fragmentation. But in terms of the packet overhead
they are similar to not full packets.

> smaller IP packets reduces the likelihood that an intervening router
> will need to fragment packets - so your patch actually increases
> the probability of IP fragmentation.

Yes, I understand it.


Igor Sysoev
http://sysoev.ru/en/