>Hey Willy, > >> - Interrupt steering needs to be controlled by block-mq instead of >> the driver. It's pointless to have each driver implement its own >> policies on interrupt steering, irqbalanced remains a source of >> end-user frustration, and block-mq can change the queue<->cpu mapping >> without the driver's knowledge. > >I honestly don't think that block-mq is the right place to >*assign* interrupt steering. Not all HW devices are dedicated >to storage, take RDMA for example, a RNIC is shared by block >storage, networking and even user-space workloads so obviously >block-mq can't understand how a user wants to steer interrupts. > >I think that block-mq needs to ask the device driver: >"what is the optimal queue index for cpu X?" and use it >while *someone* will be responsible for optimum interrupt >steering (can be the driver itself or user-space). +0.5 on block-mq asking lower layer on where to place the queue. However, I think it is better that the lower layer push up the data rather the block-mq asking for it. User can change or irqbalance can relocate the interrupt vector(s) during runtime. For Qlogic adapter, it can act in both Initiator & Target Modes at the same time. Certain target vendor might not wants the initiator side to holding this knob. > > From some discussions I had with HCH I think he intends to >use the cpu reverse-mapping API to try and do what's described >above (if I'm not mistaken). >_______________________________________________ >Lsf mailing list >Lsf@xxxxxxxxxxxxxxxxxxxxxxxxxx >https://lists.linuxfoundation.org/mailman/listinfo/lsf ��.n��������+%������w��{.n�����{����n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
