Hello again,
At lib/dpif.c in function "dpif_operate" there is a line that is being
called.
dpif->dpif_class->operate(dpif, ops, chunk);
This is possibly the actions are performed, but I have no clue how to know
what function this line leads to.
In lib/dpif-provider.h I can find the definition for these structs, but I
can only see:
/* Executes each of the 'n_ops' operations in 'ops' on 'dpif', in the order
* in which they are specified, placing each operation's results in the
* "output" members documented in comments.
*
* This function is optional. It is only worthwhile to implement it if
* 'dpif' can perform operations in batch faster than individually. */
void (*operate)(struct dpif *dpif, struct dpif_op **ops, size_t n_ops);
Kind regards,
Raúl Suárez
2015-03-18 21:26 GMT+01:00 Raul Suarez Marin <raul.suarez.ma...@gmail.com>:
> Hello Ben,
>
> Thank you for your answer. Let me correct myself when I said I adapated
> parts of "handle_upcalls", I realized I just added debugging lines only
> (my bad).
> I am trying to do the ovs-vswitchd ofproto/trace command but I am getting
> failed connection attempts because "address family is not supported by
> protocol". I will sort it out.
>
> My thoughts right now are:
> 1) I have done in "do_xlate_actions" the part of reading the field I want
> to apply the action to. (new case OFPACT_MY_FIELD)
> 2) I adapted "commit_odp_actions" which is called
> by "compose_output_action" which is called by "xlate_output_action" which
> is called by "do_xlate_actions" (case OFPACT_OUTPUT) and it is located in
> "lib/ofp-util.c" This function adds the actions to the ofpbuf at
> ctx->xout->odp_actions
> with enum ovs_key = OVS_KEY_ATTR_MY_FIELD. I think there is no way this
> fails (because it's just appending data).
> 3) Added OVS_KEY_ATTR_MY_FIELD where needed. Specially in function
> "odp_execute_set_action" at lib/ofp-execute.c, where looks like that the
> packet is actually modified. There, I do this:
>
> const struct ovs_key_STRUCTURE_MODEL my_key = nl_attr_get_unspec(a,
> sizeof(struct ovs_key_STRUCTURE_MODEL))
> struct MY_STRUCTURE *packet_to_do_action = ofpbuf_l3(packet);
> packet_to_do_action ->my_field = my_key ->my_field;
>
> This should make it.
>
> BUT, HERE is the problem!
>
> I placed this code at "odp_execute_set_action" [function in 3)]
>
> FILE *f;
> f = fopen("/home/raul/match_event2.txt", "ab+");
> fprintf(f, "->odp_execute_set_action(%d)\n", type);
> fclose(f);
>
> This is what I use for debugging. It is a very ugly way of doing it but it
> works for me. But, this line is not printed when debugging, so the code
> never arrives at this point (even if my action is not implemented).
> However, when my action is not implemented the action execution works, but
> still the said line is not printed... so maybe it executes that code but it
> is not able to print, I do not know really.
>
> I will be posting here updates so anyone trying to do this same thing can
> have a "clear" idea of what to do.
>
> Thanks again Ben for your help, hints and guidelines.
>
> Kind regards,
> Raúl Suárez
>
>
> 2015-03-12 16:06 GMT+01:00 Ben Pfaff <b...@nicira.com>:
>
>> On Thu, Mar 12, 2015 at 09:11:11AM +0100, Raul Suarez Marin wrote:
>> > I am trying to develop new actions for openvswitch, I have done all my
>> work
>> > but looks like it does not work.
>> >
>> > What I have done:
>> > -> Enable ovs to read and parse new actions, so they appear on ovs-ofctl
>> > dump-flows command.
>> > -> Adapted required parts of "handle_upcalls" function
>> > at ofproto\ofproto-dpif-upcall.c (and inside functions)
>> > -> Adapted "do_xlate_actions" function at ofproto\ofproto-dpif-xlate.c
>> >
>> > The problem is:
>> > If the new action is not programmed, everything goes as expected.
>> > If the new action is programmed, no packet forwarding is done.
>> >
>> > The last sentence means that I have done all my work, but part of it is
>> > wrong, or that I am still missing something?
>>
>> I think you've hit the right parts of the code. Try ofproto/trace (see
>> ovs-vswitchd(8)) for some hints.
>>
>> A new action wouldn't normally need any changes in handle_upcalls().
>>
>
>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
