On Fri, May 27, 2011 at 4:40 PM, Ben Pfaff <[email protected]> wrote:
> Until now, the tun_id and in_port have been lost when a packet is sent from
> the kernel to userspace and then back to the kernel. I didn't think that
> this was a problem, but recent behavior made me look closer and see that
> it makes a difference if sFlow is turned on or if an
> ODP_ATTR_ACTION_CONTROLLER action is present. We could possibly kluge
> around those, but for future-proofing it seems better to pass the packet
> metadata from userspace to the kernel. That is what this commit does.
>
> This commit introduces a user-kernel protocol break. We could avoid that,
> if it is desirable, by making ODP_PACKET_ATTR_KEY optional for
> ODP_PACKET_CMD_EXECUTE commands.
>
> Signed-off-by: Ben Pfaff <[email protected]>
> Bug #4769.
I think this bug number is from the original work that triggered
looking into this but it is not actually related.
> diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
> index 53574aa..88960ec 100644
> --- a/lib/dpif-netdev.c
> +++ b/lib/dpif-netdev.c
> @@ -944,6 +944,7 @@ dpif_netdev_flow_dump_done(const struct dpif *dpif
> OVS_UNUSED, void *state_)
>
> static int
> dpif_netdev_execute(struct dpif *dpif,
> + const struct nlattr *k OVS_UNUSED, size_t k_len
> OVS_UNUSED,
> const struct nlattr *actions, size_t actions_len,
> const struct ofpbuf *packet)
> {
I think we need to extract the in port from the metadata here.
There's no sFlow in userspace but it is still possible for a packet to
be sent to the controller (there's the optimization that tries to
avoid this case but it doesn't catch all situations). If the packet
does go to the controller, then it will have a port of -1 instead of
the real one. In addition, this would resolve an inconsistency
between here and ofproto-dpif.c:send_packet() as to whether we should
use -1 or 0 as the in port when we don't have a real one.
_______________________________________________
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev
