Jump to ID:
Networking

Project Home

Discussions

Wiki

Project Info
Forum Topic - Porting guide from io-net to io-pkt (and back!) ?: (7 Items)
   
 
 
Porting guide from io-net to io-pkt (and back!) ?  
Is there a porting guide so I can run a driver without a shim ?

I want to run the gt64260 driver natively in io-pkt to get maximum performance at lowest CPU usage.

Is there a document ? I couldn't find one, but maybe I missed it ?

Dave
RE: Porting guide from io-net to io-pkt (and back!) ?  
Hi Dave:
	Unfortunately, there isn't a "replace x with y" type of doc.
There are some generic notes on how to create a native driver here:

http://community.qnx.com/integration/viewcvs/viewcvs.cgi/trunk/sys/dev_q
nx/doc/?root=core_networking&system=exsy1001

We'll be beefing those up as we get more people involved with writing
the native drivers.

	Robert.

-----Original Message-----
From: Dave Bott [mailto:community-noreply@qnx.com] 
Sent: Tuesday, November 25, 2008 3:54 PM
To: drivers-networking
Subject: Porting guide from io-net to io-pkt (and back!) ?

Is there a porting guide so I can run a driver without a shim ?

I want to run the gt64260 driver natively in io-pkt to get maximum
performance at lowest CPU usage.

Is there a document ? I couldn't find one, but maybe I missed it ?

Dave

_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post17309
RE: Porting guide from io-net to io-pkt (and back!) ?  
> "replace x with y" 

There's an idea.  Anyways, here is a brief
overview of what you need to know:

1) you transmit and receive mbufs, not npkts

2) the transmit routine, really weirdly, is
   called fubar_start().
 
3) initialization is different.  Your dll
   fubar_entry() calls up into the stack with
   dev_attach() which in turn calls back down
   to the driver fubar_attach() function once
   for each hardware instance.  fubar_init()
   may be called over and over again.  This is
   very different from io-net.  You MUST ensure
   that fubar_init() is safe to call over and
   over again.

4) io-pkt drivers don't create threads - you
   want to always run as a "stack thread".  Use
   the stack timer callouts for periodic wakeup.
 
5) ensure that your driver registers for shutdown
   to avoid systems hangs after io-pkt faults - 
   you must quiesce the hardware to avoid memory
   corruption.

--
aboyd
RE: Porting guide from io-net to io-pkt (and back!) ?  
> create an io-pkt driver 

It is worth mentioning that the BIG difference
between running an io-net driver with the shim
and a native io-pkt driver, is that you get rid
of the thread switch on packet receive.

Experimentation has shown that on a fast cpu on 
100mbit ethernet, you will see the same throughput 
with both, and also very low cpu utilitization 
with both.

Only if you are pushing gige, or are running on a 
slow cpu, does this thread switch become noticeable.

Ok, there's also the conversion between npkts and
mbufs, but that's pretty hard to notice from either
a throughput or cpu utilitization standpoint.

--
aboyd
Re: Porting guide from io-net to io-pkt (and back!) ?  
Thanks Guys. So, would it be a good idea to take an existing, ported 
driver and compare the io-net and io-pkt versions to best understand how 
to migrate ?
Is there a recommended 'good' driver to start with ?

Dave

Andrew Boyd wrote:
>
> > create an io-pkt driver
>
> It is worth mentioning that the BIG difference
> between running an io-net driver with the shim
> and a native io-pkt driver, is that you get rid
> of the thread switch on packet receive.
>
> Experimentation has shown that on a fast cpu on
> 100mbit ethernet, you will see the same throughput
> with both, and also very low cpu utilitization
> with both.
>
> Only if you are pushing gige, or are running on a
> slow cpu, does this thread switch become noticeable.
>
> Ok, there's also the conversion between npkts and
> mbufs, but that's pretty hard to notice from either
> a throughput or cpu utilitization standpoint.
>
> --
> aboyd
>
>
> _______________________________________________
> Networking Drivers
> http://community.qnx.com/sf/go/post17314
>


-- 
Dave Bott (dbott@qnx.com)	Field Applications Engineer 
QNX Software Systems, Inc.	Voice: 408-879-7230 
900 E. Hamilton Ave #100	Fax:408-879-7221 
Campbell CA 95008		Cell:408 391-3535

Join Foundry27 <http://community.qnx.com>;  - the new QNX developer forum. 

RE: Porting guide from io-net to io-pkt (and back!) ?  
> Is there a recommended 'good' driver

To compare io-net vs io-pkt:

  for PCI: i82544
  for non-PCI: mpc85xx

Note that io-net and io-pkt drivers are not identical - 
since the source was split off for io-pkt, there may
have been substantial changes to the driver.

This is far more for the i82544 than the mpc85xx.

--
aboyd
RE: Porting guide from io-net to io-pkt (and back!) ?  
Note 1) Both of the i82544 and mpc85xx drivers 
are gige, and descriptor-based.  I cannot imagine
why anyone would port a driver to io-pkt that
was only 10/100, or had a shared-memory packet
architecture.

Note 2) rather uniquely, the i82544 hardware
has a reliable link state change interrupt, 
and thusly does not poll the PHY the way almost
all the other drivers do (like the mpc85xx).

For polling the PHY, we use our own tried and
true libdrvr (source in the io-pkt tree), not
the BSD mii code, although there is code to
hook into just enough of that stuff to make
the ifconfig media stuff work - see bsd_media.c
for any io-pkt driver, as to how to do this.

--
aboyd