Version: 1
-Previous: 5a7a492422d6a9fdb5afbc3c6ef62a522dae47e2
-Head: de52ebed743b5b7ef300586b4f7cb875dfd77792
+Previous: c34964a844f8584915185d0077d6c447890471d6
+Head: b59c9659e314dcdb07fd8bdd4314c7f4571e9730
Applied:
lazy-init: f306625fe8cafef70e3d60fddd7e685bc0696047
rs-inline: de52ebed743b5b7ef300586b4f7cb875dfd77792
+ rs-ctrl: b59c9659e314dcdb07fd8bdd4314c7f4571e9730
Unapplied:
inline0: f187212a28d15ba2fed172e2428c4fb777cf8a09
old-af-ib: aaa0d9ca917c8c361a978e5a116963c2cceac5ba
--- /dev/null
+Bottom: 55ffa8849cf2c6e18856f1e9d278573786bcb7f0
+Top: 55ffa8849cf2c6e18856f1e9d278573786bcb7f0
+Author: Sean Hefty <sean.hefty@intel.com>
+Date: 2014-04-16 22:33:38 -0700
+
+rsocket: Modify when control messages are available
+
+Rsockets currently tracks how many control messages (i.e.
+entries in the send queue) that are available using a
+single ctrl_avail counter. Seems simple enough.
+
+However, control messages currently require the use of
+inline data. In order to support control messages that
+do not use inline data, we need to associate each
+control message with a specific data buffer. This will
+become easier to manage if we modify how we track when
+control messages are available.
+
+We replace the single ctrl_avail counter with two new
+counters. The new counters conceptually treat control
+messages as if each message had its own sequence number.
+The sequence number will then be able to correspond to
+a specific data buffer in a follow up patch.
+
+ctrl_seqno will be used to indicate the current control
+message being sent. ctrl_max_seqno will track the
+highest control message that may be sent.
+
+A side effect of this change is that we will be able to
+see how many control messages have been sent.
+
+
+---
+
+