> -----Original Message-----
> From: Dave Bott [mailto:community-noreply@qnx.com]
> Sent: March-10-09 11:28 AM
> To: technology-networking
> Subject: Re: reference filter for 6.4.0 ?
> 
> That sounds like a good idea - how soon can we get it done ?
> 

Yes great idea.  I`ll make sure everyone here reads it!

> Dave
> 
> Andrew Boyd wrote:
> >
> > > receive a packet from a specific IP addres  and 'reflect'
> > > it back as fast as possible.
> >
> > We always hurt in benchmarking small packets, because
> > of the overhead of the message passing and context
> > switch between the server (stack) and the client
> > (eg ttcp).  We can do gige wire rate with ttcp, we
> > just require a larger payload size to amortize the
> > overhead.
> >
> > In the past, we have talked about creating a ttcp.so
> > dll application which would load into the stack, and
> > get rid of the context switch and message pass.  Because
> > there is no message pass through the kernel or context
> > switch, it would be very fast.  Think "fast-forwarding"
> > ttcp.
> >
> > I think that's what you want.
> >
> > --
> > aboyd
> >
> >
> > _______________________________________________
> > Technology
> > http://community.qnx.com/sf/go/post24013
> >
> 
> 
> --
> Dave Bott (dbott@qnx.com)	Field Applications Engineer
> QNX Software Systems, Inc.	Cell:408 391-3535
> San Jose CA
> 
> Join Foundry27 <http://community.qnx.com>;  - the new QNX developer
> forum.
> 
> 
> 
> _______________________________________________
> Technology
> http://community.qnx.com/sf/go/post24029
> 

Using the nraw interface will be faster since it doesn't involve sending
the packet up the stack.  It should also be somewhat faster and less
prone to jitter.

It delivers raw ethernet packets so the customer would have to set up
the appropriate byte pattern (or customize the code) to pick off the
packets that are required.  Hopefully xtang can comment on the pingd
example code (it is, I believe, code that has been written internally).

This will definitely be slower than implementing everything in the
filter since it is crossing the stack process boundary. The filter code
that's provided on the wiki covers the connection into the stack.  If
the nraw code doesn't work out, I'd say just start off using the code
example as is.  The filter point that I talked about in the previous
posting can be easily modifed later. The input / modify portion are
straight forward.  Unfortunately a "simple" example showing how to
create a transmit thread doesn't currently exist.  This is something
that is worthwhile adding to the example, but I can't commit to a time
for doing it right now.  The nraw code does have it in there, but it
obviously needs to be dug out.

	I'll also look at getting that sample code into the source
repository so that it can be checked out rather than having to do a copy
/ paste / create build environment thing.

		Robert.


-----Original Message-----
From: Dave Bott [mailto:community-noreply@qnx.com] 
Sent: Tuesday, March 10, 2009 4:14 PM
To: technology-networking
Subject: Re: RE: reference filter for 6.4.0 ?

Thanks for the replies and the information.

I'm not sure I understand enough to use the info you sent Robert.
Neither I, nor my customer, is familiar  enoughwith this code to know
what to do with the input hook that you decscribe.

However, looking at nraw, there is a sample app called 'pingd' which I
built, and ran, after first installing the nraw filter. It seems to
claim to do ping replies, as well as notice arps and IP packets. It only
has an X86 build, so I don't know if it is endian-safe - I built a PPC
and an X86 version of it anyway.

It certainly detects IP and ARP packets, but it did not seem to ping
reply correctly - leastways, pinging the box (X86 or PPC) did not get a
good reply once this was enabled. It also seems to consume all packets,
regardless of the originating IP address.

Did we write the pingd code, or test it ? Am I using it incorrectly ? It
seems like this would be a nicer way to get what the customer wants - it
must be faster via this interface surely, yet still living in a separate
process... Or is this still a bad idea ? Writing a filter looks to be a
tricky proposition...

Dave

_______________________________________________
Technology
http://community.qnx.com/sf/go/post24077

The "pingd" works for me, I double checked.

The "ip address" you passed to pingd, must be on same subnet, otherwise,
there won't be an ARP send out if it is pinged from some other node.

The "consume all packets", is also intentional. It suppose to show how
to exclusively access the packet. You can change the "open()" in pingd,
*not to* open(O_EXCL), (just O_RDWR), that way, nraw will let the packet
pass through.

If you customer also want performance, he should use a filter module
instead of nraw. 

-xtang

> -----Original Message-----
> From: Dave Bott [mailto:community-noreply@qnx.com]
> Sent: March 11, 2009 4:14 AM
> To: technology-networking
> Subject: Re: RE: reference filter for 6.4.0 ?
> 
> Thanks for the replies and the information.
> 
> I'm not sure I understand enough to use the info you sent Robert.
> Neither I, nor my customer, is familiar  enoughwith this code to know
what
> to do with the input hook that you decscribe.
> 
> However, looking at nraw, there is a sample app called 'pingd' which I
> built, and ran, after first installing the nraw filter. It seems to
claim
> to do ping replies, as well as notice arps and IP packets. It only has
an
> X86 build, so I don't know if it is endian-safe - I built a PPC and an
X86
> version of it anyway.
> 
> It certainly detects IP and ARP packets, but it did not seem to ping
reply
> correctly - leastways, pinging the box (X86 or PPC) did not get a good
> reply once this was enabled. It also seems to consume all packets,
> regardless of the originating IP address.
> 
> Did we write the pingd code, or test it ? Am I using it incorrectly ?
It
> seems like this would be a nicer way to get what the customer wants -
it
> must be faster via this interface surely, yet still living in a
separate
> process... Or is this still a bad idea ? Writing a filter looks to be
a
> tricky proposition...
> 
> Dave
> 
> _______________________________________________
> Technology
> http://community.qnx.com/sf/go/post24077