> Subject: Re: [PATCH v4 1/1] RDMA/mana_ib: Add EQ interrupt support to mana ib > driver. > > On Fri, Jul 28, 2023 at 05:51:46PM +0000, Long Li wrote: > > > Subject: Re: [PATCH v4 1/1] RDMA/mana_ib: Add EQ interrupt support > > > to mana ib driver. > > > > > > On Fri, Jul 28, 2023 at 05:07:49PM +0000, Wei Hu wrote: > > > > Add EQ interrupt support for mana ib driver. Allocate EQs per > > > > ucontext to receive interrupt. Attach EQ when CQ is created. Call > > > > CQ interrupt handler when completion interrupt happens. EQs are > > > > destroyed when ucontext is deallocated. > > > > > > It seems strange that interrupts would be somehow linked to a ucontext? > > > interrupts are highly limited, you can DOS the entire system if > > > someone abuses this. > > > > > > Generally I expect a properly functioning driver to use one interrupt per CPU > core. > > > > Yes, MANA uses one interrupt per CPU. One interrupt is shared among > > multiple EQs. > > So you have another multiplexing layer between the interrupt and the EQ? That is > alot of multiplexing layers.. > > > > You should tie the CQ to a shared EQ belong to the core that the CQ > > > wants to have affinity to. > > > > The reason for using a separate EQ for a ucontext, is for preventing > > DOS. If we use a shared EQ, a single ucontext can storm this shared EQ > > affecting other users. > > With a proper design it should not be possible. The CQ adds an entry to the EQ > and that should be rate limited by the ability of userspace to schedule to re-arm > the CQ. I think DPDK user space can sometimes storm the EQ by arming the CQ from user-mode. Please see the following code on arming the CQ from MLX4: https://github.com/DPDK/dpdk/blob/12fcafcd62286933e6b167b14856d21f642efa5f/drivers/net/mlx4/mlx4_intr.c#L229 With a malicious DPDK user, this code can be abused to arm the CQ at extremely high rate. Long
