<div dir="ltr">Good idea. There may be other aspects of the mega related kernel ABI needs document as well. Wonder if Justin and Jesse have more inputs on this. <br></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Wed, Jun 19, 2013 at 2:55 PM, Ben Pfaff <span dir="ltr"><<a href="mailto:blp@nicira.com" target="_blank">blp@nicira.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
OK, can we add that in the tree somewhere, maybe datapath/README?<br>
<br>
Thanks,<br>
<br>
Ben.<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, Jun 19, 2013 at 02:52:52PM -0700, Andy Zhou wrote:<br>
> It is a good idea to capture this information in a table. The following<br>
> table should be accurate:<br>
><br>
> Pre-megaflow:<br>
><br>
> type mask matches<br>
> ---------------- ---------------- ---------------------------<br>
> eth_type(0x600+) <none> specified Ethertype II, or valid 802.3<br>
> SNAP<br>
> packet with valid<br>
> eth_type.<br>
> Ethertype.<br>
> <none> <none> any non-Ethernet II frame, except<br>
> valid 802.3 SNAP<br>
> packet with valid<br>
> eth_type.<br>
><br>
> Post-megaflow:<br>
><br>
> type mask matches<br>
> ---------------- ---------------- ---------------------------<br>
> eth_type(0x600+) eth_type(0xffff) specified Ethertype II<br>
> Ethertype, or valid 802.3 SNAP packet with valid eth_type.<br>
> eth_type(0x600+) eth_type(0) any Ethertype II frame or<br>
> non-Ethernet II frame.<br>
> <none> eth_type(0xffff) any non-Ethernet II frame,<br>
> except valid 802.3 SNAP packet with valid eth_type.<br>
><br>
> --andy<br>
><br>
><br>
><br>
><br>
> On Wed, Jun 19, 2013 at 1:42 PM, Ben Pfaff <<a href="mailto:blp@nicira.com">blp@nicira.com</a>> wrote:<br>
><br>
> > I don'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+) <none> specified Ethertype II<br>
> > Ethertype.<br>
> > <none> <none> 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<br>
> > Ethertype.<br>
> > eth_type(0x600+) eth_type(0) any Ethertype II frame<br>
> > <none> eth_type(0xffff) any non-Ethernet II frame<br>
> ><br>
> > Is that right?<br>
> ><br>
> > On Wed, Jun 19, 2013 at 10:40:28AM -0700, Andy Zhou wrote:<br>
> > > We will continue to allow missing eth_type in the netlink attribute to<br>
> > > imply Ethernet II type. 802.3 frames requires a specific eth_type<br>
> > > attribute.<br>
> ><br>
> > I don'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>
> ><br>
> > > With Mega flows, we further require a missing eth_type in the key<br>
> > attribute<br>
> > > to have a exact match (oxffff) in the eth_type of the mask attribute (if<br>
> > > present).<br>
> ><br>
> > That's really weird. What's the rationale?<br>
> ><br>
> > Thanks,<br>
> ><br>
> > Ben.<br>
> ><br>
</div></div></blockquote></div><br></div>