That seems reasonable to me. I suggest posting the patch; we can
quibble about details at that point.
On Thu, May 19, 2016 at 12:28:00PM +0200, Jan Scheurich wrote:
> I have a patch prepared that adds a new group mod command OFPGC11_ADD_OR_MOD
> (value 0x8000 to not conflict with standard OFPGC
I have a patch prepared that adds a new group mod command OFPGC11_ADD_OR_MOD
(value 0x8000 to not conflict with standard OFPGC commands) to the openflow
header files.
When ofproto.c receives such a group_mod it checks the existence of the
referred group_id and either calls add_group() or
On Wed, May 11, 2016 at 01:30:58PM +, Jan Scheurich wrote:
> A simple solution to this problem would be an additional, more
> tolerant Group Mod command (e.g. ADD_OR_MODIFY) that writes a group
> into the group table no matter if it already existed in the switch or
> not. A similar proposal
In OpenFlow 1.x the Group Mod commands OFPGC_ADD and OFPGC_MODIFY have strict
semantics: ADD fails if the group exists, while MODIFY fails if the group does
not exist.
This requires a controller to exactly know the state of the switch when
programming a group in order not run the risk of
