[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