Sorry, I sent the last mail by mistake, it has not been finished. So
the story continues here:)
The changed cap_rtbuffer is like:
void cap_rtbuffer(struct rt-buffer *abuffer, int
buffer_size, struct cap_struct *aCap)
{
if(aCap->buffer_size != buffer_size)
//print error msg and return
else{
//allocate a compensating buffer from the cap pool
if(failed)
//out of memory failure and return
//assign comp buffer to abuffer
// stamp the time
//put the buffer to the queue as captured packet
}
}
> > >>At least for RTnet, capturing is a debugging feature you don't what
> > >>compiled in for production systems. It adds overhead to some critical
> > >>paths that may hurt on low-end boxes.
> > >>
> > >
> > > I dont think the overhead is noticable. When the base module (say
> > > RTDM) has capturing option enabled, the only overhead that happens to
> > > applications that do NOT need capturing is, in the free_rtbuffer
> > > function, the extra checking of a rt-buffer's cap_struct pointer.
> >
> > Well, the current kfree_rtskb in RTnet has to do more. It iterates over
> > all rtskbs in a (possible) chain and checks for each if it is a captured
> > one. Anyway, this needless overhead in the capturing-compiled-in-but-
> > not-used case can be avoided with a simple check before entering any
> > loop. So, you are likely right, the overhead is acceptable - and could
> > still be reduced when we add a CONFIG_switch to RTDM.
> >
> > Apropos chains: does RT-FireWire's rtpk support them? If we drag
> > capturing into the core service layer, this is required.
> >
Yes, chaining will be supported also. Not yet in current RT-FireWire's
rtpkb module, but will be a new feature.
> > >
> > >
> > >>The question to me is then what functionality of the capturing subsystem
> > >>could be moved to RTDM while still keeping the control of using it or
> > >>not (without runtime costs) at the configuration level of the driver
> > >>using it. I would like to be able to switch capturing off during "make
> > >>menuconfig" of RTnet, but maybe switching it on for RT-FireWire at the
> > >>same time.
> > >>
> > >
> > > The capturing I am proposing is conceptually different from the
> > > capturing in RTnet (what I understood). It is fully oriented to
> > > applications, while RTnet's capturing is more or less per networking
> > > interface. That means in this new capturing service, buffer capturing
> > > can happen /anywhere/, even something totally away from network
> > > transaction. This is especially useful when we develop multiple
> > > applications over /one/ FireWire interface: we may only want to
> > > capture buffers used by one high-level application. Besides FireWire
> >
> > I may not know my own code well enough, but I don't see a reason why
> > setting the capturing mark in RTnet should not be movable, also away
> > from the general places where it is right now.
> >
Em...I would like to know more about this: how to move the capturing
mark in RTnet from where it is now? Now, I see it only happens when
packets is transmitted or received.
> > > and Ethernet, other applications based on RTDM, like socketCAN, can
> > > also benefit from this service, as long as they need some analysis
> > > over the used memory to gain some insight to the system behavior.
> >
> > I had Socket-CAN in mind as well first, but Sebastian's implementation
> > is smartly not using discrete CAN-packet buffers. Rather, there are ring
> > buffers per receiving socket. This is more efficient than throwing
> > around 8 bytes data + some bytes head per CAN frame in individual
> > packets. CAN packets are too small to justify the maintenance costs of
> > skb-like approaches - that's at least my strong believe (but we should
> > soon be able to do some benchmarks on this as well - there is a Linux
> > skb-based variant on the way).
> >
> > Anyway, one may consider if "external" users of the rt-packet capturing
> > services make sense as well. But that's more kind of a second or third step.
> >
> > >
> > > BTW, are you going to work on these soon, at least the memory
> > > management part? How can I contribute? My idea is to make RTDM
> >
> > My plan was to burden much of the development on you, as my time is more
> > than just limited. ;)
> >
> > Well, I have no fixed schedule, but I guess things will move quickly as
> > soon as we have some API and data structures.
> >
> > > temporarily a separate module that can be compiled over xenomai, and
> > > put it either on RTnet svn or RT-FireWire svn.
> >
> > I wouldn't drag the whole RTDM module back in RTnet again (that's too
> > platform dependent anyway). I would suggest to develop the required
> > services as an optional subsystem first inside RT-FireWire and RTnet. As
> > soon as this API is stable for each individual project, we could than
> > merge it into a private Xenomai tree, test the cooperation between RTnet
> > and RT-FireWire, and then start submitting patches against Xenomai first
> > and RTAI later.
> >
> > And, with the RTDM-packet subsystem still in both projects available, we
> > could continue to provide support for older RTDM cores without that
> > feature. Detecting the RTDM API revision is easy and could be used to
> > decide if the internal rt-packet code should be build.
> >
I just created a new branch in RTFW svn. Now only copied the files
from RTFW's rtpkbuff module, but can be compiled separately. A
starting point.
Yuchen
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
RTnet-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rtnet-developers
