On 09.08.2024 16:51, [email protected] wrote:
On Fri, 2024-08-09 at 11:28 +0200, Dumitru Ceara wrote:
On Friday, August 9, 2024,<[email protected]> wrote:
I don't mind merging them, but while we are at the topic. Are there
benefits in processing performance in "fewer, more complex rules"
vs "more, less complex rules"? Or is it just to improve
readability?
In this case I don’t expect we’ll have a lot of ports with redirect
enabled so, from my perspective, it’s just readability (I was ok with
the 2 flow version too). From an openflow perspective there’s no
difference.
Thanks, I think I'll have to keep the current 2-line implementation in
and add this into the list of future improvements. @Vladislav I do
appreciate the review and the feedback, and I don't want to look like
I'm just ignoring it, but due to the time pressure (freeze today) and
this change resulting in tests/docs change (which always takes me way
more than I expect) i don't think I'll fit it in. It doesn't look like
it but the overhead adds up.
Sure, no problem.
I'm going to test v6. Will return with feedback soon. Stay tuned :)
Martin.
Thanks,
Dumitru
Martin.
On Fri, 2024-08-09 at 11:08 +0200, Dumitru Ceara wrote:
On Friday, August 9, 2024, Vladislav Odintsov<[email protected]>
wrote:
Don't we want to merge these two conditions into one logical
flow?
E.g.:
"(ip%d.dst == %s && (%s.dst == %d && %s.src == %d)"
Sorry, there is typo. It should be:
"(ip%d.dst == %s && (%s.dst == %d || %s.src == %d)"
?
This will make one logical flow per LRP IP per protocol
instead of two.
I didn’t test this but I think that looks ok.
Regards,
Dumitru
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
