From: 'Marcelo Ricardo Leitner' > Sent: 28 January 2016 20:56 ... > > > > I did wonder whether the queued data could actually be picked up > > > > be a Heartbeat chunk that is probing a different remote address > > > > (which would be bad news). > > > > > > I don't follow. You mean if a heartbeat may get stuck in queue or if > > > sending of a heartbeat can end up carrying additional data by accident? > > > > My suspicion was that the heartbeat would carry the queued data. > > I'm afraid I'm still not following, sorry. You mean that this GSO patch > would cause the heartbeat to carry queued data? If yes, no, because for > SCTP side of it it mangles the packet size and make it look bigger > instead of handling multiple packets. It will then break this large > sctp_packet into several sk_buff and glue them together as if they were > GROed, allowing skb_segment to just split them back. The reason the > sctp_packet is generated, being it due to user data or control chunks > like heartbeats, is not modified. I'm thinking of the code prior to your GSO changes. IIRC with nagle enabled data chunks are built and put onto an internal queue to be sent later (with nagle disabled they are sent at the end of the tx processing provided (IIRC) there is window). Any message that forces a transmit picks up the queued data - and I think this might include heartbeats.... I didn't read the code closely enough to find out whether this was true or not. 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
