i will try to have another look at this tomorrow. i am too tired tonight. :)
Sent from my iPhone
> On Oct 2, 2016, at 12:45 PM, Saso Kiselkov 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_r
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
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 wrote:
>
> I'm willing to test anything you suggest.
>
> --
> Saso
>
>> On 10/2/16 10
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
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 wrote:
>
> Thanks for the suggestions! Results below:
>
>> On 10/2/16 7:20 PM, Garrett D'Amore 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 14
You could also try benchmarking with 'fio' tool, where you have some more
control over the benchmark.
I’m also having some troubles with iSCSI performance, where I can get up to
3GB/s with local tests, but can’t go over 500MB/s via network (10gbit, latency
is minimal, since both servers are on
Yuck. This driver does the loan up thing … which is ugly and pointless on
“modern” gigE hardware, bcopy is faster. Especially as this driver is
probably only ever used with 1500 byte frames (it cannot do conventional
jumbo frames, but can do frames up to 7k… which is just bizarre!) It looks
like
Let me take a look.
On Sun, Oct 2, 2016 at 5:23 AM, Saso Kiselkov
wrote:
> Well what I know so far is that after a fixed number of packets
> (probably after filling up the RX ring), we get a storm of
> RX_FIFO_OVERFLOW_INT | NO_RXDESC_INT interrupts, probably because the
> adapter is telling us
Well what I know so far is that after a fixed number of packets
(probably after filling up the RX ring), we get a storm of
RX_FIFO_OVERFLOW_INT | NO_RXDESC_INT interrupts, probably because the
adapter is telling us that it filled up the RX ring and we didn't let it
know that we dequeued the old pac
10 matches
Mail list logo
