dpdk-devbind.py ./. bonding interfaces

Message ID YrZE/aZN09zSDMCr@priv-mua (mailing list archive)
State Changes Requested, archived
Delegated to: Thomas Monjalon
Headers
Series dpdk-devbind.py ./. bonding interfaces |

Checks

Context Check Description
ci/Intel-compilation success Compilation OK
ci/intel-Testing success Testing PASS
ci/iol-intel-Performance success Performance Testing PASS
ci/iol-intel-Functional success Functional Testing PASS
ci/iol-aarch64-compile-testing success Testing PASS
ci/iol-aarch64-unit-testing success Testing PASS
ci/github-robot: build success github build: passed
ci/iol-x86_64-compile-testing success Testing PASS
ci/iol-x86_64-unit-testing success Testing PASS
ci/iol-abi-testing success Testing PASS

Commit Message

qcqx-obaq.6cba8489@hashmail.org June 24, 2022, 11:13 p.m. UTC
  To whom it may concern.

usertools/dpdk-devbind.py currently does not recognize interfaces 
that are part of a bond as active.
that can be a nuisance if you are using something like libmoon which
proactively rebinds drivers for all "not active" interfaces.

yes, i am aware of the dpdk contribution guideline. 

no, i am not going to jump through linux-kernel level hoops for
a trivial 9-sloc-python driveby-contrib.

yes, that glorious code is all written by me, i promise i didnt
steal it, and whoever takes pity and merges it is free to claim
full credits for it.
(if you feel bad about claiming credits for something you didnt
 write, perhaps find more useful names for "f" and "l" and/or
 add some comment above it...)

yes, i promise i will read and respect the contrib guide if i ever
want to contrib code that took longer to write than it takes to
read the contrib guide.

regards,
   x23
  

Comments

Stephen Hemminger June 29, 2022, 2:09 a.m. UTC | #1
On Sat, 25 Jun 2022 01:13:01 +0200
qcqx-obaq.6cba8489@hashmail.org wrote:

> To whom it may concern.
> 
> usertools/dpdk-devbind.py currently does not recognize interfaces 
> that are part of a bond as active.
> that can be a nuisance if you are using something like libmoon which
> proactively rebinds drivers for all "not active" interfaces.
> 
> yes, i am aware of the dpdk contribution guideline. 
> 
> no, i am not going to jump through linux-kernel level hoops for
> a trivial 9-sloc-python driveby-contrib.
> 
> yes, that glorious code is all written by me, i promise i didnt
> steal it, and whoever takes pity and merges it is free to claim
> full credits for it.
> (if you feel bad about claiming credits for something you didnt
>  write, perhaps find more useful names for "f" and "l" and/or
>  add some comment above it...)
> 
> yes, i promise i will read and respect the contrib guide if i ever
> want to contrib code that took longer to write than it takes to
> read the contrib guide.
> 
> regards,
>    x23

Sounds like a libmoon bug, not a DPDK bug. 

There are many more types of joined devices in Linux, and just doing
bonding seems wrong.

Also, since your patch is missing Signed-off-by with a valid name,
it can not be accepted.
  

Patch

diff --git a/usertools/dpdk-devbind.py b/usertools/dpdk-devbind.py
index 4d9c1be666..d02552de33 100755
--- a/usertools/dpdk-devbind.py
+++ b/usertools/dpdk-devbind.py
@@ -244,6 +244,16 @@  def get_device_details(devices_type):
             if rt_info[i] == "dev":
                 ssh_if.append(rt_info[i + 1])
 
+        bdir = "/proc/net/bonding"
+        if os.path.exists(bdir):
+            for bn in os.listdir(bdir):
+                f = open(os.path.join(bdir, bn))
+                bs = f.read()
+                f.close()
+                for l in bs.splitlines():
+                    if l[:17] == "Slave Interface: ":
+                        ssh_if.append(l[17:])
+
     # based on the basic info, get extended text details
     for d in devices.keys():
         if not device_type_match(devices[d], devices_type):