[ovs-dev] Implementation of Packet-Out in Bundles

Fri Feb 26 20:07:32 UTC 2016

I wanted to right some unit tests to start testing my code and the
interactions of packet_outs with other messages in bundles.

I've seen some examples in ofp-print.at, ofproto.at and was trying to
figure them out so I could add more.

(ofp-print.at)
AT_SETUP([OFPT_BUNDLE_ADD_MESSAGE - PORT_MOD])
AT_KEYWORDS([ofp-print])
AT_CHECK([ovs-ofctl ofp-print "\
05 22 00 38 00 00 00 03 00 00 00 01 00 00 00 01 \
05 10 00 28 00 00 00 03 00 00 00 03 00 00 00 00 \
50 54 00 00 00 01 00 00 00 00 00 01 00 00 00 01 \
00 00 00 08 00 00 00 01
"], [0], [dnl
OFPT_BUNDLE_ADD_MESSAGE (OF1.4) (xid=0x3):
 bundle_id=0x1 flags=atomic
OFPT_PORT_MOD (OF1.4) (xid=0x3): port: 3: addr:50:54:00:00:00:01
     config: PORT_DOWN
     mask:   PORT_DOWN
     advertise: 10MB-HD
])

>From ofproto.at I can see that:

05 - OpenFlow14 message
22 - OFPT_BUNDLE_ADD_MESSAGE (?)

I also tried to search for ovs-ofctl ofp-print syntax or help but couldn't
find it.

Any help?

André Mantas <andremantas7 at gmail.com> escreveu no dia quinta, 18/02/2016 às
20:00:

> Thanks for the detailed answer. Comments below.
>
> Jarno Rajahalme <jarno at ovn.org> escreveu no dia quarta, 17/02/2016 às
> 17:59:
>
>>
>> > On Feb 17, 2016, at 2:39 AM, André Mantas <andremantas7 at gmail.com>
>> wrote:
>> >
>> > Hi. I'm currently adding support for packet-out messages in bundles.
>> >
>> > I started to look at *handle_packet_out*, *handle_bundle_add *and
>> > *do_bundle_commit
>> > *functions to understand how things work. Here is what I did in each
>> > function:
>> >
>> > *handle_bundle_add:* added if case for OFPTYPE_PACKET_OUT which does all
>> > the validations performed in handle_packet_out as well as saving the
>> > packet_out info in the bundle_entry. For this I added a new
>>
>> You’d have to make sure that the validations work as expected in the
>> context of the bundle. I haven’t checked the details, but if an earlier
>> message in the bundle adds a port (that has not been committed yet), will
>> the in_port of the packet_out using that port validate correctly?
>>
>
> Good question, will have to look at this. It should allow a packet_out in
> that "new" port.
>
>
>> Group and meter validation is part of the action validation for
>> packet_out. While the bundles can’t currently include group or meter mods,
>> I’d like to see that adding packet_out to a bundle does not unnecessarily
>> complicate adding group and meter mods to bundles.
>>
>>
> If this is the case, should a new validation function be made that does
> not involve validating group and meters?
>
>
>> > ofproto_packet_out struct to the union in ofp_bundle_entry. This new
>> struct
>> > (created in the same way as ofproto_flow_mod and ofproto_port_mod)
>> contains
>> > an ofputil_packet_out, a dp_packet *payload and a flow. If I understand
>> > correctly, this three structs are needed later to send the packet_out in
>> > the commit phase.
>> >
>> > *do_bundle_commit: *added if case for OFPTYPE_PACKET_OUT in phase 3
>> > (finish) which calls the ofproto->ofproto_class->packet_out function
>> using
>> > the data saved in the bundle entry and then deletes de payload (as done
>> in
>> > handle_packet_out).
>> > In phase 1 (begin) I only added prev_is_port_mod = false; to the
>> packet-out
>> > "if case" because all the validations were done before.
>> >
>> > Is there a way to verify if the packet can be sent without actually
>> sending
>> > it?
>>
>> Currently, no. The packet_out execution can fail either in action
>> translation (which may call into arbitrarily complex set of flow tables via
>> resubmit action), or in datapath action execution. Datapaths (such as the
>> openvswitch Linux kernel module) currently perform action validation as an
>> integral part of packet execution, and it may be impossible to create a
>> call that would only exercise the validation part.
>>
>> > If not, the ofproto->ofproto_class->packet_out can still return errors,
>> but
>> > this will be in the finish phase, which cannot be rolled back.
>>
>> To make packet_out behave correctly in a bundle, the
>> ofproto_class->packet_out should be split into separate validation and
>> execution pieces. If you decide to do this, it may be possible to perform
>> the action translation piece before the commit phase, leaving only the
>> datapath action execution to the ofproto_class->packet_out. However, it may
>> be costly to split the datapath action execution to separate validation and
>> execution steps. Generally we do a good job not trying to execute something
>> that the datapath then rejects, so maybe that is not necessary.
>>
>
> That's good to know. If it comes out that splitting the function is a
> better solution, I may be able to do it.
>
>
>>
>> > I think that in this case the bundle should still be committed (because
>> it
>> > does not affect other modifications like flow-mods and port-mods) and
>> > errors can be returned to the controller. Would this be a good option?
>> >
>>
>> As per the OpenFlow bundle spec, the controller does not expect any
>> errors for a successful bundle commit. So this would not be a good option.
>>
>
> Right, I just thought it would make sense in this case, but it cannot be
> done.
>
>
>>
>> However, contrary to the documentation in ofproto-provider.h, our current
>> implementation of packet_out in ofproto-dpif.c does not pass any errors
>> back to the caller. If we decide to keep it that way, then all of the above
>> is kind of moot, as we pretend that the packet_out succeeded even when it
>> did not.
>>
>
> So, summing up, the most straightforward solution is to assume that after
> the first validation, a packet-out never fails being sent, right?
>
>
>>
>>   Jarno
>>
>> > I would also like to know if I'm going in the right direction or if I
>> did
>> > something wrong.
>> >
>> > Thanks in advance.
>> > _______________________________________________
>> > dev mailing list
>> > dev at openvswitch.org
>> > http://openvswitch.org/mailman/listinfo/dev
>>
>>