lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 15 Jan 2020 10:04:21 -0800
From:   Jay Vosburgh <>
To:     David Ahern <>
cc:     Jiri Pirko <>,
        Leon Romanovsky <>,
        Maor Gottlieb <>,
        "" <>,
        "" <>,
        "" <>,
        Saeed Mahameed <>,
        Jason Gunthorpe <>,
        Jiri Pirko <>,
        Alex Rosenbaum <>,
        "" <>,
        Mark Zhang <>,
        Parav Pandit <>
Subject: Re: Expose bond_xmit_hash function

David Ahern <> wrote:

>On 1/15/20 9:48 AM, Jiri Pirko wrote:
>>> Right now, we have one of two options:
>>> 1. One-to-one copy/paste of that bond_xmit function to RDMA.
>>> 2. Add EXPORT_SYMBOL and call from RDMA.
>>> Do you have another solution to our undesire to do copy/paste in mind?
>> I presented it in this thread.

	Having the output of bond_xmit_hash would only allow matching
the egress slave in the RDMA code to the bonding selection if the RDMA
code also peeks into the bonding internal data structures to look at

	This is true whether it's EXPORTed or duplicated.

>Something similar is needed for xdp and not necessarily tied to a
>specific bond mode. Some time back I was using this as a prototype:
>It is incomplete, but shows the intent - exporting bond_egress_slave for
>use by other code to take a bond device and return an egress leg.

	This seems much less awful, but would it make bonding a
dependency on pretty much everything?


	-Jay Vosburgh,

Powered by blists - more mailing lists