From: Marcelo Ricardo Leitner > Sent: 16 August 2016 18:25 ... > > That doesn't seem a good idea. > > You don't want to abort the association if there is a transient > > memory allocation failure. > > You also can't drop data chunks. > > From a system-wise POV, this behavior - to free the new asoc in case of > transient memory allocation failure - doesn't seem bad to me. > That's what will have to happen if any allocation before it failed and > also it helps the system to reduce the stress a little bit. I don't see > any inconsistency/problems here because we are not dropping a single > random chunk but instead we are actually refusing to initialize a new > asoc in such conditions. Failing a new association should be ok, whether purists will like connect() failing ENOMEM is another matter. > Nevertheless, I agree that letting the application see ENOMEM errors when > the data actually got queued and is being fully handled, as in, it will > be retransmitted later, is not be wise, as the application probably > won't be able to distinguish from ENOMEMs that it should retry or not. I think an application would be justified in thinking that an ENOMEM return meant that the system call had no effect. For send() even ENOMEM is really wrong, it should be treated as 'flow control' and either block or return EAGAIN/EWOULDBLOCK. Getting POLLOUT set is left as an exercise to the reader :-) ... > Well, it may be, but we are trying to improve it. Please continue > discussing the fixes so we can keep improving it. :) Indeed, we have customers who use sctp (for M3UA). We don't do anything 'complicated', but do end up sending a lot of short data chunks. David -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
