lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6DCFE70E65@AcuExch.aculab.com>
Date:   Mon, 27 Feb 2017 10:48:30 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Xin Long' <lucien.xin@...il.com>
CC:     network dev <netdev@...r.kernel.org>,
        "linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>,
        Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
        Neil Horman <nhorman@...driver.com>,
        "Vlad Yasevich" <vyasevich@...il.com>,
        "davem@...emloft.net" <davem@...emloft.net>
Subject: RE: [PATCH net-next 2/2] sctp: add support for MSG_MORE

From: Xin Long
> Sent: 27 February 2017 04:49
...
> > what I'm worried about is if the msg_more is saved in assoc:
> >      chk4[clear] -> chk3 [clear] -> chk2 [clear] -> chk1 [clear]
> > then when you send a small chkA with MSG_MORE,
> > the queue will be like:
> >      chkA [set] -> chk4[set] -> chk3 [set] -> chk2 [set] -> chk1 [set]
> > because msg_more is saved in assoc, every chunk can look at it.
> > chk1 - chk4 are big enough to be packed into a packet, they were
> > not sent last time because a lot of chunks are in the retransmit
> > queue.

Or just waiting for transmit window space.

> > But now even if retransmit queue is null, chk1-chk4 are still blocked.
> >
> > can you accept that chkA may block the old chunks ?
> even also block the retransmit chunks.

I don't see a problem, the application is about to send another chunk.
It is likely that the whole lot will go in one packet.

If the connection is flow controlled off (even if due to packet loss)
the minor delay waiting for the application won't make any real difference.
Indeed reducing the number of ethernet frames may help increase
overall throughput.

Does a request for chunks to be retransmitted force a response packet be built?
If so it will pick up all the queued data chunks regardless of any saved
MSG_MORE bits.

	David


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ