Consider how Busy polling can be configured without support/intervention from the device plugin

redhat-et / afxdp-network-operator

0 stars 0 forks source link

Consider how Busy polling can be configured without support/intervention from the device plugin #4

Open maryamtahhan opened 1 year ago

maryamtahhan commented 1 year ago

Currently - the option to configure an AF_XDP socket as a busy polling socket is a privileged operation. Investigate why this is the case (does it truly need privilege, if yes then how much privilege).

The main concern here is that AF_XDP works on a per queue basis, does this really scale if a netdev has 90 AF_XDP sockets?
Does it make sense for a pod to share the AF_XDP socket fd with the device plugin? Are there any security concerns from the App POV?
Is there an alternative approach?

kot-begemot-uk commented 1 year ago

Looking at the source they are all CAP_NET_ADMIN. No idea why. Investigating.

kot-begemot-uk commented 1 year ago

The only thing which comes to mind is that the same option also controls NAPI behavior. You can very effectively DOS the machine by misconfiguring the NAPI budget and hogging the CPU in a kernel thread.