Hey folks!
I’m having some trouble with my tulip driver, in that I noticed that it
takes about a hundred microseconds longer than I have in my realtime budget
to receive packets.
It seems that at least half of this time, on average is being consumed by
tulip_AllocNpkt(). Long story short, I noticed tulip_AllocNpkt() calls
ion_alloc() and ion_alloc_npkt(). These functions don’t show up in the
online docs even though I have the net ddk loaded.
I’m wondering if anyone knows if they call malloc() or a variant?
Thanks!
Chris
BPC Software Group <bpc_sw@hotmail.com> wrote:
: Hey folks!
: I’m having some trouble with my tulip driver, in that I noticed that it
: takes about a hundred microseconds longer than I have in my realtime budget
: to receive packets.
: It seems that at least half of this time, on average is being consumed by
: tulip_AllocNpkt(). Long story short, I noticed tulip_AllocNpkt() calls
: ion_alloc() and ion_alloc_npkt(). These functions don’t show up in the
: online docs even though I have the net ddk loaded.
: I’m wondering if anyone knows if they call malloc() or a variant?
They may call mmap() if they don’t have a cached entry.
-seanb
Sean Boudreau <seanb@qnx.com> wrote in message
news:9vact3$pqj$2@nntp.qnx.com…
BPC Software Group <> bpc_sw@hotmail.com> > wrote:
: Hey folks!
: I’m having some trouble with my tulip driver, in that I noticed that it
: takes about a hundred microseconds longer than I have in my realtime
budget
: to receive packets.
: It seems that at least half of this time, on average is being consumed
by
: tulip_AllocNpkt(). Long story short, I noticed tulip_AllocNpkt() calls
: ion_alloc() and ion_alloc_npkt(). These functions don’t show up in the
: online docs even though I have the net ddk loaded.
: I’m wondering if anyone knows if they call malloc() or a variant?
They may call mmap() if they don’t have a cached entry.
-seanb
Is anyone aware of a way to compile the tulip driver that would have it
allocate all the
packets it needs upon startup? Our system requires much higher performance
than we
can currently get from the existing driver and io-net stack.
Thanks!
Chris
Sean Boudreau <seanb@qnx.com> wrote in message
news:9vact3$pqj$2@nntp.qnx.com…
BPC Software Group <> bpc_sw@hotmail.com> > wrote:
: Hey folks!
: I’m having some trouble with my tulip driver, in that I noticed that it
: takes about a hundred microseconds longer than I have in my realtime
budget
: to receive packets.
: It seems that at least half of this time, on average is being consumed
by
: tulip_AllocNpkt(). Long story short, I noticed tulip_AllocNpkt() calls
: ion_alloc() and ion_alloc_npkt(). These functions don’t show up in the
: online docs even though I have the net ddk loaded.
: I’m wondering if anyone knows if they call malloc() or a variant?
They may call mmap() if they don’t have a cached entry.
-seanb
I have another idea. In receive.c, in …DoRx() where the call to
tulip_AllocNpkt is called, the result, “new” ( lousy name for a
variable… ) is not used until the end of the function. I’m thinking about
factoring this …AllocNpkt() call until after the current packet, npkt, is
passed up the stack. I realize that I have to still set the “I want my
packet back NOW” flag, if neccessary first, but I don’t have to make the
call to alloc until later, just before the result is needed.
Anyboday see any problems with my theory?
Thanks!
Chris
Actually, what many of the drivers do is keep a cache of pre-allocated
packets on a queue and simply pop the packets from this local data
structure when new packet data is required.
chris
BPC Software Group <bpc_sw@hotmail.com> wrote:
Sean Boudreau <> seanb@qnx.com> > wrote in message
news:9vact3$pqj$> 2@nntp.qnx.com> …
BPC Software Group <> bpc_sw@hotmail.com> > wrote:
: Hey folks!
: I’m having some trouble with my tulip driver, in that I noticed that it
: takes about a hundred microseconds longer than I have in my realtime
budget
: to receive packets.
: It seems that at least half of this time, on average is being consumed
by
: tulip_AllocNpkt(). Long story short, I noticed tulip_AllocNpkt() calls
: ion_alloc() and ion_alloc_npkt(). These functions don’t show up in the
: online docs even though I have the net ddk loaded.
: I’m wondering if anyone knows if they call malloc() or a variant?
They may call mmap() if they don’t have a cached entry.
-seanb
I have another idea. In receive.c, in …DoRx() where the call to
tulip_AllocNpkt is called, the result, “new” ( lousy name for a
variable… ) is not used until the end of the function. I’m thinking about
factoring this …AllocNpkt() call until after the current packet, npkt, is
passed up the stack. I realize that I have to still set the “I want my
packet back NOW” flag, if neccessary first, but I don’t have to make the
call to alloc until later, just before the result is needed.
Anyboday see any problems with my theory?
Thanks!
Chris
\
–
cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Can you provide the source for one of the drivers that does this?
Thanks!
Chris
Chris McKillop <cdm@qnx.com> wrote in message
news:9ve84n$kes$2@nntp.qnx.com…
Actually, what many of the drivers do is keep a cache of pre-allocated
packets on a queue and simply pop the packets from this local data
structure when new packet data is required.
chris
BPC Software Group <> bpc_sw@hotmail.com> > wrote:
Sean Boudreau <> seanb@qnx.com> > wrote in message
news:9vact3$pqj$> 2@nntp.qnx.com> …
BPC Software Group <> bpc_sw@hotmail.com> > wrote:
: Hey folks!
: I’m having some trouble with my tulip driver, in that I noticed that
it
: takes about a hundred microseconds longer than I have in my realtime
budget
: to receive packets.
: It seems that at least half of this time, on average is being
consumed
by
: tulip_AllocNpkt(). Long story short, I noticed tulip_AllocNpkt()
calls
: ion_alloc() and ion_alloc_npkt(). These functions don’t show up in
the
: online docs even though I have the net ddk loaded.
: I’m wondering if anyone knows if they call malloc() or a variant?
They may call mmap() if they don’t have a cached entry.
-seanb
I have another idea. In receive.c, in …DoRx() where the call to
tulip_AllocNpkt is called, the result, “new” ( lousy name for a
variable… ) is not used until the end of the function. I’m thinking
about
factoring this …AllocNpkt() call until after the current packet, npkt,
is
passed up the stack. I realize that I have to still set the “I want my
packet back NOW” flag, if neccessary first, but I don’t have to make the
call to alloc until later, just before the result is needed.
Anyboday see any problems with my theory?
Thanks!
Chris
\
cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL