Use exact match or regex for pfname selector #350

rozeps · 2021-05-04T14:59:56Z

Use regular expression as PF selector.

martinkennelly

Thank you for the patch. Its an interesting enhancement. Id like to have this feature turned off by default.

martinkennelly · 2021-05-27T11:59:09Z

pkg/resources/deviceSelectors.go

 		if strings.EqualFold(strings.Split(item, "#")[0], needle) {
 			return item
 		}
+		re, err := regexp.Compile(strings.Split(item, "#")[0])


I am worried about a regex expression with '#' char itself. We should definitely throw an error if that is included.

I think you should split the string once into a var once you have checked it doesn't include more than one '#' char at the start of this loop. Ignore any string that have more than one '#' and log it.

Sure I understand your concern. Not sure how to make this "turned off", but one way to address both issue could be to use a special notation like "re{<regexp}#" so the "re{...}" is the way to turn on the feature and the brackets ensure that everthing included is the regexp and everything that follows is the VF list.

Regex delimiter could also be "/regexp/[#vfs]" (slash is definitely not an interface name allowed character)

martinkennelly · 2021-05-27T12:03:28Z

pkg/resources/deviceSelectors.go

@@ -171,11 +173,20 @@ func contains(hay []string, needle string) bool {
 	return false
 }

-func getItem(hay []string, needle string) string {
+func getItem(hay []string, needle string, what string) string {


I don't think the 'what' arg is needed.

Sure can remove.

martinkennelly · 2021-05-27T12:07:22Z

pkg/resources/deviceSelectors.go

 	for _, item := range hay {
+		// May be an exact match or a regex, try both.


I think I'd like to have this regex matching an optional feature that would be off by default. I am worried a PF name could end up being a regex expression and cause strange matches to occur.

With explicit re delimiter, intent would be clear that it must compile/match.

martinkennelly · 2021-05-31T08:37:09Z

@rozeps Why not use multiple pfNames selector?

adrianchiris · 2021-05-31T10:44:18Z

@rozeps can you explain the problem you are trying to solve with this PR ?

rozeps · 2021-05-31T13:41:27Z

We are deploying in multi-nodes OpenShift clusters, and we support few vendors SR-IOV for use in our applications (matching on vendor PF is not sufficient here).

We are reserving VFs 0-2 for internal use then 3-7 for end user applications.

As interface name not fully predictive (systems end up with ens5s0f0 or enp65s0f0, and so on).

I am tring to come up with configuration that would match any PF from vendor/device XYZ, take only VFs 3-7.

martinkennelly · 2021-05-31T13:50:58Z

We are deploying in multi-nodes OpenShift clusters, and we support few vendors SR-IOV for use in our applications (matching on vendor PF is not sufficient here).

We are reserving VFs 0-2 for internal use then 3-7 for end user applications.

As interface name not fully predictive (systems end up with ens5s0f0 or enp65s0f0, and so on).

I am tring to come up with configuration that would match any PF from vendor/device XYZ, take only VFs 3-7.

@rozeps
Is the PCI address deterministic across your cluster for the PFs you wish to consume? You can use that instead of PF name.
Or use udev rules to make your interfaces names deterministic?

rozeps · 2021-05-31T14:11:25Z

Well apparently yes, but I just looked at few systems that are based on same Xeon family (same socket/numa architecture), just wonder how that may differ in more heterogeneous h/w environment (that customers would be allowed to use).

In my mind, would be much simpler to say selector: "match vendor=0x8086,device=0x158b,pf=/.*/#3-7"

With the re enclosed in special characters (illegal ifname ones) don't think that would break much existing implementations.

adrianchiris · 2021-06-01T07:15:04Z

I am tring to come up with configuration that would match any PF from vendor/device XYZ, take only VFs 3-7.

So if you would have a "VFIndex" selector it would also satisfy your use-case ?

rozeps · 2021-06-01T13:10:15Z

Sure you mean no PFNames just the VFIndex as list of id that would be perfect (and cleaner I believe).

adrianchiris · 2021-06-01T14:03:45Z

@rozeps this PR was discussed in today's technical meeting

see: https://docs.google.com/document/d/1bEyEh_K9lGwQWHgUHUH-vqodYd1W-LCWRGlW0-ZVR5A/edit#

We would like to understand more about your use-case and whether or not it is possible to get persistent and predictable net device names.

if it is, then using pfNames while specifying all relevant netdevs with the specific range should work.
e.g all nodes have 4 NICs and the netdevs are named the same across nodes.

if it isnt, then a "VFIndex" selector might do the trick.
A regex as you proposed will work but it requires to introduce a special notation for it + ensuring it does not affect existing configuration, so its less favorable.

rozeps · 2021-06-02T12:12:51Z

We cannot predict all the combinations now and future, but on my test systems I have 2 nodes with mix of different cards (Mellanox/Intel) and the PCI addresses are different, and the network device names also. Anticipating all possible PF names might be error prone one day someone deploy node with slightly different config and the PF name is not on the list ... may take while to figure out.

The VFIndex I think would have been a good idea if initially tought (in addition to the PFName) but right now that could conflict right one may have non-overlapping pfname with "#0-2-3" part and VFIndex.

The regex enclosed withih "/" is backward compatible with existing syntax - when not present exact match on PF name is used otherwise the regex logic.

adrianchiris · 2021-06-02T12:52:42Z

The VFIndex I think would have been a good idea if initially tought (in addition to the PFName) but right now that could conflict right one may have non-overlapping pfname with "#0-2-3" part and VFIndex.

AND is performed between different selectors, so result will be consistent
It might not make sense to use the VF range notation and VFIndex selector.
there are other combinations that might not make sense.

@zshi-redhat, @martinkennelly any [additional] thoughts on this ?

zshi-redhat · 2021-07-05T13:51:31Z

The VFIndex I think would have been a good idea if initially tought (in addition to the PFName) but right now that could conflict right one may have non-overlapping pfname with "#0-2-3" part and VFIndex.

AND is performed between different selectors, so result will be consistent
It might not make sense to use the VF range notation and VFIndex selector.
there are other combinations that might not make sense.

@zshi-redhat, @martinkennelly any [additional] thoughts on this ?

Do you want to introduce a match on all PF interface names or do we need a regex for advanced matchings?
If it is about matching all PF interface names, perhaps we can just leave the name empty which indicates matching all.
If we have advanced matching cases, it looks to me that having a special notation like re{...} would provide more readability to user and less confliction with existing selectors.

Eoghan1232 · 2022-01-19T13:40:13Z

@zshi-redhat @adrianchiris @rozeps
What's the status of this PR?

zshi-redhat · 2022-01-20T01:30:51Z

@zshi-redhat @adrianchiris @rozeps What's the status of this PR?

I think we didn't get conclusion on which approach to implement or use:

VF Index selector
Regex match in PfName selector
Exhaust all PF names in PfName selector w/ defect that PF names may change in heterogeneous env, no change required

rozeps · 2022-01-20T19:43:48Z

Not sure if it can help to decide, but in our case we'd like to have a selector based on "vendor", "device", "driver", and "vfIndex" the later could have syntax like "pfnames: ["#2", "#6", "#8"] for example i.e. no regex needed only VF number.

I guess one could also want: "pfnames: ["enp66s0f0#1", "#2", "enp65s0f1"] i.e. with both, pfname only or vfIndex only.

SchSeba · 2023-12-21T08:06:23Z

Hi @rozeps any update on this PR or we can close it?

SchSeba · 2024-08-20T20:55:55Z

no update closing this one

Roxsan Payette added 2 commits May 4, 2021 10:57

Use exact match or regex for pfname selector

56532f8

fixed lint issue

969c566

martinkennelly reviewed May 27, 2021

View reviewed changes

SchSeba closed this Aug 20, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use exact match or regex for pfname selector #350

Use exact match or regex for pfname selector #350

rozeps commented May 4, 2021 •

edited

Loading

martinkennelly left a comment

martinkennelly May 27, 2021

martinkennelly May 27, 2021

rozeps May 27, 2021 •

edited

Loading

martinkennelly May 27, 2021

rozeps May 27, 2021

martinkennelly May 27, 2021

rozeps May 27, 2021 •

edited

Loading

martinkennelly commented May 31, 2021

adrianchiris commented May 31, 2021

rozeps commented May 31, 2021

martinkennelly commented May 31, 2021 •

edited

Loading

rozeps commented May 31, 2021

adrianchiris commented Jun 1, 2021

rozeps commented Jun 1, 2021

adrianchiris commented Jun 1, 2021 •

edited

Loading

rozeps commented Jun 2, 2021

adrianchiris commented Jun 2, 2021

zshi-redhat commented Jul 5, 2021

Eoghan1232 commented Jan 19, 2022

zshi-redhat commented Jan 20, 2022

rozeps commented Jan 20, 2022

SchSeba commented Dec 21, 2023

SchSeba commented Aug 20, 2024

		for _, item := range hay {
		// May be an exact match or a regex, try both.

Use exact match or regex for pfname selector #350

Use exact match or regex for pfname selector #350

Conversation

rozeps commented May 4, 2021 • edited Loading

martinkennelly left a comment

Choose a reason for hiding this comment

martinkennelly May 27, 2021

Choose a reason for hiding this comment

martinkennelly May 27, 2021

Choose a reason for hiding this comment

rozeps May 27, 2021 • edited Loading

Choose a reason for hiding this comment

martinkennelly May 27, 2021

Choose a reason for hiding this comment

rozeps May 27, 2021

Choose a reason for hiding this comment

martinkennelly May 27, 2021

Choose a reason for hiding this comment

rozeps May 27, 2021 • edited Loading

Choose a reason for hiding this comment

martinkennelly commented May 31, 2021

adrianchiris commented May 31, 2021

rozeps commented May 31, 2021

martinkennelly commented May 31, 2021 • edited Loading

rozeps commented May 31, 2021

adrianchiris commented Jun 1, 2021

rozeps commented Jun 1, 2021

adrianchiris commented Jun 1, 2021 • edited Loading

rozeps commented Jun 2, 2021

adrianchiris commented Jun 2, 2021

zshi-redhat commented Jul 5, 2021

Eoghan1232 commented Jan 19, 2022

zshi-redhat commented Jan 20, 2022

rozeps commented Jan 20, 2022

SchSeba commented Dec 21, 2023

SchSeba commented Aug 20, 2024

rozeps commented May 4, 2021 •

edited

Loading

rozeps May 27, 2021 •

edited

Loading

rozeps May 27, 2021 •

edited

Loading

martinkennelly commented May 31, 2021 •

edited

Loading

adrianchiris commented Jun 1, 2021 •

edited

Loading