Hi, Happy new year! I like how this question comes up once every year, and how we throw the same old arguments at it. So in line with traditions, here is mine. :-)
The semantic difference is huge between the acknowledgement and a barrier: Acknowledgement means: Tell me when this and only this command has been processed (I absolutely don't care about other commands). Barrier means: Tell me when this and all the previous commands have been processed (including commands from controller applications I have never even heard about). I agree that assuming a very simple control processing (single-threaded, no out-of-order execution) on the switch, the only visible advantage would be saving an 8-byte message. However if processing is more complex, we can save both in control processing (no need to execute a real barrier), and in latency towards the requestor (no need to wait for other commands to be processed). Best Regards, Zoltan PS: If I recall correctly this request was filed as EXT-40 in ONF. > -----Original Message----- > From: openflow-discuss [mailto:openflow-discuss- > boun...@lists.stanford.edu] On Behalf Of Ben Pfaff > Sent: Sunday, January 03, 2016 3:13 AM > To: André Mantas > Cc: Justin Pettit; openflow-discuss@lists.stanford.edu; Stas Kozlov > Subject: Re: [openflow-discuss] openflow-discuss Digest, Vol 87, Issue 1 > > A barrier is only 8 bytes in each direction. An acknowledgment could only, at > most, save 8 bytes in one direction, which is hardly worth changing the basic > OpenFlow header format. > > On Sun, Jan 03, 2016 at 12:46:26AM +0000, André Mantas wrote: > > Thanks for all your answers, I was not sure where to ask this. > > > > The reason I ask this is because: > > > > a) I think it would be an useful feature that, I think. wouldn't "hurt > > anyone". > > > > b) I found this (old) conversation ( > > https://mailman.stanford.edu/pipermail/openflow-discuss/2009- > December/ > > 000547.html) > > where > > looks like a "barrier bit" was considered in earlier implementations, > > and I was curious to see if this was still a thing. > > > > Ben Pfaff <b...@ovn.org> escreveu no dia sábado, 2/01/2016 às 23:44: > > > > > The basic answer to Andre's question is that no, there are no plans. > > > > > > The right place to bring up a proposal for such a feature is the ONF > > > Open Datapath working group. > > > > > > On Sat, Jan 02, 2016 at 06:45:27AM +0300, Stas Kozlov wrote: > > > > That's right, but Andre does not want use Barrier. From my point > > > > of view the barrier messages are suitable in most cases, but I > > > > have a feeling > > > that > > > > one more cycle for control plane might be a burden for weak cpu. > > > > > > > > -- Stas > > > > On 2 Jan 2016 10:25 am, "Justin Pettit" <jpet...@gmail.com> wrote: > > > > > > > > > That's true, but to know that it completed without an error, you > > > > > can > > > send > > > > > a barrier message to know that the switch fully processed the > request. > > > > > > > > > > --Justin > > > > > > > > > > > > > > > On Jan 1, 2016, at 7:21 PM, Stas Kozlov <mancubu...@gmail.com> > wrote: > > > > > > > > > > Hi > > > > > > > > > > This duty should be done by controller. In case a flow can not > > > > > be > > > modified > > > > > or added a switch response with error message. In case message > > > > > was delivered tcp.ack will be generated according tcp flow. > > > > > Controller may handle both events. > > > > > > > > > > Faithfully yours > > > > > Stas > > > > > > > > > > > Message: 2 > > > > > > Date: Fri, 01 Jan 2016 17:46:52 +0000 > > > > > > From: Andr? Mantas <andremant...@gmail.com> > > > > > > To: openflow-discuss@lists.stanford.edu, > > > > > > "openflow-supp...@lists.stanford.edu" > > > > > > <openflow-supp...@lists.stanford.edu> > > > > > > Subject: [openflow-discuss] Positive ACK > > > > > > Message-ID: > > > > > > < > > > > > CAP-YG6oJhksvWc32YNt_D3yHgH-0O- > v2yRxMv5eo5H0OHwYA4g@mail.gmail.c > > > > > om> > > > > > > Content-Type: text/plain; charset="utf-8" > > > > > > > > > > > > Hello. > > > > > > > > > > > > Are there any plans to include the possibility of having > > > > > > per-message positive ACK in OpenFlow? (e.g., a flag in a flow > > > > > > mod that tells the > > > > > switch > > > > > > to send an ack when it receives/processes the flow mod message). > > > > > > > > > > > > I know this can be done with the use of barriers, but I think > > > > > > it > > > would be > > > > > > better to have some option to achieve this without using a > > > > > > barrier > > > per > > > > > > message. > > > > > > > > > > > > Thanks in advance. > > > > > > > > > > _______________________________________________ > > > > > openflow-discuss mailing list > > > > > openflow-discuss@lists.stanford.edu > > > > > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss > > > > > > > > > > > > > > > > > _______________________________________________ > > > > openflow-discuss mailing list > > > > openflow-discuss@lists.stanford.edu > > > > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss > > > > > > _______________________________________________ > > > openflow-discuss mailing list > > > openflow-discuss@lists.stanford.edu > > > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss > > > > _______________________________________________ > openflow-discuss mailing list > openflow-discuss@lists.stanford.edu > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss _______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
