Project Home
Project Home		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
Networking/Discussion/io-net migration/Sending down packets from separate thread/List of Posts
Forum Topic - Sending down packets from separate thread: (9 Items)
   
Update
Peter Engstrom
09/12/2008 9:27 AM
post13325
Sending down packets from separate thread   
Hi,

in io-net it was possible to register a filter/module which would
create a thread that could receive packets via ipc and then
send these down to the driver. The thread would receive the packet,
allocate an npkt, copy the data into it, register to have the npkt
freed using reg_tx_done and then call tx_down which would send the
packet down to the driver.

In io-pkt I wonder if this is feasible? We want to use ipc and not
socket. Sending packets down in io-pkt seems to be limited to work
threads only and it looks like there is no way of allocating mbufs for
non-work threads.

Registering a callout which would run in work-thread context and
thus would be able to allocate mbufs, unfortunately can only be
triggered every 8.39 ms and so it is too slow for our needs.

Thankful for any help or ideas,
Peter Engstrom
Prisma Engineering
Sean Boudreau(deleted)
09/12/2008 10:11 AM
post13333
Re: Sending down packets from separate thread   
On Fri, Sep 12, 2008 at 09:27:54AM -0400, Peter Engstrom wrote:
> Hi,
> 
> in io-net it was possible to register a filter/module which would
> create a thread that could receive packets via ipc and then
> send these down to the driver. The thread would receive the packet,
> allocate an npkt, copy the data into it, register to have the npkt
> freed using reg_tx_done and then call tx_down which would send the
> packet down to the driver.
> 
> In io-pkt I wonder if this is feasible? We want to use ipc and not
> socket. Sending packets down in io-pkt seems to be limited to work
> threads only and it looks like there is no way of allocating mbufs for
> non-work threads.
> 
> Registering a callout which would run in work-thread context and
> thus would be able to allocate mbufs, unfortunately can only be
> triggered every 8.39 ms and so it is too slow for our needs.
> 
> Thankful for any help or ideas,
> Peter Engstrom
> Prisma Engineering
> 

You can create a work thread with nw_pthread_create() that
can allocate mbufs.  You can do this as part of an lsm
entry point.  However, bpf / libpcap might also do what you
want (sending raw packets).

-seanb
Peter Engstrom
09/12/2008 10:42 AM
post13338
Re: Sending down packets from separate thread   
Thanks,

this looks like what I need.

Peter
Peter Engstrom
09/15/2008 12:45 PM
post13431
Re: Sending down packets from separate thread   
Hi,

I created a thread with nw_pthread_create and it works fine for
allocating mbufs and sending packets etc. I would also like to be able
to remove it but this seems to be trickier. I created the thread as
part of a driver entry point and thought/hoped I would be able to
remove it using:

ifconfig myintf0 destroy

That command would trigger the following code in
sys/net/if.c:

...
		if (cmd == SIOCIFDESTROY) {
			/* Settle threads down */
			quiesce_all();

			/*
			 * Allow any interface that has supports detach
			 * to be taken out.  detach has precedence over
			 * a clone destroy func.
			 */
			if ((ifp = ifunit(ifr->ifr_name)) == NULL ||
			    (error = dev_detach_name(ifp->if_xname, DETACH_FORCE)) != EOK) {
				error = if_clone_destroy(ifr->ifr_name);
			}

			unquiesce_all();
...

However, this code will not let me remove the thread using
nw_pthread_reap() called from my detach function because of the
quiesce_all() and unquiesce_all() calls. Is there something I'm
missing or is the code just not designed for what I would
like to do?

Best regards,
Peter Engstrom
Weijie Zhang(deleted)
09/15/2008 3:11 PM
post13446
RE: Sending down packets from separate thread   
You may check the ppp code to get the idea how to cancel a thread.

Thanks
Weijie

-----Original Message-----
From: Peter Engstrom [mailto:community-noreply@qnx.com] 
Sent: September 15, 2008 12:45 PM
To: ionetmig-networking
Subject: Re: Sending down packets from separate thread

Hi,

I created a thread with nw_pthread_create and it works fine for
allocating mbufs and sending packets etc. I would also like to be able
to remove it but this seems to be trickier. I created the thread as
part of a driver entry point and thought/hoped I would be able to
remove it using:

ifconfig myintf0 destroy

That command would trigger the following code in
sys/net/if.c:

...
		if (cmd == SIOCIFDESTROY) {
			/* Settle threads down */
			quiesce_all();

			/*
			 * Allow any interface that has supports detach
			 * to be taken out.  detach has precedence over
			 * a clone destroy func.
			 */
			if ((ifp = ifunit(ifr->ifr_name)) == NULL ||
			    (error = dev_detach_name(ifp->if_xname,
DETACH_FORCE)) != EOK) {
				error = if_clone_destroy(ifr->ifr_name);
			}

			unquiesce_all();
...

However, this code will not let me remove the thread using
nw_pthread_reap() called from my detach function because of the
quiesce_all() and unquiesce_all() calls. Is there something I'm
missing or is the code just not designed for what I would
like to do?

Best regards,
Peter Engstrom

_______________________________________________
io-net migration
http://community.qnx.com/sf/go/post13431
Peter Engstrom
09/16/2008 4:37 AM
post13454
Re: RE: Sending down packets from separate thread   
Hi,

I can see how the code is designed. PPP ioctl calls nw_pthread_reap()
which in turn calls quiesce_force_exit(). This will call the
quiesce callout with die set to 1 which will make the thread exit.

The problem remains, though. There is no way in io-pkt to remove
a thread I created. With 'ifconfig ... destroy' the code doesn't permit
me to remove the thread. The quiesce_all()/unquiesce_all() calls will not 
allow me to call nw_pthread_reap().

Best regards,
Peter Engstrom
Sean Boudreau(deleted)
09/16/2008 11:45 AM
post13488
Re: RE: Sending down packets from separate thread   
On Tue, Sep 16, 2008 at 04:37:07AM -0400, Peter Engstrom wrote:
> Hi,
> 
> I can see how the code is designed. PPP ioctl calls nw_pthread_reap()
> which in turn calls quiesce_force_exit(). This will call the
> quiesce callout with die set to 1 which will make the thread exit.
> 
> The problem remains, though. There is no way in io-pkt to remove
> a thread I created. With 'ifconfig ... destroy' the code doesn't permit
> me to remove the thread. The quiesce_all()/unquiesce_all() calls will not 
> allow me to call nw_pthread_reap().

You've tickled an unforeseen usage scenario.  I moved
the quiesce further down into dev_detach() and made it
dependent on a new DVF_QUIESCESELF flag.  I still quiesce
around ifdetach() but this should allow you to quiesce()
unquiesce(), reap() in your detach callout.

dev_attach(,, &devp)
devp->dv_flags |= DVF_QUIESCESELF;

...
...

-seanb
Peter Engstrom
09/17/2008 11:50 AM
post13572
Re: RE: Sending down packets from separate thread   
Hi,

I am now able to mount and "ifconfig ... destroy" my module. I
couldn't 'svn update' to the latest code in trunk since it seems to be
unstable (io-pkt sigsegvs as soon as I issue an ifconfig
command). However, I was able to patch in your quiesce code to the
somewhat old version of core_networking I'm compiling (svn rev. 430)
and that seems to work.

This will save us a lot of work. Many thanks for adding that code.

Regards,
Peter Engstrom
Sean Boudreau(deleted)
09/17/2008 12:14 PM
post13573
Re: RE: Sending down packets from separate thread   
On Wed, Sep 17, 2008 at 11:50:15AM -0400, Peter Engstrom wrote:
> Hi,
> 
> I am now able to mount and "ifconfig ... destroy" my module. I
> couldn't 'svn update' to the latest code in trunk since it seems to be
> unstable (io-pkt sigsegvs as soon as I issue an ifconfig
> command). However, I was able to patch in your quiesce code to the
> somewhat old version of core_networking I'm compiling (svn rev. 430)
> and that seems to work.
> 
> This will save us a lot of work. Many thanks for adding that code.
> 

Make sure you do a clean build: struct _iopkt_inter changed
recently.

-seanb

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems