lists.openwall.net | 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
| ||
|
Date: Wed, 15 Jan 2020 21:46:28 +0100 From: Jiri Pirko <jiri@...nulli.us> To: David Ahern <dsahern@...il.com> Cc: Jay Vosburgh <jay.vosburgh@...onical.com>, Leon Romanovsky <leonro@...lanox.com>, Maor Gottlieb <maorg@...lanox.com>, "vfalico@...il.com" <vfalico@...il.com>, "andy@...yhouse.net" <andy@...yhouse.net>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, Saeed Mahameed <saeedm@...lanox.com>, Jason Gunthorpe <jgg@...lanox.com>, Jiri Pirko <jiri@...lanox.com>, Alex Rosenbaum <alexr@...lanox.com>, "davem@...emloft.net" <davem@...emloft.net>, Mark Zhang <markz@...lanox.com>, Parav Pandit <parav@...lanox.com> Subject: Re: Expose bond_xmit_hash function Wed, Jan 15, 2020 at 07:12:54PM CET, dsahern@...il.com wrote: >On 1/15/20 11:04 AM, Jay Vosburgh wrote: >> >>> 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: >>> >>> https://github.com/dsahern/linux/commit/2714abc1e629613e3485b7aa860fa3096e273cb2 >>> >>> 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? >> > >The intent is to hide the bond details beyond the general "a bond has >multiple egress paths and we need to pick one". ie., all of the logic >and data structures are still private. > >Exporting the function for use by modules is the easy part. > >Making it accessible to core code (XDP) means ??? Obviously not a >concern when bond is built in but the usual case is a module. One >solution is to repeat the IPv6 stub format; not great from an indirect >call perspective. I have not followed the work on INDIRECT_CALL to know >if that mitigates the concern about the stub when bond is a module. Why it can't be an ndo as I previously suggested in this thread? It is not specific to bond, others might like to fillup this ndo too (team, ovs, bridge).
Powered by blists - more mailing lists