<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 24, 2013 at 6:13 PM, Alex Wang <span dir="ltr">&lt;<a href="mailto:alexw@nicira.com" target="_blank">alexw@nicira.com</a>&gt;</span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Thanks for the answers,<div class="gmail_extra">


<br><div class="gmail_quote"><div>On Mon, Jun 24, 2013 at 5:03 PM, Ben Pfaff <span dir="ltr">&lt;<a href="mailto:blp@nicira.com" target="_blank">blp@nicira.com</a>&gt;</span> wrote:<br>

</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div>On Mon, Jun 24, 2013 at 03:56:31PM -0700, Alex Wang wrote:<br>




&gt; 1. What is usually the bug in the buggy driver? How can using vlan-splinter<br>
&gt; avoid that? I&#39;m a bit confused here, since the &quot;vlandev.c&quot; code still talks<br>
&gt; to linux device driver (e.g. when creating ADD_VLAN_CMD) via the &quot;ioctl&quot;<br>
&gt; call.<br>
<br>
</div>ovs-vlan-bug-workaround(8) has a lot of information:<br>
<br></div>......</blockquote><div><br></div><div><br></div><div>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?</div>


</div></div></div></blockquote><div><br></div><div><br></div>Hey Ben,<div><br></div><div>I checked more code and seem to understand more about my question.</div><div><br></div><div>Here is my understanding about how vlan-splinter works,</div>


<div><br></div><div>1. The &quot;set interface p1 other-config:enable-vlan-splinters=true&quot; enables the vlan splinter of the port in ovsdb.</div><div><br></div><div>2. In &quot;vswitch/bridge.c&quot;, the vlandev is added and ports are created for each vlandev. Then, it calls functions in &quot;ofproto/ofproto.c&quot; and &quot;ofproto/ofproto-dpif.c&quot; to set vlandev port as slave to the realdev port.</div>


<div><br></div><div>3. The packets with vlan header are missed in kernel and examined in &quot;ofproto/ofproto-dpif.c&quot;. The &quot;vsp_vlandev_to_realdev()&quot; and &quot;vsp_realdev_to_vlandev()&quot; are used to convert between &quot;vlandev port&quot; and &quot;realdev port&quot;. And the performance cost is in that there is no datapath flow installed.</div>
<div><br></div>
<div>Does it sound correct?</div><div><br></div><div>Kind Regards,</div><div>Alex Wang,</div></div></div></div>