On Mon, Jan 15, 2024, at 2:13 AM, Hrvoje Popovski wrote:
> On 2.1.2024. 21:27, Jan Klemkow wrote:
>> On Mon, Jan 01, 2024 at 07:12:31PM +0100, Mark Kettenis wrote:
>>> On amd64, we only have 240 interrupt vectors, which means they're a
>>> limited.  And unless I'm terribly confused, we're not using 48 of
>>> those because of the way we've assigned the priority levels.  And with
>>> more and more devices supporting multiple interrupt vectors, we can
>>> put these to good use.  So this diff rearranges the levels to make the
>>> additonal vectors available for use.  Since it most likely network
>>> devices that need these, I leave a gap between between IPL_NET and
>>> IPL_SOFTTTY.  That way, it will take longer for IPL_NET interrupts to
>>> spill over into the IPL_SOFTTTY range and mess up the interrupt
>>> priorities.
>>>
>>> Now I vagelue remember something about trying something like this
>>> before.  So I want to make sure this doesn't cause any problems.
>>> Therefore I'd appreciate it if people can test this, especially on
>>> machines with lots of network devices.
>> Together with the multiqueue diff for em(4) from jmatthew@ the interrupt
>> error of em18 just changed.  I guess it got some more interrupts
>> allocates, but still not enough.  Thus, also on this machine the
>> interrupt issue improves.
>> 
>> Thanks,
>> Jan
>
>
> Hi Jan,
>
> is em multiqueue diff from jmatthew@ good enough for production? It was
> working fine when I tested forwarding and I remember that you said that
> something isn't working as expected

The last time I tested it, I had success initially but later ran into this issue also:

https://marc.info/?l=openbsd-tech&m=168242217423664

I don't recall seeing a newer diff, but admittedly have not tested recently to see if something outside the diff had improved the situation.

Brian Conway