[ECOS] [Fwd: ether_demux function]

[ECOS] [Fwd: ether_demux function]

[mkhoyila]

I know that it is dropping packets because IF_QFULL(inq) is full. This
does not seem correct to me since eCos should handle more traffic than 100
packets/sec.

Is there any issue with the driver or need to turn something on to make
this happen.

Thanks.

michael

---------------------------- Original Message ----------------------------
Subject: ether_demux function
From:    mkhoyila@uci.edu
Date:    Fri, September 16, 2005 12:10 pm
To:      ecos-discuss@ecos.sourceware.org
--------------------------------------------------------------------------

Hi Gary,

Do you have any idea, why ether_demux drops packets when more than 100
packet per second are sent via the driver (with 100 packets/sec with
length of 60bytes each, no issues). Basically it only allows exactly 50
packets thru and drops the rest. Thanks.

MHK




-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] [Fwd: ether_demux function]

[Andrew Lunn]

On Fri, Sep 16, 2005 at 12:35:08PM -0700, mkhoyila@uci.edu wrote:
> I know that it is dropping packets because IF_QFULL(inq) is full. This
> does not seem correct to me since eCos should handle more traffic than 100
> packets/sec.
> 
> Is there any issue with the driver or need to turn something on to make
> this happen.
> 
> Thanks.
> 
> michael
> 
> ---------------------------- Original Message ----------------------------
> Subject: ether_demux function
> From:    mkhoyila@uci.edu
> Date:    Fri, September 16, 2005 12:10 pm
> To:      ecos-discuss@ecos.sourceware.org
> --------------------------------------------------------------------------
> 
> Hi Gary,
> 
> Do you have any idea, why ether_demux drops packets when more than 100
> packet per second are sent via the driver (with 100 packets/sec with
> length of 60bytes each, no issues). Basically it only allows exactly 50
> packets thru and drops the rest. Thanks.

You need to find out why the queue is overflowing. What is supposed to
take packets out of the queue? Why is it not? It sounds like a problem
with the transmit functions in your ethernet driver.

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: Urgent Help: ether_demux function

[mkhoyila]

Hi Gary and Andew,

I can see what the issue is, but I do not know how to solve. From my dsr I
call:

while ( !(pDevCtrl->rxBds[pDevCtrl->rxHeadIndex].status & DMA_OWN)
	(sc->funs->eth_drv->recv)(sc, pDevCtrl .....);

this loops through as long as packets are coming and I checked from
eth_drv.c the function ether_input.c is being called which calls
ether_demux.

ether_demux queue them in ip_input queue and schedule a software interrupt
for ipintr to pick up the packets in the queue. if packets are coming
beyond 100 packets/sec, then software interrupt is NOT generated and after
first 50 packets received, all are dropped. ipintr is called at the end
and at that time only first 50 packets are in the queue.

Need help please. Thanks.

Michael


> On Fri, Sep 16, 2005 at 12:35:08PM -0700, mkhoyila@uci.edu wrote:
>> I know that it is dropping packets because IF_QFULL(inq) is full. This
>> does not seem correct to me since eCos should handle more traffic than
>> 100
>> packets/sec.
>>
>> Is there any issue with the driver or need to turn something on to make
>> this happen.
>>
>> Thanks.
>>
>> michael
>>
>> ---------------------------- Original Message
>> ----------------------------
>> Subject: ether_demux function
>> From:    mkhoyila@uci.edu
>> Date:    Fri, September 16, 2005 12:10 pm
>> To:      ecos-discuss@ecos.sourceware.org
>> --------------------------------------------------------------------------
>>
>> Hi Gary,
>>
>> Do you have any idea, why ether_demux drops packets when more than 100
>> packet per second are sent via the driver (with 100 packets/sec with
>> length of 60bytes each, no issues). Basically it only allows exactly 50
>> packets thru and drops the rest. Thanks.
>
> You need to find out why the queue is overflowing. What is supposed to
> take packets out of the queue? Why is it not? It sounds like a problem
> with the transmit functions in your ethernet driver.
>
>         Andrew
>



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: Urgent Help: ether_demux function

[Roy E Richardson]

Perhaps I'm missing the point here, but when faced with an instance of a 
consisently full queue, I have been taught to investigate the process(es) 
that are to service that queue.
Given the limiting factor of 100 frames /sec. one can pretty much rule out 
CPU cycle saturation as the root problem (unless we're using a Z80 timeframe 
CPU or other really old HW),  one has to ask if the blockage is due to some 
thread priorites, or the like blocking the servicing of the queue?

what is the platform, and what is the "tick interval"

---- Original Message ----- 
From: <mkhoyila@uci.edu>
To: <ecos-discuss@ecos.sourceware.org>
Sent: Monday, September 19, 2005 5:46 PM
Subject: [ECOS] Re: Urgent Help: ether_demux function


> Hi Gary and Andew,
>
> I can see what the issue is, but I do not know how to solve. From my dsr I
> call:
>
> while ( !(pDevCtrl->rxBds[pDevCtrl->rxHeadIndex].status & DMA_OWN)
> (sc->funs->eth_drv->recv)(sc, pDevCtrl .....);
>
> this loops through as long as packets are coming and I checked from
> eth_drv.c the function ether_input.c is being called which calls
> ether_demux.
>
> ether_demux queue them in ip_input queue and schedule a software interrupt
> for ipintr to pick up the packets in the queue. if packets are coming
> beyond 100 packets/sec, then software interrupt is NOT generated and after
> first 50 packets received, all are dropped. ipintr is called at the end
> and at that time only first 50 packets are in the queue.
>
> Need help please. Thanks.
>
> Michael
>
>
>> On Fri, Sep 16, 2005 at 12:35:08PM -0700, mkhoyila@uci.edu wrote:
>>> I know that it is dropping packets because IF_QFULL(inq) is full. This
>>> does not seem correct to me since eCos should handle more traffic than
>>> 100
>>> packets/sec.
>>>
>>> Is there any issue with the driver or need to turn something on to make
>>> this happen.
>>>
>>> Thanks.
>>>
>>> michael
>>>
>>> ---------------------------- Original Message
>>> ----------------------------
>>> Subject: ether_demux function
>>> From:    mkhoyila@uci.edu
>>> Date:    Fri, September 16, 2005 12:10 pm
>>> To:      ecos-discuss@ecos.sourceware.org
>>> --------------------------------------------------------------------------
>>>
>>> Hi Gary,
>>>
>>> Do you have any idea, why ether_demux drops packets when more than 100
>>> packet per second are sent via the driver (with 100 packets/sec with
>>> length of 60bytes each, no issues). Basically it only allows exactly 50
>>> packets thru and drops the rest. Thanks.
>>
>> You need to find out why the queue is overflowing. What is supposed to
>> take packets out of the queue? Why is it not? It sounds like a problem
>> with the transmit functions in your ethernet driver.
>>
>>         Andrew
>>
>
>
>
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
> 



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: Urgent Help: ether_demux function

[mkhoyila]

I am arriving at the same conclusion.

Platform: MIPS
Ticks from support.c:

int hz = 100;
int tick = 10000;  // usec per "tick"

Thanks.

MHK

> Perhaps I'm missing the point here, but when faced with an instance of a
> consisently full queue, I have been taught to investigate the process(es)
> that are to service that queue.
> Given the limiting factor of 100 frames /sec. one can pretty much rule out
> CPU cycle saturation as the root problem (unless we're using a Z80
> timeframe
> CPU or other really old HW),  one has to ask if the blockage is due to
> some
> thread priorites, or the like blocking the servicing of the queue?
>
> what is the platform, and what is the "tick interval"
>
> ---- Original Message -----
> From: <mkhoyila@uci.edu>
> To: <ecos-discuss@ecos.sourceware.org>
> Sent: Monday, September 19, 2005 5:46 PM
> Subject: [ECOS] Re: Urgent Help: ether_demux function
>
>
>> Hi Gary and Andew,
>>
>> I can see what the issue is, but I do not know how to solve. From my dsr
>> I
>> call:
>>
>> while ( !(pDevCtrl->rxBds[pDevCtrl->rxHeadIndex].status & DMA_OWN)
>> (sc->funs->eth_drv->recv)(sc, pDevCtrl .....);
>>
>> this loops through as long as packets are coming and I checked from
>> eth_drv.c the function ether_input.c is being called which calls
>> ether_demux.
>>
>> ether_demux queue them in ip_input queue and schedule a software
>> interrupt
>> for ipintr to pick up the packets in the queue. if packets are coming
>> beyond 100 packets/sec, then software interrupt is NOT generated and
>> after
>> first 50 packets received, all are dropped. ipintr is called at the end
>> and at that time only first 50 packets are in the queue.
>>
>> Need help please. Thanks.
>>
>> Michael
>>
>>
>>> On Fri, Sep 16, 2005 at 12:35:08PM -0700, mkhoyila@uci.edu wrote:
>>>> I know that it is dropping packets because IF_QFULL(inq) is full. This
>>>> does not seem correct to me since eCos should handle more traffic than
>>>> 100
>>>> packets/sec.
>>>>
>>>> Is there any issue with the driver or need to turn something on to
>>>> make
>>>> this happen.
>>>>
>>>> Thanks.
>>>>
>>>> michael
>>>>
>>>> ---------------------------- Original Message
>>>> ----------------------------
>>>> Subject: ether_demux function
>>>> From:    mkhoyila@uci.edu
>>>> Date:    Fri, September 16, 2005 12:10 pm
>>>> To:      ecos-discuss@ecos.sourceware.org
>>>> --------------------------------------------------------------------------
>>>>
>>>> Hi Gary,
>>>>
>>>> Do you have any idea, why ether_demux drops packets when more than 100
>>>> packet per second are sent via the driver (with 100 packets/sec with
>>>> length of 60bytes each, no issues). Basically it only allows exactly
>>>> 50
>>>> packets thru and drops the rest. Thanks.
>>>
>>> You need to find out why the queue is overflowing. What is supposed to
>>> take packets out of the queue? Why is it not? It sounds like a problem
>>> with the transmit functions in your ethernet driver.
>>>
>>>         Andrew
>>>
>>
>>
>>
>> --
>> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
>> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>>
>>
>
>



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: Urgent Help: IP Stack processing priority increase

[mkhoyila]

Hi guys,

I need to know how to increase the ip stacking processing priority. I
played around with following entries but no luck so far:

Priority level for background network processing
Priority lvel for fast network processing.

Again upon enqueueing the packets, the ipintr is NOT called to dequeue.
Thanks.

Michael

> Perhaps I'm missing the point here, but when faced with an instance of a
> consisently full queue, I have been taught to investigate the process(es)
> that are to service that queue.
> Given the limiting factor of 100 frames /sec. one can pretty much rule out
> CPU cycle saturation as the root problem (unless we're using a Z80
> timeframe
> CPU or other really old HW),  one has to ask if the blockage is due to
> some
> thread priorites, or the like blocking the servicing of the queue?
>
> what is the platform, and what is the "tick interval"
>
> ---- Original Message -----
> From: <mkhoyila@uci.edu>
> To: <ecos-discuss@ecos.sourceware.org>
> Sent: Monday, September 19, 2005 5:46 PM
> Subject: [ECOS] Re: Urgent Help: ether_demux function
>
>
>> Hi Gary and Andew,
>>
>> I can see what the issue is, but I do not know how to solve. From my dsr
>> I
>> call:
>>
>> while ( !(pDevCtrl->rxBds[pDevCtrl->rxHeadIndex].status & DMA_OWN)
>> (sc->funs->eth_drv->recv)(sc, pDevCtrl .....);
>>
>> this loops through as long as packets are coming and I checked from
>> eth_drv.c the function ether_input.c is being called which calls
>> ether_demux.
>>
>> ether_demux queue them in ip_input queue and schedule a software
>> interrupt
>> for ipintr to pick up the packets in the queue. if packets are coming
>> beyond 100 packets/sec, then software interrupt is NOT generated and
>> after
>> first 50 packets received, all are dropped. ipintr is called at the end
>> and at that time only first 50 packets are in the queue.
>>
>> Need help please. Thanks.
>>
>> Michael
>>
>>
>>> On Fri, Sep 16, 2005 at 12:35:08PM -0700, mkhoyila@uci.edu wrote:
>>>> I know that it is dropping packets because IF_QFULL(inq) is full. This
>>>> does not seem correct to me since eCos should handle more traffic than
>>>> 100
>>>> packets/sec.
>>>>
>>>> Is there any issue with the driver or need to turn something on to
>>>> make
>>>> this happen.
>>>>
>>>> Thanks.
>>>>
>>>> michael
>>>>
>>>> ---------------------------- Original Message
>>>> ----------------------------
>>>> Subject: ether_demux function
>>>> From:    mkhoyila@uci.edu
>>>> Date:    Fri, September 16, 2005 12:10 pm
>>>> To:      ecos-discuss@ecos.sourceware.org
>>>> --------------------------------------------------------------------------
>>>>
>>>> Hi Gary,
>>>>
>>>> Do you have any idea, why ether_demux drops packets when more than 100
>>>> packet per second are sent via the driver (with 100 packets/sec with
>>>> length of 60bytes each, no issues). Basically it only allows exactly
>>>> 50
>>>> packets thru and drops the rest. Thanks.
>>>
>>> You need to find out why the queue is overflowing. What is supposed to
>>> take packets out of the queue? Why is it not? It sounds like a problem
>>> with the transmit functions in your ethernet driver.
>>>
>>>         Andrew
>>>
>>
>>
>>
>> --
>> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
>> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>>
>>
>
>



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: Urgent Help: ether_demux function

[Andrew Lunn]

On Mon, Sep 19, 2005 at 05:46:19PM -0700, mkhoyila@uci.edu wrote:
> Hi Gary and Andew,
> 
> I can see what the issue is, but I do not know how to solve. From my dsr I
> call:
> 
> while ( !(pDevCtrl->rxBds[pDevCtrl->rxHeadIndex].status & DMA_OWN)
> 	(sc->funs->eth_drv->recv)(sc, pDevCtrl .....);
> 
> this loops through as long as packets are coming and I checked from
> eth_drv.c the function ether_input.c is being called which calls
> ether_demux.
> 
> ether_demux queue them in ip_input queue and schedule a software interrupt
> for ipintr to pick up the packets in the queue. if packets are coming
> beyond 100 packets/sec, then software interrupt is NOT generated and after
> first 50 packets received, all are dropped. ipintr is called at the end
> and at that time only first 50 packets are in the queue.

So you need to find out why the software interrupt is not
generated. How many packets per second are you actually sending to the
device? If you are sending 10000 of 64byte packets per second it is
possible the CPU is spending all its time simply throwing away packets
and has no time to process those in the queue. 

If the problem really is your device is spending all its time throwing
stuff away rather than processing new packets what might help is to
change the order of CYGPKG_NET_THREAD_PRIORITY and
CYGPKG_NET_FAST_THREAD_PRIORITY. ie make the FAST thread lower
priority than the other thread. You should then find that the device
driver does the discard because it is always overflowing its receive
buffers and the network stack gets to process every packet it
receives.

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss