[ovs-dev] [packet_in v2 18/18] openflow: New Nicira Extended PACKET_IN format.
Ethan Jackson
ethan at nicira.com
Tue Jan 10 03:02:33 UTC 2012
kj> I don't think that we need to pad nxt_set_packet_in_format to a
> multiple of 8 bytes.
I thought this was the convention, but apparently nxt_set_flow_format
doesn't pad to 8 bytes. So I suppose I'll be consistent with that.
> In ofputil_decode_packet_in(), I think that the following fails to
> byte-swap in_port or the registers and their masks:
>> + pin->fmd.in_port = rule.flow.in_port;
>> +
>> + pin->fmd.tun_id = rule.flow.tun_id;
>> + pin->fmd.tun_id_mask = rule.wc.tun_id_mask;
>> +
>> + memcpy(pin->fmd.regs, rule.flow.regs, sizeof pin->fmd.regs);
>> + memcpy(pin->fmd.reg_masks, rule.wc.reg_masks,
>> + sizeof pin->fmd.reg_masks);
I'm sorry I don't think I understand this comment. Are you talking
about byte order? Or perhaps you are saying that we should be applying
the mask to the fmd field? I must be missing something obvious.
I'll send out an incremental shortly.
Ethan
> In ovs-ofctl, I think it would be better to follow the pattern that we
> have for e.g. "dump-flows", where by default we try to use the Nicira
> extension but fall back to the OpenFlow 1.0 version if it is
> unavailable, and allow command-line options to force some particular
> version.
>
> In ovs-ofctl.8, in the documentation for --packet-in-format, I think
> we should mention that it affects only the "monitor" and "snoop"
> commands.
>
> Thanks,
>
> Ben.
More information about the dev
mailing list