[ovs-discuss] Does it work if netdev datapath connect system datapath through patch ports

Hui Xiang xianghuir at gmail.com
Fri Oct 13 23:33:43 UTC 2017

Thanks Ben, that is much helpful explanation.

On Fri, Oct 13, 2017 at 11:42 PM, Ben Pfaff <blp at ovn.org> wrote:

> On Fri, Oct 13, 2017 at 06:04:16PM +0800, Hui Xiang wrote:
> > Is the patch port output logistic within function
> apply_nested_clone_actions
> > ? Sorry, I have not totally understood the whole picture on how a packet
> > through
> > the datapath flow on the case that goes from netdev datapath patch port_B
> > to system datapath port_C. Is it such a procedure:
> > When a packet arrives at patch port_B of netdev datapath br1, the xlate
> ctx
> > switch to system datapath br2, and try to find a
> > rule, the rule probably missed, but I didn't find where this rule should
> be
> > preloaded, and why does it not work in this case.
> >
> > Coud you help to guide?
> Patch port output happens in patch_port_output() in ofproto-dpif-xlate.c.
> Patch ports are implemented entirely within a datapath.  Output to one
> happens by simply doing a nested translation of the actions that would
> happen at the other end of the patch port.  This can't really happen if
> the packet would pass to another datapath entirely.  One could implement
> some feature for hopping from one datapath to another.  We have not done
> this because the value of the feature seems limited; most installations
> of OVS use only a single datapath.
> > In additions, does it work with veth connected netdev datapath with
> system
> > datapath? It seems OVN will bridge the br-int with
> > the external network having another bridge with patch port, in this case,
> > if br-int is netdev, but external bridge is system,
> > then it doesn't work as what I understand so far.
> veths should be able to hop from one datapath to another, at least for
> datapaths that support veths.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20171014/12583d0b/attachment.html>

More information about the discuss mailing list