ovs 对于 OFPT_SET_CONFIG消息的处理过程非常简单，其实就是通过TCP协议（或其它）交换了几个整型值，而且交换机不需要对此消息进行回复；只需要解析出消息体（struct ofp_switch_config）然后设置max miss len 即可。通过分析Floodlight发送它的过程 和 OVS
处理它的过程，我们可以对openflow协议有更好的理解。下面是代码流程：
对于这个消息的具体处理：
static enum ofperr
handle_set_config(struct ofconn *ofconn, const struct ofp_header *oh)
{
const struct ofp_switch_config *osc = ofpmsg_body(oh);
/* ignore the ofp_header to get the config struct */
struct ofproto *ofproto = ofconn_get_ofproto(ofconn);
/*get the OF SW abstraction, later will config it */
uint16_t flags = ntohs(osc->flags);
/*openflow use bigendian mode*/
if (ofconn_get_type(ofconn) != OFCONN_PRIMARY
|| ofconn_get_role(ofconn) != NX_ROLE_SLAVE) {
enum ofp_config_flags cur = ofproto->frag_handling;
enum ofp_config_flags next = flags & OFPC_FRAG_MASK;
assert((cur & OFPC_FRAG_MASK) == cur);
if (cur != next) {
if (ofproto->ofproto_class->set_frag_handling(ofproto, next)) {
ofproto->frag_handling = next;
} else {
VLOG_WARN_RL(&rl, "%s: unsupported fragment handling mode %s",
ofproto->name,
ofputil_frag_handling_to_string(next));
}
}
}
ofconn_set_invalid_ttl_to_controller(ofconn,
(flags & OFPC_INVALID_TTL_TO_CONTROLLER));
/* set the max miss length of the SW XXX*/
ofconn_set_miss_send_len(ofconn, ntohs(osc->miss_send_len));
return 0;
}
下面的这个结构体代表的是 OFPT_SET_CONFIG 消息的消息体。
/* Switch configuration. */
struct ofp_switch_config {
ovs_be16 flags; /* OFPC_* flags. */
ovs_be16 miss_send_len; /* Max bytes of new flow that datapath should
send to the controller. */
};
OFP_ASSERT(sizeof(struct ofp_switch_config) == 4);
Floodlight 是如何发送这个消息的呢？ 比如 设置在出现packetin时候把全部的包发送到 Controller。
OFSetConfig config = (OFSetConfig) factory
.getMessage(OFType.SET_CONFIG);
config.setMissSendLength((short) 0xffff)
.setLengthU(OFSwitchConfig.MINIMUM_LENGTH);
sw.write(config, null);
OVS 响应 OFPT_SET_CONFIG 过程分析