[OmniOS-discuss] [discuss] Re: [networking] rge_intr troubles

[Saso Kiselkov]

But we already do an rge_receive on receiving NO_RXDESC_INT. The code
sequence is:

 1) get interrupt status word (line 1479)
 2) if interrupt is RX_FIFO_OVERFLOW_INT, modify int_mask variable to
    exclude further RX_FIFO_OVERFLOW_INT (line 1488)
 3) otherwise if interrupt contains NO_RXDESC_INT (among other things),
    modify int_mask to include RX_FIFO_OVERFLOW_INT (line 1495)
 4) if interrupt contains NO_RXDESC_INT (among other things), do
    rge_receive (line 1510)
 ...
 5) update interrupt mask according to steps 2 & 3.

So after receiving the interrupt, the first thing we pretty much do is
rge_receive anyway. I'm sorry I can't be of more help here, but this is
all completely foreign to me. I suspect the problem has more to do with
the fact that we never really properly dequeue packets from the RX ring,
so once the NIC runs out of descriptors, it just keeps on notifying us
that it needs more RX descriptors. The reason I think is that this
problem appears to be triggered strictly by the number of packets received.

-- 
Saso

On 10/2/16 10:37 PM, Garrett D'Amore wrote:
> so do the rx logic first even if the fifo overflow is set.  im not in front of the code but refer to the if-else block I referenced earlier. 
> 
> Sent from my iPhone
> 
>> On Oct 2, 2016, at 1:32 PM, Saso Kiselkov <skiselkov.ml at gmail.com> wrote:
>>
>> I'm willing to test anything you suggest.
>>
>> -- 
>> Saso
>>
>>> On 10/2/16 10:09 PM, Garrett D'Amore wrote:
>>> ah so maybe we need to change the logic so that the exhaustion of descriptors takes precedence over the rx fifo overrun.  
>>>
>>> Sent from my iPhone
>>>
>>>> On Oct 2, 2016, at 12:45 PM, Saso Kiselkov <skiselkov.ml at gmail.com> wrote:
>>>>
>>>> Thanks for the suggestions! Results below:
>>>>
>>>>> On 10/2/16 7:20 PM, Garrett D'Amore wrote:
>>>>> But as a first test, you can try calling rge_receive().  The simplest
>>>>> way I can see to do that is to OR in the value of RGE_NO_RXDESC_INT in
>>>>> the check at 1495. (Btw the ordering of the checks at 1488 and 1495 are
>>>>> suboptimal, as the rx interrupt should be the *hot* code path.
>>>>
>>>> Sadly, this won't help. RGE_RX_INT is already a composite of
>>>> RX_OK_INT | RX_ERR_INT | NO_RXDESC_INT
>>>>
>>>>> One thing you might also try doing is changing the value in rge.h for
>>>>> RGE_RECV_COPY_SIZE from 256 to something much larger — 8000 will be
>>>>> larger than the largest possible rge frame.  I have a theory that part
>>>>> of the problem you are encountering may be due to being out of buffers
>>>>> to loan up, and the screwy handling for that case.
>>>>
>>>> Tried this, but to no avail. It still goes into the sad place. Sadly,
>>>> this stupid box doesn't even have a serial port with which I could
>>>> provide you access. And I'm out of PCI-e slots to shove in an Intel NIC,
>>>> so the on-board Realtek POS is my last option. Well that, or using Linux
>>>> with Illumos as a KVM on top of it, but even saying that out loud leaves
>>>> a bad taste in my mouth...
>>>>
>>>> Cheers,
>>>> --
>>>> Saso
>>
>>
> 
> 
> -------------------------------------------
> illumos-discuss
> Archives: https://www.listbox.com/member/archive/182180/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/182180/22722377-e9306e56
> Modify Your Subscription: https://www.listbox.com/member/?member_id=22722377&id_secret=22722377-08ac87bf
> Powered by Listbox: http://www.listbox.com
>