Skip to content
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

core: allow users to configure MTU for bridge and veth interfaces from config #111

Merged
merged 1 commit into from
Dec 1, 2021

Conversation

flouthoc
Copy link
Collaborator

@flouthoc flouthoc commented Dec 1, 2021

Netavark config accepts MTU as network option so allow users to
configure the same for both bridge and veth interfaces if defined.

Closes: #107

…m config

Netavark config accepts `MTU` as network option so allow users to
configure the same for both `bridge` and `veth` interfaces if defined.

Signed-off-by: Aditya Rajan <[email protected]>
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Dec 1, 2021

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: flouthoc

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci bot added the approved label Dec 1, 2021
@flouthoc
Copy link
Collaborator Author

flouthoc commented Dec 1, 2021

I want to rebase this PR after: #110

@@ -36,6 +36,23 @@ impl Core {
let mut response_net_addresses: Vec<NetAddress> = Vec::new();
// interfaces map, but we only ever expect one, for response
let mut interfaces: HashMap<String, types::NetInterface> = HashMap::new();
// mtu to configure, 0 means it was not set do nothing.
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should not set mtu to 0. Although kernel allows it but its a bug https://serverfault.com/a/652604

So netavark will NOOP in case of mtu: 0

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree 0 means default so we should do nothing

@@ -750,6 +789,12 @@ impl CoreUtils {
}
}

if mtu != 0 {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

small nit, I prefer mtu > 0 syntax as it is not clear here if this is a unit or regular int in which case != would allow negative values.
Not a blocker

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure i'll fix this.

@Luap99
Copy link
Member

Luap99 commented Dec 1, 2021

LGTM

@mheon
Copy link
Member

mheon commented Dec 1, 2021

/lgtm

@openshift-ci openshift-ci bot added the lgtm label Dec 1, 2021
@openshift-merge-robot openshift-merge-robot merged commit 0c81c3a into containers:main Dec 1, 2021
@flouthoc
Copy link
Collaborator Author

flouthoc commented Dec 1, 2021

whoops I really wanted to get this merged first #110 no issues i'll rebase the other one.

flouthoc added a commit to flouthoc/netavark that referenced this pull request Jan 12, 2022
Netavark config accepts `MTU` as network option so allow users to
configure the same for `macvlan` interface.

See https://github.com/containernetworking/plugins/blob/master/plugins/main/macvlan/macvlan.go#L181

Follow up PR to: containers#111

Signed-off-by: Aditya Rajan <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Set MTU
4 participants