Re: [RTnet-developers] Re: Common rt-buffers

[Yuchen Z. <yuc...@gm...>]

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 !=3D 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 capture=
d
> > 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 subsys=
tem
> > >>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 "mak=
e
> > >>menuconfig" of RTnet, but maybe switching it on for RT-FireWire at th=
e
> > >>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 rin=
g
> > 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 mor=
e
> > 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. A=
s
> > soon as this API is stable for each individual project, we could than
> > merge it into a private Xenomai tree, test the cooperation between RTne=
t
> > and RT-FireWire, and then start submitting patches against Xenomai firs=
t
> > and RTAI later.
> >
> > And, with the RTDM-packet subsystem still in both projects available, w=
e
> > 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