2014/04/16 18:54 "YAMAMOTO Takashi" <yamam...@valinux.co.jp>:
>
> > On Wed, Apr 16, 2014 at 04:39:24PM +0900, YAMAMOTO Takashi wrote:
> >> > @@ -1762,6 +1765,10 @@ compose_output_action__(struct xlate_ctx
*ctx, ofp_port_t ofp_port,
> >> > } else if (may_receive(peer, ctx)) {
> >> > if (xport_stp_forward_state(peer)) {
> >> > xlate_table_action(ctx, flow->in_port.ofp_port, 0,
true, true);
> >> > + if (ctx->xout->recirc_ofproto ==
ctx->xbridge->ofproto &&
> >> > + ctx->xout->recirc_md.in_port.odp_port ==
peer->odp_port) {
> >> > + ctx->xout->recirc_md.in_port.ofp_port =
peer->ofp_port;
> >> > + }
> >>
> >> can you explain this?
> >
> > In the case where recirculation occurs after a packet is output
> > to a patch port the ofproto and in_port may differ from that when
> > the packet was originally received or executed.
> >
> > The ofproto at the time when a recirculation action is composed is
> > saved in ctx->xout->recirc_ofproto by compose_recirculate_action().
> >
> > I could not work out how to obtain the odp_port at that time
> > so I deferred saving in ctx->xout->recirc_md.in_port.ofp_port until
> > here.
> >
> > The reason I had trouble obtaining it in compose_recirculate_action()
> > is that at that point an odp_port is available. But it is not
> > useful for converting to an ofp_port as my analysis is that
> > all patch ports use the same odp_port (2^32 - 2, IIRC).
>
> thanks for explanation.
>
> just to be sure, do you know that md.in_port is a union?
> which field of recirc_md.in_port is expected to be used, before and
> after the block?
Thanks, I am aware of that.
But I may well have messed things up.
> as the ofp port counterpart is used in the most parts of xlate code,
> the conditional on recirc_md.in_port.odp_port looks weird to me.
>
> >
> >
> > The update ofproto and ctx->xout->recirc_md values
> > are used to perform recirculation outside the datapath in cases
> > where it doesn't seem logical to receive recirculated packets from the
datapath
> > because the in_port of the packet does not correspond to an port the
datapath.
> > In particular:
> >
> > * Packets processed due to packet out with an in_port that doesn't
> > exist in the datapath. E.g. the CONTROLLER port.
> > * Packets where recirculation occurs after a packet is output
> > to a patch port. As I mention above all patch ports seem to
> > share the same ODP port. And it does not appear to exist in the
datapath.
>
> does your patch work for "output:1,2", where 1 and 2 are patch
> ports, both requiring recirculation?
Thanks, I had not considered that.
I think that I need to do some more work in this area.
> YAMAMOTO Takashi
>
> >
> >
> > I will work some documentation of the above into the code,
> > something I should have done before posting.
> >
> >> > @@ -3074,6 +3238,9 @@ xlate_actions__(struct xlate_in *xin, struct
xlate_out *xout)
> >> > ctx.xout->has_fin_timeout = false;
> >> > ctx.xout->nf_output_iface = NF_OUT_DROP;
> >> > ctx.xout->mirrors = 0;
> >> > + ctx.xout->recirc_ofproto = NULL;
> >> > + memset(&ctx.xout->recirc_md, 0, sizeof
ctx.xout->recirc_ofproto);
> >>
> >> this looks like a typo.
> >
> > Thanks, I will fix that.
> > _______________________________________________
> > dev mailing list
> > dev@openvswitch.org
> > http://openvswitch.org/mailman/listinfo/dev
>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
