-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ovs flows #447
base: main
Are you sure you want to change the base?
Ovs flows #447
Conversation
Functional tests are currently broken because of an issue in Vagrant 2.4.2. |
retis-events/src/ovs.rs
Outdated
|
||
#[event_type] | ||
#[derive(Copy, Default, PartialEq)] | ||
pub struct Ufid(pub [u32; 4]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a full review, just a comment that came up when integrating.
I had this:
#[event_type]
#[derive(Copy, Default, PartialEq)]
pub struct UFID {
parts: [u32; 4],
}
Looking at the convention taken elsewhere I think your name is probably preferred.
However, whether to use tuple vs named struct took me some thinking. I think tuples are nice if you don't use inner objects too much or else self.0
is a bit confusing to me when reading. Having it pub
is definitely a red flag, even more in this case where UFID.0 could be thought to be the first 32bit part.
Why did you need it to be public?
Also, note that internal members of event_type
s are accessed directly in python and tuples are a bit confusing (#437).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about this for a middle ground?
#[event_type]
#[derive(Copy, Default, PartialEq)]
pub struct UFID(pub u32, pub u32, pub u32, pub u32);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a full review, just a comment that came up when integrating.
I had this:
#[event_type] #[derive(Copy, Default, PartialEq)] pub struct UFID { parts: [u32; 4], }Looking at the convention taken elsewhere I think your name is probably preferred.
However, whether to use tuple vs named struct took me some thinking. I think tuples are nice if you don't use inner objects too much or else
self.0
is a bit confusing to me when reading. Having itpub
is definitely a red flag, even more in this case where UFID.0 could be thought to be the first 32bit part.Why did you need it to be public? Also, note that internal members of
event_type
s are accessed directly in python and tuples are a bit confusing (#437).
No real reason. TBF, this was simply quicker to write&share to unblock the other part of the work.
Something like this will have been the final intended form:
impl Ufid {
pub fn new_or_from_whatever(ufid: [u32; 4]) -> Self {
Self(ufid)
}
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about this for a middle ground?
#[event_type] #[derive(Copy, Default, PartialEq)] pub struct UFID(pub u32, pub u32, pub u32, pub u32);
Having parts accessible with this form sgtm.
Signed-off-by: Paolo Valerio <[email protected]>
5603ee3
to
5021d7f
Compare
While at it, n_{mask,cache}_hit have been included. Ideally, this should be done with fexit indexing by sw_flow_key, but given that is missing, it uses a dedicated map. Signed-off-by: Paolo Valerio <[email protected]>
Signed-off-by: Paolo Valerio <[email protected]>
extract ufid and other info