Good to hear, thank you.
On Wed, Jun 19, 2013 at 06:42:59PM -0700, Jesse Gross wrote: > I added most of the ones that seemed important during my cleanups > yesterday. The only other thing that comes to mind is a description of > how updates are handled (such as the fact that the new mask is > ignored). > > On Wed, Jun 19, 2013 at 3:04 PM, Andy Zhou <az...@nicira.com> wrote: > > 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. > > > > > > On Wed, Jun 19, 2013 at 2:55 PM, Ben Pfaff <b...@nicira.com> wrote: > >> > >> OK, can we add that in the tree somewhere, maybe datapath/README? > >> > >> Thanks, > >> > >> Ben. > >> > >> On Wed, Jun 19, 2013 at 02:52:52PM -0700, Andy Zhou wrote: > >> > It is a good idea to capture this information in a table. The > >> > following > >> > table should be accurate: > >> > > >> > Pre-megaflow: > >> > > >> > type mask matches > >> > ---------------- ---------------- --------------------------- > >> > eth_type(0x600+) <none> specified Ethertype II, or valid > >> > 802.3 > >> > SNAP > >> > packet with valid > >> > eth_type. > >> > Ethertype. > >> > <none> <none> any non-Ethernet II frame, > >> > except > >> > valid 802.3 SNAP > >> > packet with valid > >> > eth_type. > >> > > >> > Post-megaflow: > >> > > >> > type mask matches > >> > ---------------- ---------------- --------------------------- > >> > eth_type(0x600+) eth_type(0xffff) specified Ethertype II > >> > Ethertype, or valid 802.3 SNAP packet with valid eth_type. > >> > eth_type(0x600+) eth_type(0) any Ethertype II frame or > >> > non-Ethernet II frame. > >> > <none> eth_type(0xffff) any non-Ethernet II frame, > >> > except valid 802.3 SNAP packet with valid eth_type. > >> > > >> > --andy > >> > > >> > > >> > > >> > > >> > On Wed, Jun 19, 2013 at 1:42 PM, Ben Pfaff <b...@nicira.com> wrote: > >> > > >> > > I don't really care about the formatting, only about the kernel ABI. > >> > > > >> > > Pre-megaflows, the ABI was: > >> > > > >> > > type mask matches > >> > > ---------------- ---------------- --------------------------- > >> > > eth_type(0x600+) <none> specified Ethertype II > >> > > Ethertype. > >> > > <none> <none> any non-Ethernet II frame > >> > > > >> > > Now, my understanding is that the above continue to be valid, with the > >> > > same meanings, but the following are also supported: > >> > > > >> > > type mask matches > >> > > ---------------- ---------------- --------------------------- > >> > > eth_type(0x600+) eth_type(0xffff) specified Ethertype II > >> > > Ethertype. > >> > > eth_type(0x600+) eth_type(0) any Ethertype II frame > >> > > <none> eth_type(0xffff) any non-Ethernet II frame > >> > > > >> > > Is that right? > >> > > > >> > > On Wed, Jun 19, 2013 at 10:40:28AM -0700, Andy Zhou wrote: > >> > > > We will continue to allow missing eth_type in the netlink attribute > >> > > > to > >> > > > imply Ethernet II type. 802.3 frames requires a specific eth_type > >> > > > attribute. > >> > > > >> > > I don't understand the first sentence. We have never interpreted a > >> > > missing eth_type as implying an Ethernet II frame; the opposite, in > >> > > fact: a missing eth_type matches only non-Ethernet II frames. > >> > > > >> > > > With Mega flows, we further require a missing eth_type in the key > >> > > attribute > >> > > > to have a exact match (oxffff) in the eth_type of the mask attribute > >> > > > (if > >> > > > present). > >> > > > >> > > That's really weird. What's the rationale? > >> > > > >> > > Thanks, > >> > > > >> > > Ben. > >> > > > > > > > > > > _______________________________________________ > > dev mailing list > > dev@openvswitch.org > > http://openvswitch.org/mailman/listinfo/dev > > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
