<div dir="ltr"><div>It is a good idea to capture this information in a table.   The following table should be accurate:<br><br>Pre-megaflow:<br><br>    type                mask               matches<br>    ----------------    ----------------   ---------------------------<br>
    eth_type(0x600+)    &lt;none&gt;       specified Ethertype II, or valid 802.3 SNAP<br>                                                   packet with valid eth_type.<br> Ethertype.<br>    &lt;none&gt;              &lt;none&gt;           any non-Ethernet II frame, except valid 802.3 SNAP<br>
                                                   packet with valid eth_type.<br><br>Post-megaflow:<br><br>    type                mask               matches<br>    ----------------    ----------------   ---------------------------<br>
    eth_type(0x600+)    eth_type(0xffff)   specified Ethertype II Ethertype, or valid 802.3 SNAP packet with valid eth_type.<br>    eth_type(0x600+)    eth_type(0)        any Ethertype II frame or non-Ethernet II frame.<br>
    &lt;none&gt;              eth_type(0xffff)   any non-Ethernet II frame, except valid 802.3 SNAP packet with valid eth_type. <br>
<br></div>--andy<br><div><div><br><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 19, 2013 at 1:42 PM, Ben Pfaff <span dir="ltr">&lt;<a href="mailto:blp@nicira.com" target="_blank">blp@nicira.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don&#39;t really care about the formatting, only about the kernel ABI.<br>
<br>
Pre-megaflows, the ABI was:<br>
<br>
    type                mask               matches<br>
    ----------------    ----------------   ---------------------------<br>
    eth_type(0x600+)    &lt;none&gt;             specified Ethertype II Ethertype.<br>
    &lt;none&gt;              &lt;none&gt;             any non-Ethernet II frame<br>
<br>
Now, my understanding is that the above continue to be valid, with the<br>
same meanings, but the following are also supported:<br>
<br>
    type                mask               matches<br>
    ----------------    ----------------   ---------------------------<br>
    eth_type(0x600+)    eth_type(0xffff)   specified Ethertype II Ethertype.<br>
    eth_type(0x600+)    eth_type(0)        any Ethertype II frame<br>
    &lt;none&gt;              eth_type(0xffff)   any non-Ethernet II frame<br>
<br>
Is that right?<br>
<div class="im"><br>
On Wed, Jun 19, 2013 at 10:40:28AM -0700, Andy Zhou wrote:<br>
&gt; We will continue to allow missing eth_type in the netlink attribute to<br>
&gt; imply Ethernet II type. 802.3 frames requires a specific eth_type<br>
&gt; attribute.<br>
<br>
</div>I don&#39;t understand the first sentence.  We have never interpreted a<br>
missing eth_type as implying an Ethernet II frame; the opposite, in<br>
fact: a missing eth_type matches only non-Ethernet II frames.<br>
<div class="im"><br>
&gt; With Mega flows, we further require a missing eth_type in the key attribute<br>
&gt; to have a exact match (oxffff) in the eth_type of the mask attribute (if<br>
&gt; present).<br>
<br>
</div>That&#39;s really weird.  What&#39;s the rationale?<br>
<br>
Thanks,<br>
<br>
Ben.<br>
</blockquote></div><br></div>