Thanks Jarno for the hints!
I found this function looking for ", struct dpif_op " term in every file.
static void dpif_linux_operate(struct dpif *dpif_, struct dpif_op **ops,
size_t n_ops)
The main lines in that function of my interest are:
dpif_linux_encode_execute(dpif->dp_ifindex, execute, &aux->request);
nl_transact_multiple(NETLINK_GENERIC, txnsp, n_ops);
As I understand from this function, and following the path for op->type
= DPIF_OP_EXECUTE, a request is sent at
"nl_transact_multiple(NETLINK_GENERIC, txnsp, n_ops);" through
NETLINK_GENERIC protocol (to the kernel?, any hint to where are they
sent?). Inside this function, I can find these important functions:
lib/netlink-socket.c:
nl_sock_transact_multiple__(struct nl_sock *sock,
struct nl_transaction **transactions, size_t n,
size_t *done) {
/* some lines */
do {
error = sendmsg(sock->fd, &msg, 0) < 0 ? errno : 0;
} while (error == EINTR);
/* some lines */
error = nl_sock_recv__(sock, buf_txn->reply, false);
/* some lines */
The thing is that when my action is performed, the error value is 0 (BAD,
packet is not sent); and when it is not performed, error = 11 = EAGAIN (OK,
actions are performed and packet is sent). I guess this means that whoever
receives the request, still does not understand the meaning of the custom
action I am creating.
I will be posting here any updates I have.
Kind regards,
Raúl Suárez
2015-03-19 20:50 GMT+01:00 Jarno Rajahalme <jrajaha...@nicira.com>:
> Raúl,
>
> The dip class functions are implemented by the different dip classes.
> Linux and Windows data paths are interfaced by lib/dpif-netlink.c and the
> userspace datapath is implemented in lib/dpif-netlink.c. You’ll find a
> class struct with the local function pointers in those files, just search
> for “operate” in those files.
>
> Hope this helps,
>
> Jarno
>
> > On Mar 19, 2015, at 2:06 AM, Raul Suarez Marin <
> raul.suarez.ma...@gmail.com> wrote:
> >
> > 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
>
>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
