On Mon, Jun 24, 2013 at 6:13 PM, Alex Wang <al...@nicira.com> wrote: > Thanks for the answers, > > On Mon, Jun 24, 2013 at 5:03 PM, Ben Pfaff <b...@nicira.com> wrote: > >> On Mon, Jun 24, 2013 at 03:56:31PM -0700, Alex Wang wrote: >> > 1. What is usually the bug in the buggy driver? How can using >> vlan-splinter >> > avoid that? I'm a bit confused here, since the "vlandev.c" code still >> talks >> > to linux device driver (e.g. when creating ADD_VLAN_CMD) via the "ioctl" >> > call. >> >> ovs-vlan-bug-workaround(8) has a lot of information: >> >> ...... > > > > This is very helpful. Also, Do you which file I should check to see how > packet (with vlan header) arrived on a trunk port is mapped to > corresponding vlandev port? >
Hey Ben, I checked more code and seem to understand more about my question. Here is my understanding about how vlan-splinter works, 1. The "set interface p1 other-config:enable-vlan-splinters=true" enables the vlan splinter of the port in ovsdb. 2. In "vswitch/bridge.c", the vlandev is added and ports are created for each vlandev. Then, it calls functions in "ofproto/ofproto.c" and "ofproto/ofproto-dpif.c" to set vlandev port as slave to the realdev port. 3. The packets with vlan header are missed in kernel and examined in "ofproto/ofproto-dpif.c". The "vsp_vlandev_to_realdev()" and "vsp_realdev_to_vlandev()" are used to convert between "vlandev port" and "realdev port". And the performance cost is in that there is no datapath flow installed. Does it sound correct? Kind Regards, Alex Wang,
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
