At Thu, 21 Jul 2016 22:00:21 +0900 (JST), FUJITA Tomonori wrote: > > On Thu, 21 Jul 2016 15:56:07 +0900 > Shinpei Muraoka <shinpei.mura...@gmail.com> wrote: > > > Hi Fujita-San > > > >> The patch can't be cleanly reverted. So let's forget this point. > > > > I got it. > > I will include it in the patch. > > > > > >> Keeping the jsondict outputs is nice but it's optional for me. > > > > I think the simple source is good. > > I modify the format to be set the zone_src a string. > > If you want to set the immediate value for zone, > > zone_src set the None or empty character string. > > > > > >> As Iwamoto-san pointed out, this patch doesn't recover the old API: > >> > >> https://github.com/osrg/ryu/blob/d090b291bee5a8e1883cb4a75b9045b2703cdba8/ryu/ofproto/nx_actions.py#L215 > >> > >> Can you please fix that? > > > > NXActionRegLoad was present in the nx_actions.py and > > ofproto_v1_0_parser.py originally. > > The nx_actions.py had ofs and nbits in the argument. > > The ofproto_v1_0_parser.py had ofs_nbits in the argument. > > It is common to set the values directly to ofs_nbits in nx_actions.py. > > Now it is in the form of ofproto_v1_0_parser.py. > > I think the current form is correct, > > what you do think? > > I think that the point is we keep the exact same API. So strictly > speaking, we have to have ofs_nbits argument for RegLoad with OF1.0 > and ofs and nbits with other OF versions. Right? > > The safer option is adding a hack for accepting both ofs_nbits/ofs and > nbits. > > But after checking the dragonflow code, RegLoad is not used. So we > might be able to have ofs_nbits argument for both if it's more > consistent with the rests. > > Iwamoto-san, what's your opinion?
I checked the git history. When I added NXActionRegLoad, I thought ofs and nbits are more user-friendly than ofs_nbit, without being aware of pre-existing ofs_nbits API elsewhere, IIRC. So, I'm fine with ofs_nbits for NXActionRegLoad. -- IWAMOTO Toshihiro ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev _______________________________________________ Ryu-devel mailing list Ryu-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ryu-devel