On 11/29/21 16:50, Salvatore Daniele wrote:
> On Mon, Nov 29, 2021 at 8:01 AM Ilya Maximets wrote:
>>
>> On 11/4/21 20:54, Salvatore Daniele wrote:
>>> Hi Ilya,
>>>
>>> Per your feedback on v4, I accounted for igmp_type/code, both in the
>>> work-around in 1/2, and removing it from match.c entirel
On Mon, Nov 29, 2021 at 8:01 AM Ilya Maximets wrote:
>
> On 11/4/21 20:54, Salvatore Daniele wrote:
> > Hi Ilya,
> >
> > Per your feedback on v4, I accounted for igmp_type/code, both in the
> > work-around in 1/2, and removing it from match.c entirely in 2/2.
> >
> > I was not sure the best way to
On 11/4/21 20:54, Salvatore Daniele wrote:
> Hi Ilya,
>
> Per your feedback on v4, I accounted for igmp_type/code, both in the
> work-around in 1/2, and removing it from match.c entirely in 2/2.
>
> I was not sure the best way to proceed regarding the issue I had
> mentioned on v4 where ofputil_n
Hi Ilya,
Per your feedback on v4, I accounted for igmp_type/code, both in the
work-around in 1/2, and removing it from match.c entirely in 2/2.
I was not sure the best way to proceed regarding the issue I had
mentioned on v4 where ofputil_normalize_match__() fails to recognize
'igmp/ip,nw_proto=2
match_format() prints the keyword "igmp" for flows with the field
"ip,nw_proto=2". ofp_parse_protocol does not accept this value, or
the values igmp_type or igmp_code.
This results in flow dump restoration failing when the ovs-save script
is used by "ovs-ctl restart" on a dump of flows containing
