|
From: Jan K. <jan...@we...> - 2005-12-06 21:37:57
Attachments:
signature.asc
|
Yuchen Zhang wrote:
> Jan,
>
>
>>BTW: Yuchen, we still need to think about that common rtskb format to
>>avoid the additonal copy step in eth1394...
>>
>
> The solution currently in my mind is to also use rtpkbuff module in
> RTnet, which will be exactly the same for RTnet and RT-FW. The
> rtpkbuff modules takes care of the general memory management, so all
> the current rtskb functions will be using the primitives from rtpkbuff
> module, like the hpsb_packet in RT-FW. That way, RTnet can still keep
> the same naming for all rtskb functions. See below how currently rtpkb
> is defined:
>
> struct rtpkb {
> /*meta stuff for general memory management*/
> ......
>
> char specific_stuff[256]; /*rtskb specific stuff goes here*/
> };
>
> Would like to know your opinion:)
I checked the situation in more details again. This is how I see at ATM:
o rt-buffers as RT-FireWire and RTnet use consist of a single memory
fragment, starting with a buffer head, followed by a payload buffer.
RTnet requires almost 1700 bytes per buffer, RT-FireWire more than
4k. But RTnet may require more in case we ever start using jumbo
frames for gigabit Ethernet (i.e. >8k).
o In order to make buffer fully exchangeable between RT-FireWire and
RTnet, both subsystems must agree on
1. a common rt-buffer size
2. a minimum buffer head size to let every user put some private
data into the header as well
3. the same kernel slab pool to take additional buffers from
The third item actually enforces the first one - but may
unfortunately do this in the wrong direction, i.e. provide too small
buffers for one instance.
Requirement 3 could be avoided by using kmalloc instead of
kmem_cache_alloc for each individual buffer, but this may easily
increase the overhead due to not optimally sized memory fragments.
o As we should not simply set the worst-case size as default for all,
some flexibility at least during compile time is required regarding
the size parameters (1. and 2.). More precisely, that subsystem which
is closer to the physical media dictates the rt-packet size.
Now let's think about some approaches to fulfill these requirements in a
generic, maybe also extensible way:
o The rt-buffer pooling mechanism is a generic feature probably suited
for more scenarios than RTnet and RT-FireWire. I'm currently playing
with the idea to move the functionality into the RTDM layer. The core
features would be:
- Providing non-real-time allocation for rt-buffers from -what I
would call it- parent pools. Buffers from parent pools can be
organised in local real-time pools by the drivers and, in case
they come from the same parent pool, freely exchanged.
- Parent pools need to be identified by a unique name. The first
user which accesses a parent pool under a yet unregistered name
will create that pool with rt-buffer size that it provides with
the request.
- Any additional user of an existing parent pool specifying a
different rt-buffer size will receive an error. Thus we make sure
that all users cleanly agree on the same size beforehand. By
"size", I also mean the minimum header size, i.e. actually two
parameters.
- Moreover, one can discuss which features from RT-FireWire's rtpk
and RTnet's rtskb implementation should make it into RTDM. I
haven't thought about this yet.
o Applying this new RTDM feature to the RTnet/RT-FireWire situation, we
would first have to establish some mechanism to agree on rt-buffer
sizes. As RTnet with its rt_eth1394 driver is stacked on top of
RT-FireWire and its buffers are (currently) smaller, it will simply
grab RT-FireWire's parameters from some exported header during
compile time. Then RTnet can call RTDM to either join or create the
fitting parent pool.
o Due to the significant overhead of using 4k buffers for standard
Ethernet and the possibility that RTnet may support jumbo frames in
the future, a scheme for using different parent pools, thus rt-buffer
sizes for different network devices has to be established in RTnet
later on. But this requires some refactoring and API extensions and
is nothing for a quick shot.
So far my ideas. Comments are welcome, questions as well. I hope the
actual implementation is not half as long as this posting. ;)
Jan
|
|
From: Yuchen Z. <yuc...@gm...> - 2005-12-07 00:39:43
|
On 12/6/05, Jan Kiszka <jan...@we...> wrote:
> Yuchen Zhang wrote:
> > Jan,
> >
> >
> >>BTW: Yuchen, we still need to think about that common rtskb format to
> >>avoid the additonal copy step in eth1394...
> >>
> >
> > The solution currently in my mind is to also use rtpkbuff module in
> > RTnet, which will be exactly the same for RTnet and RT-FW. The
> > rtpkbuff modules takes care of the general memory management, so all
> > the current rtskb functions will be using the primitives from rtpkbuff
> > module, like the hpsb_packet in RT-FW. That way, RTnet can still keep
> > the same naming for all rtskb functions. See below how currently rtpkb
> > is defined:
> >
> > struct rtpkb {
> > /*meta stuff for general memory management*/
> > ......
> >
> > char specific_stuff[256]; /*rtskb specific stuff goes =
here*/
> > };
> >
> > Would like to know your opinion:)
>
> I checked the situation in more details again. This is how I see at ATM:
>
> o rt-buffers as RT-FireWire and RTnet use consist of a single memory
> fragment, starting with a buffer head, followed by a payload buffer.
> RTnet requires almost 1700 bytes per buffer, RT-FireWire more than
> 4k. But RTnet may require more in case we ever start using jumbo
> frames for gigabit Ethernet (i.e. >8k).
>
> o In order to make buffer fully exchangeable between RT-FireWire and
> RTnet, both subsystems must agree on
>
> 1. a common rt-buffer size
> 2. a minimum buffer head size to let every user put some private
> data into the header as well
> 3. the same kernel slab pool to take additional buffers from
>
What I understand about the buffer header is: it is composed of the
meta stuff, which is used both for general memory management (like
payload size, the pool where the buffer belongs to, etc) and for
application-specific management (like the Ethernet frame headers), and
the pointer to the payload memory. A rt-buffer struct pointer can be
safely casted to an pointer to application-specific buffer struct, and
vice versa.
> The third item actually enforces the first one - but may
> unfortunately do this in the wrong direction, i.e. provide too small
> buffers for one instance.
> Requirement 3 could be avoided by using kmalloc instead of
> kmem_cache_alloc for each individual buffer, but this may easily
> increase the overhead due to not optimally sized memory fragments.
>
Yes, I agree.
> o As we should not simply set the worst-case size as default for all,
> some flexibility at least during compile time is required regarding
> the size parameters (1. and 2.). More precisely, that subsystem which
> is closer to the physical media dictates the rt-packet size.
>
I also agree that the size of buffer should be flexible. It could be
an argument that is specified to the pool allocating API in the
general memory management(say RTDM).
>
> Now let's think about some approaches to fulfill these requirements in a
> generic, maybe also extensible way:
>
> o The rt-buffer pooling mechanism is a generic feature probably suited
> for more scenarios than RTnet and RT-FireWire. I'm currently playing
> with the idea to move the functionality into the RTDM layer. The core
> features would be:
>
Good idea. In RT-FireWire, the general memory management has been
separated from application-specific buffer management: we have rtpkb
(for general) and hpsb_packet (for FireWire protocol). But, to move
the functionality to a base layer, like RTDM, seems more reasonable.
> - Providing non-real-time allocation for rt-buffers from -what I
> would call it- parent pools. Buffers from parent pools can be
> organised in local real-time pools by the drivers and, in case
> they come from the same parent pool, freely exchanged.
>
> - Parent pools need to be identified by a unique name. The first
> user which accesses a parent pool under a yet unregistered name
> will create that pool with rt-buffer size that it provides with
> the request.
>
> - Any additional user of an existing parent pool specifying a
> different rt-buffer size will receive an error. Thus we make sure
> that all users cleanly agree on the same size beforehand. By
> "size", I also mean the minimum header size, i.e. actually two
> parameters.
>
Above 3 seem fine to me.
> - Moreover, one can discuss which features from RT-FireWire's rtpk
> and RTnet's rtskb implementation should make it into RTDM. I
> haven't thought about this yet.
>
rtpkb has some functions that rtskb does not have. We can take a look
into these details later.
> o Applying this new RTDM feature to the RTnet/RT-FireWire situation, we
> would first have to establish some mechanism to agree on rt-buffer
> sizes. As RTnet with its rt_eth1394 driver is stacked on top of
> RT-FireWire and its buffers are (currently) smaller, it will simply
> grab RT-FireWire's parameters from some exported header during
> compile time. Then RTnet can call RTDM to either join or create the
> fitting parent pool.
>
The pool allocating API of RTDM can be called either when the pool (of
which the name is specified as argument) has been allocated or not. If
allocated, the API simply returns the existing pointer to the pool.
> o Due to the significant overhead of using 4k buffers for standard
> Ethernet and the possibility that RTnet may support jumbo frames in
> the future, a scheme for using different parent pools, thus rt-buffer
> sizes for different network devices has to be established in RTnet
> later on. But this requires some refactoring and API extensions and
> is nothing for a quick shot.
>
Ok, again, the buffer size can be set as argument. But for now, I
think we only need to focus on the service-provider part, i.e. RTDM.
Now, I have some further idea: what if we also bind the packet
capturing service with the memory management. That is if a real-time
application needs real-time memory allocation, it can also ask for
capturing of all those allocated memory (packets). We can use some
user-space tools to analyze the captured memory. The captured memory
can be delivered via fake Ethernet interface, so tools like Ethereal
can be used (only need to extend it based on the application).
The capturng of a packet can be done when that packet memory is freed,
where the capturing operation is transparent to the application. Well,
the application must claim somewhere before the packet is freed that
it should be captured, e.g. right after it is allocated.
Concerning the packet capturing idea, we can explore more, if it is
agreed to be interesting and effort-worth.
Comments wanted, questions welcome:)
Yuchen
|
|
From: Jan K. <jan...@we...> - 2005-12-07 22:53:07
Attachments:
signature.asc
|
Yuchen Zhang wrote:
> On 12/6/05, Jan Kiszka <jan...@we...> wrote:
>
>>Yuchen Zhang wrote:
>>
>>>Jan,
>>>
>>>
>>>
>>>>BTW: Yuchen, we still need to think about that common rtskb format to
>>>>avoid the additonal copy step in eth1394...
>>>>
>>>
>>>The solution currently in my mind is to also use rtpkbuff module in
>>>RTnet, which will be exactly the same for RTnet and RT-FW. The
>>>rtpkbuff modules takes care of the general memory management, so all
>>>the current rtskb functions will be using the primitives from rtpkbuff
>>>module, like the hpsb_packet in RT-FW. That way, RTnet can still keep
>>>the same naming for all rtskb functions. See below how currently rtpkb
>>>is defined:
>>>
>>>struct rtpkb {
>>> /*meta stuff for general memory management*/
>>> ......
>>>
>>> char specific_stuff[256]; /*rtskb specific stuff goes here*/
>>>};
>>>
>>>Would like to know your opinion:)
>>
>>I checked the situation in more details again. This is how I see at ATM:
>>
>> o rt-buffers as RT-FireWire and RTnet use consist of a single memory
>> fragment, starting with a buffer head, followed by a payload buffer.
>> RTnet requires almost 1700 bytes per buffer, RT-FireWire more than
>> 4k. But RTnet may require more in case we ever start using jumbo
>> frames for gigabit Ethernet (i.e. >8k).
>>
>> o In order to make buffer fully exchangeable between RT-FireWire and
>> RTnet, both subsystems must agree on
>>
>> 1. a common rt-buffer size
>> 2. a minimum buffer head size to let every user put some private
>> data into the header as well
>> 3. the same kernel slab pool to take additional buffers from
>>
>
> What I understand about the buffer header is: it is composed of the
> meta stuff, which is used both for general memory management (like
> payload size, the pool where the buffer belongs to, etc) and for
> application-specific management (like the Ethernet frame headers), and
> the pointer to the payload memory. A rt-buffer struct pointer can be
> safely casted to an pointer to application-specific buffer struct, and
> vice versa.
>
>
>> The third item actually enforces the first one - but may
>> unfortunately do this in the wrong direction, i.e. provide too small
>> buffers for one instance.
>> Requirement 3 could be avoided by using kmalloc instead of
>> kmem_cache_alloc for each individual buffer, but this may easily
>> increase the overhead due to not optimally sized memory fragments.
>>
>
> Yes, I agree.
>
>
>> o As we should not simply set the worst-case size as default for all,
>> some flexibility at least during compile time is required regarding
>> the size parameters (1. and 2.). More precisely, that subsystem which
>> is closer to the physical media dictates the rt-packet size.
>>
>
> I also agree that the size of buffer should be flexible. It could be
> an argument that is specified to the pool allocating API in the
> general memory management(say RTDM).
>
>
>>Now let's think about some approaches to fulfill these requirements in a
>>generic, maybe also extensible way:
>>
>> o The rt-buffer pooling mechanism is a generic feature probably suited
>> for more scenarios than RTnet and RT-FireWire. I'm currently playing
>> with the idea to move the functionality into the RTDM layer. The core
>> features would be:
>>
>
> Good idea. In RT-FireWire, the general memory management has been
> separated from application-specific buffer management: we have rtpkb
> (for general) and hpsb_packet (for FireWire protocol). But, to move
> the functionality to a base layer, like RTDM, seems more reasonable.
>
>
>> - Providing non-real-time allocation for rt-buffers from -what I
>> would call it- parent pools. Buffers from parent pools can be
>> organised in local real-time pools by the drivers and, in case
>> they come from the same parent pool, freely exchanged.
>>
>> - Parent pools need to be identified by a unique name. The first
>> user which accesses a parent pool under a yet unregistered name
>> will create that pool with rt-buffer size that it provides with
>> the request.
>>
>> - Any additional user of an existing parent pool specifying a
>> different rt-buffer size will receive an error. Thus we make sure
>> that all users cleanly agree on the same size beforehand. By
>> "size", I also mean the minimum header size, i.e. actually two
>> parameters.
>>
>
>
> Above 3 seem fine to me.
>
>> - Moreover, one can discuss which features from RT-FireWire's rtpk
>> and RTnet's rtskb implementation should make it into RTDM. I
>> haven't thought about this yet.
>>
>
>
> rtpkb has some functions that rtskb does not have. We can take a look
> into these details later.
>
>
>> o Applying this new RTDM feature to the RTnet/RT-FireWire situation, we
>> would first have to establish some mechanism to agree on rt-buffer
>> sizes. As RTnet with its rt_eth1394 driver is stacked on top of
>> RT-FireWire and its buffers are (currently) smaller, it will simply
>> grab RT-FireWire's parameters from some exported header during
>> compile time. Then RTnet can call RTDM to either join or create the
>> fitting parent pool.
>>
>
> The pool allocating API of RTDM can be called either when the pool (of
> which the name is specified as argument) has been allocated or not. If
> allocated, the API simply returns the existing pointer to the pool.
>
>
>> o Due to the significant overhead of using 4k buffers for standard
>> Ethernet and the possibility that RTnet may support jumbo frames in
>> the future, a scheme for using different parent pools, thus rt-buffer
>> sizes for different network devices has to be established in RTnet
>> later on. But this requires some refactoring and API extensions and
>> is nothing for a quick shot.
>>
>
> Ok, again, the buffer size can be set as argument. But for now, I
> think we only need to focus on the service-provider part, i.e. RTDM.
Hey, convincing you of my idea was really easy. ;)
>
> Now, I have some further idea: what if we also bind the packet
> capturing service with the memory management. That is if a real-time
> application needs real-time memory allocation, it can also ask for
> capturing of all those allocated memory (packets). We can use some
> user-space tools to analyze the captured memory. The captured memory
> can be delivered via fake Ethernet interface, so tools like Ethereal
> can be used (only need to extend it based on the application).
>
> The capturng of a packet can be done when that packet memory is freed,
> where the capturing operation is transparent to the application. Well,
> the application must claim somewhere before the packet is freed that
> it should be captured, e.g. right after it is allocated.
>
> Concerning the packet capturing idea, we can explore more, if it is
> agreed to be interesting and effort-worth.
Actually, I'm not yet convinced that outsourcing /this/ job to RTDM is
useful.
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.
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.
But maybe I'm too sceptical. I haven't look at both code bases with your
idea in mind yet. What packet field, what functions would you move to RTDM?
Jan
|
|
From: Yuchen Z. <yuc...@gm...> - 2005-12-08 19:27:55
|
On 12/7/05, Jan Kiszka <jan...@we...> wrote:
> Yuchen Zhang wrote:
> > On 12/6/05, Jan Kiszka <jan...@we...> wrote:
> >
> >>Yuchen Zhang wrote:
> >>
> >>>Jan,
> >>>
> >>>
> >>>
> >>>>BTW: Yuchen, we still need to think about that common rtskb format to
> >>>>avoid the additonal copy step in eth1394...
> >>>>
> >>>
> >>>The solution currently in my mind is to also use rtpkbuff module in
> >>>RTnet, which will be exactly the same for RTnet and RT-FW. The
> >>>rtpkbuff modules takes care of the general memory management, so all
> >>>the current rtskb functions will be using the primitives from rtpkbuff
> >>>module, like the hpsb_packet in RT-FW. That way, RTnet can still keep
> >>>the same naming for all rtskb functions. See below how currently rtpkb
> >>>is defined:
> >>>
> >>>struct rtpkb {
> >>> /*meta stuff for general memory management*/
> >>> ......
> >>>
> >>> char specific_stuff[256]; /*rtskb specific stuff goes=
here*/
> >>>};
> >>>
> >>>Would like to know your opinion:)
> >>
> >>I checked the situation in more details again. This is how I see at ATM=
:
> >>
> >> o rt-buffers as RT-FireWire and RTnet use consist of a single memory
> >> fragment, starting with a buffer head, followed by a payload buffer.
> >> RTnet requires almost 1700 bytes per buffer, RT-FireWire more than
> >> 4k. But RTnet may require more in case we ever start using jumbo
> >> frames for gigabit Ethernet (i.e. >8k).
> >>
> >> o In order to make buffer fully exchangeable between RT-FireWire and
> >> RTnet, both subsystems must agree on
> >>
> >> 1. a common rt-buffer size
> >> 2. a minimum buffer head size to let every user put some private
> >> data into the header as well
> >> 3. the same kernel slab pool to take additional buffers from
> >>
> >
> > What I understand about the buffer header is: it is composed of the
> > meta stuff, which is used both for general memory management (like
> > payload size, the pool where the buffer belongs to, etc) and for
> > application-specific management (like the Ethernet frame headers), and
> > the pointer to the payload memory. A rt-buffer struct pointer can be
> > safely casted to an pointer to application-specific buffer struct, and
> > vice versa.
> >
> >
> >> The third item actually enforces the first one - but may
> >> unfortunately do this in the wrong direction, i.e. provide too small
> >> buffers for one instance.
> >> Requirement 3 could be avoided by using kmalloc instead of
> >> kmem_cache_alloc for each individual buffer, but this may easily
> >> increase the overhead due to not optimally sized memory fragments.
> >>
> >
> > Yes, I agree.
> >
> >
> >> o As we should not simply set the worst-case size as default for all,
> >> some flexibility at least during compile time is required regarding
> >> the size parameters (1. and 2.). More precisely, that subsystem whic=
h
> >> is closer to the physical media dictates the rt-packet size.
> >>
> >
> > I also agree that the size of buffer should be flexible. It could be
> > an argument that is specified to the pool allocating API in the
> > general memory management(say RTDM).
> >
> >
> >>Now let's think about some approaches to fulfill these requirements in =
a
> >>generic, maybe also extensible way:
> >>
> >> o The rt-buffer pooling mechanism is a generic feature probably suited
> >> for more scenarios than RTnet and RT-FireWire. I'm currently playing
> >> with the idea to move the functionality into the RTDM layer. The cor=
e
> >> features would be:
> >>
> >
> > Good idea. In RT-FireWire, the general memory management has been
> > separated from application-specific buffer management: we have rtpkb
> > (for general) and hpsb_packet (for FireWire protocol). But, to move
> > the functionality to a base layer, like RTDM, seems more reasonable.
> >
> >
> >> - Providing non-real-time allocation for rt-buffers from -what I
> >> would call it- parent pools. Buffers from parent pools can be
> >> organised in local real-time pools by the drivers and, in case
> >> they come from the same parent pool, freely exchanged.
> >>
> >> - Parent pools need to be identified by a unique name. The first
> >> user which accesses a parent pool under a yet unregistered name
> >> will create that pool with rt-buffer size that it provides with
> >> the request.
> >>
> >> - Any additional user of an existing parent pool specifying a
> >> different rt-buffer size will receive an error. Thus we make sure
> >> that all users cleanly agree on the same size beforehand. By
> >> "size", I also mean the minimum header size, i.e. actually two
> >> parameters.
> >>
> >
> >
> > Above 3 seem fine to me.
> >
> >> - Moreover, one can discuss which features from RT-FireWire's rtpk
> >> and RTnet's rtskb implementation should make it into RTDM. I
> >> haven't thought about this yet.
> >>
> >
> >
> > rtpkb has some functions that rtskb does not have. We can take a look
> > into these details later.
> >
> >
> >> o Applying this new RTDM feature to the RTnet/RT-FireWire situation, w=
e
> >> would first have to establish some mechanism to agree on rt-buffer
> >> sizes. As RTnet with its rt_eth1394 driver is stacked on top of
> >> RT-FireWire and its buffers are (currently) smaller, it will simply
> >> grab RT-FireWire's parameters from some exported header during
> >> compile time. Then RTnet can call RTDM to either join or create the
> >> fitting parent pool.
> >>
> >
> > The pool allocating API of RTDM can be called either when the pool (of
> > which the name is specified as argument) has been allocated or not. If
> > allocated, the API simply returns the existing pointer to the pool.
> >
> >
> >> o Due to the significant overhead of using 4k buffers for standard
> >> Ethernet and the possibility that RTnet may support jumbo frames in
> >> the future, a scheme for using different parent pools, thus rt-buffe=
r
> >> sizes for different network devices has to be established in RTnet
> >> later on. But this requires some refactoring and API extensions and
> >> is nothing for a quick shot.
> >>
> >
> > Ok, again, the buffer size can be set as argument. But for now, I
> > think we only need to focus on the service-provider part, i.e. RTDM.
>
> Hey, convincing you of my idea was really easy. ;)
>
This is because my own idea was already more or less similiar to
yours, i.e. to move memory management to a base layer, like RTDM. BUT,
I dont think my idea is exactly the same as what you said, see below:
1. I think the buffer size should be an argument to API of allocating
parent pools, i.e. the kernel_slab_pool.
2. I think We DONT need to have different APIs for creating and
joining parent pool. The name of the pool is given in the creating API
anyway, but in case a pool of same name already exists, the pointer to
the existing pool is returned. BUT this is transparent to
applications.
> >
> > Now, I have some further idea: what if we also bind the packet
> > capturing service with the memory management. That is if a real-time
> > application needs real-time memory allocation, it can also ask for
> > capturing of all those allocated memory (packets). We can use some
> > user-space tools to analyze the captured memory. The captured memory
> > can be delivered via fake Ethernet interface, so tools like Ethereal
> > can be used (only need to extend it based on the application).
> >
> > The capturng of a packet can be done when that packet memory is freed,
> > where the capturing operation is transparent to the application. Well,
> > the application must claim somewhere before the packet is freed that
> > it should be captured, e.g. right after it is allocated.
> >
> > Concerning the packet capturing idea, we can explore more, if it is
> > agreed to be interesting and effort-worth.
>
> Actually, I'm not yet convinced that outsourcing /this/ job to RTDM is
> useful.
>
Ok, now time for real debating:)
Let's first sketch the main frame code to support this service.
struct Cap_struct {
struct net_dev *fakedev; /*the fake ethernet dev to deliver
captured packet to user-space*/
struct rt-buffer-pool *cap_pool; /*where the buffers to
compensate application memory come from*/
int buffer_size; /* the size of buffer that can be captured here *=
/
}
struct rt-buffer{
.....
struct Cap_struct *aCap;
}
/*function to create a Cap_struct*/
struct Cap_struct *create_cap( int size, // the buffer size
struct kernel_slab_pool
*parent_pool,
char *name) // the name
of fake ethernet dev, should be
=20
//specific about application
{
if(*name already exists){
return (address of existing Cap_struct)
}
.............
}
/*function to remove a Cap_struct*/
void remove_cap(struct Cap_struct *aCap_struct)
/*function to capture a buffer*/
struct rt-buffer *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 compesating buffer from the cap pool
// exchange buffers
//deliver the captured buffer to fake ethernet dev
//return the address of compensating buffer
return &comp_buffer;
}
}
/*function to free a rt buffer*/
void free_rtbuffer(struct rt-buffer *abuffer){
if(abuffer->aCap){ //pointer NOT null, so we should capture this one
abuffer =3D cap_rtbuffer(abuffer, sizeof(abuffer), abuffer->aCap);
}
//free abuffer
......
}
> 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.
> 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
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.
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
temporarily a separate module that can be compiled over xenomai, and
put it either on RTnet svn or RT-FireWire svn.
Regards,
Yuchen
|
|
From: Jan K. <jan...@we...> - 2005-12-09 20:41:43
Attachments:
signature.asc
|
Yuchen Zhang wrote:
> [...]
> This is because my own idea was already more or less similiar to
> yours, i.e. to move memory management to a base layer, like RTDM. BUT,
> I dont think my idea is exactly the same as what you said, see below:
> 1. I think the buffer size should be an argument to API of allocating
> parent pools, i.e. the kernel_slab_pool.
Did I expressed this differently? Yes, this makes sense most (more
precisely: buffer size and minimum header size).
>
> 2. I think We DONT need to have different APIs for creating and
> joining parent pool. The name of the pool is given in the creating API
> anyway, but in case a pool of same name already exists, the pointer to
> the existing pool is returned. BUT this is transparent to
> applications.
Also what I meant. You call some rtdm_prntpool_create(name, buf_size,
min_head_size) or so, and that pool gets either created or the existing
one is returned.
>
>
>>>Now, I have some further idea: what if we also bind the packet
>>>capturing service with the memory management. That is if a real-time
>>>application needs real-time memory allocation, it can also ask for
>>>capturing of all those allocated memory (packets). We can use some
>>>user-space tools to analyze the captured memory. The captured memory
>>>can be delivered via fake Ethernet interface, so tools like Ethereal
>>>can be used (only need to extend it based on the application).
>>>
>>>The capturng of a packet can be done when that packet memory is freed,
>>>where the capturing operation is transparent to the application. Well,
>>>the application must claim somewhere before the packet is freed that
>>>it should be captured, e.g. right after it is allocated.
>>>
>>>Concerning the packet capturing idea, we can explore more, if it is
>>>agreed to be interesting and effort-worth.
>>
>>Actually, I'm not yet convinced that outsourcing /this/ job to RTDM is
>>useful.
>>
>
> Ok, now time for real debating:)
> Let's first sketch the main frame code to support this service.
>
> struct Cap_struct {
> struct net_dev *fakedev; /*the fake ethernet dev to deliver
> captured packet to user-space*/
> struct rt-buffer-pool *cap_pool; /*where the buffers to
> compensate application memory come from*/
> int buffer_size; /* the size of buffer that can be captured here */
> }
So, that structure describes a capturing instance, conceptually
something like rtcap service of RTnet?
>
> struct rt-buffer{
> .....
> struct Cap_struct *aCap;
> }
>
And this link is needed as there can be multiple capturers, right? But
what about the additional fields required by rtcap to save the initial
buffer layout, the compensation buffer, timestamp, and other stuff? Note
that rtcap does deferred capturing. Does your service in RT-FireWire
work the same way?
> /*function to create a Cap_struct*/
> struct Cap_struct *create_cap( int size, // the buffer size
> struct kernel_slab_pool
> *parent_pool,
> char *name) // the name
> of fake ethernet dev, should be
>
> //specific about application
> {
> if(*name already exists){
> return (address of existing Cap_struct)
> }
> .............
> }
>
> /*function to remove a Cap_struct*/
> void remove_cap(struct Cap_struct *aCap_struct)
>
Ok, this makes sense.
> /*function to capture a buffer*/
> struct rt-buffer *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 compesating buffer from the cap pool
> // exchange buffers
> //deliver the captured buffer to fake ethernet dev
I hope you do NOT deliver immediately, just pend the delivery for Linux
to get in the CPU again.
> //return the address of compensating buffer
> return &comp_buffer;
> }
> }
What's the caller supposed to do with that returned buffer?
>
> /*function to free a rt buffer*/
> void free_rtbuffer(struct rt-buffer *abuffer){
> if(abuffer->aCap){ //pointer NOT null, so we should capture this one
> abuffer = cap_rtbuffer(abuffer, sizeof(abuffer), abuffer->aCap);
Is this the only use case for cap_rtbuffer? How do you mark the actual
capturing date? Only on buffer release? Or did you leave out this aspect
in the draft?
> }
> //free abuffer
> ......
> }
>
>
>>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.
>
>
>>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.
> 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.
Jan
|
|
From: Yuchen Z. <yuc...@gm...> - 2005-12-13 00:06:22
|
On 12/9/05, Jan Kiszka <jan...@we...> wrote:
> Yuchen Zhang wrote:
> >>>Now, I have some further idea: what if we also bind the packet
> >>>capturing service with the memory management. That is if a real-time
> >>>application needs real-time memory allocation, it can also ask for
> >>>capturing of all those allocated memory (packets). We can use some
> >>>user-space tools to analyze the captured memory. The captured memory
> >>>can be delivered via fake Ethernet interface, so tools like Ethereal
> >>>can be used (only need to extend it based on the application).
> >>>
> >>>The capturng of a packet can be done when that packet memory is freed,
> >>>where the capturing operation is transparent to the application. Well,
> >>>the application must claim somewhere before the packet is freed that
> >>>it should be captured, e.g. right after it is allocated.
> >>>
> >>>Concerning the packet capturing idea, we can explore more, if it is
> >>>agreed to be interesting and effort-worth.
> >>
> >>Actually, I'm not yet convinced that outsourcing /this/ job to RTDM is
> >>useful.
> >>
> >
> > Ok, now time for real debating:)
> > Let's first sketch the main frame code to support this service.
> >
> > struct Cap_struct {
> > struct net_dev *fakedev; /*the fake ethernet dev to deliver
> > captured packet to user-space*/
> > struct rt-buffer-pool *cap_pool; /*where the buffers to
> > compensate application memory come from*/
> > int buffer_size; /* the size of buffer that can be captured he=
re */
> > }
>
> So, that structure describes a capturing instance, conceptually
> something like rtcap service of RTnet?
>
Here the difference is, compared with rtcap in RTnet, every single
Capturer has its own buffer pool and interface-to-userspace (the fake
Ethernet). The latter can be seen the same in RTnet, as you have tap
dev for each rtdev.
But all in all, the new Capturing is oriented to application instead
of network interface:
when rtcap module in RTnet is loaded, it changes the xmit_hook&rx_hook
of a certain rtdev with informing the applications, i.e. the
capturing service is fully transparent to applications. (Fix me, if I
am wrong:)) The new Capturing is new mainly because it lets
applications take over the control of capturing.
> >
> > struct rt-buffer{
> > .....
> > struct Cap_struct *aCap;
> > }
> >
>
> And this link is needed as there can be multiple capturers, right? But
> what about the additional fields required by rtcap to save the initial
> buffer layout, the compensation buffer, timestamp, and other stuff? Note
> that rtcap does deferred capturing. Does your service in RT-FireWire
> work the same way?
>
My idea was also deferred capturing, but somehow it was not clearly express=
ed:)
And yes, the timestamp will be in rt-buffer struct also. For
compensation buffer, my initial idea was to only capture the rt-buffer
when it is being freed. In that case, we dont need the compesation
buffer pointer in rt-buffer struct, since the compensation buffer will
be immediately given to the application buffer pool, i.e. buffer
exchange between application and capturer. That's also why the
cap_rtbuffer function should return the pointer to compensation
buffer. BUT now, I would rather choose to let application decide when
to capture the packet: stamping the time, assigning the compensation
packet and putting into the queue of captured packet. That is more
similiar to rtcap in RTnet.
So the rt-buffer struct will be
struct rt-buffer{
..........
struct Cap_struct *aCap;
struct rt-buffer *comp_buf;
}
> > /*function to create a Cap_struct*/
> > struct Cap_struct *create_cap( int size, // the buffer size
> > struct kernel_slab_pool
> > *parent_pool,
> > char *name) // the name
> > of fake ethernet dev, should be
> >
> > //specific about application
> > {
> > if(*name already exists){
> > return (address of existing Cap_struct)
> > }
> > .............
> > }
> >
> > /*function to remove a Cap_struct*/
> > void remove_cap(struct Cap_struct *aCap_struct)
> >
>
> Ok, this makes sense.
>
> > /*function to capture a buffer*/
> > struct rt-buffer *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 compesating buffer from the cap pool
> > // exchange buffers
> > //deliver the captured buffer to fake ethernet dev
>
> I hope you do NOT deliver immediately, just pend the delivery for Linux
> to get in the CPU again.
>
I thought this would not be real-time killing, since the main work is
done in the signal handler invoked via netif_rx, but I just realized
it also should include one time dynamic memory allocation, so now it
will be wrapped in a Linux signal handler. Again like in RTnet.
> > //return the address of compensating buffer
> > return &comp_buffer;
> > }
> > }
>
> What's the caller supposed to do with that returned buffer?
>
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 compesating buffer from the cap pool
> > // exchange buffers
> > //deliver the captured buffer to fake ethernet dev
>
> I hope you do NOT deliver immediately, just pend the delivery for Linux
> to get in the CPU again.
>
I thought this would not be real-time killing, since the main work is
done in the signal handler invoked via netif_rx, but I just realized
it also should include one time dynamic memory allocation, so now it
will be wrapped in a Linux signal handler. Again like in RTnet.
> > //return the address of compensating buffer
> > return &comp_buffer;
> > }
> > }
>
> >
> > /*function to free a rt buffer*/
> > void free_rtbuffer(struct rt-buffer *abuffer){
> > if(abuffer->aCap){ //pointer NOT null, so we should capture this on=
e
> > abuffer =3D cap_rtbuffer(abuffer, sizeof(abuffer), abuffer->aC=
ap);
>
> Is this the only use case for cap_rtbuffer? How do you mark the actual
> capturing date? Only on buffer release? Or did you leave out this aspect
> in the draft?
>
> > }
> > //free abuffer
> > ......
> > }
> >
> >
> >>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.
>
> >
> >
> >>The question to me is then what functionality of the capturing subsyste=
m
> >>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.
>
> > 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 st=
ep.
>
> >
> > 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.
>
> Jan
>
>
>
|
|
From: Yuchen Z. <yuc...@gm...> - 2005-12-13 00:22:02
|
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
|
|
From: Jan K. <jan...@we...> - 2005-12-19 21:06:17
Attachments:
signature.asc
|
Hi Yuchen,
time to kick this discussion again ;) - no I didn't forget it!
Yuchen Zhang wrote:
> On 12/9/05, Jan Kiszka <jan...@we...> wrote:
>
>>Yuchen Zhang wrote:
>
>>>
>>>Ok, now time for real debating:)
>>>Let's first sketch the main frame code to support this service.
>>>
>>>struct Cap_struct {
>>> struct net_dev *fakedev; /*the fake ethernet dev to deliver
>>>captured packet to user-space*/
>>> struct rt-buffer-pool *cap_pool; /*where the buffers to
>>>compensate application memory come from*/
>>> int buffer_size; /* the size of buffer that can be captured here */
>>>}
>>
>>So, that structure describes a capturing instance, conceptually
>>something like rtcap service of RTnet?
>>
>
> Here the difference is, compared with rtcap in RTnet, every single
> Capturer has its own buffer pool and interface-to-userspace (the fake
> Ethernet). The latter can be seen the same in RTnet, as you have tap
> dev for each rtdev.
Ok, sounds interesting. But I guess this does not yet mean that there
can be multiple capturers for the same packet? I guess it means that you
decide later during the stack traversal (or earlier when looking at the
transmission path) if you want to grab a certain packet or not. Some
kind of in-kernel capturing filter instead of doing this later with
Ethereal&friends?
>
> But all in all, the new Capturing is oriented to application instead
> of network interface:
> when rtcap module in RTnet is loaded, it changes the xmit_hook&rx_hook
> of a certain rtdev with informing the applications, i.e. the
> capturing service is fully transparent to applications. (Fix me, if I
> am wrong:)) The new Capturing is new mainly because it lets
> applications take over the control of capturing.
>
Mmh, doesn't this confuse the user and make the management of all those
potential capturing sources a bit complicated? I already had problems to
explain users why there is also a "rteth0-mac" that additionally records
the queuing date of packets deferred by a RTmac discipline. Actually, I
haven't stumbled over a useful use case for this feature on my own so far...
>
>>>struct rt-buffer{
>>> .....
>>> struct Cap_struct *aCap;
>>>}
>>>
>>
>>And this link is needed as there can be multiple capturers, right? But
>>what about the additional fields required by rtcap to save the initial
>>buffer layout, the compensation buffer, timestamp, and other stuff? Note
>>that rtcap does deferred capturing. Does your service in RT-FireWire
>>work the same way?
>>
>
> My idea was also deferred capturing, but somehow it was not clearly expressed:)
> And yes, the timestamp will be in rt-buffer struct also. For
> compensation buffer, my initial idea was to only capture the rt-buffer
> when it is being freed. In that case, we dont need the compesation
> buffer pointer in rt-buffer struct, since the compensation buffer will
> be immediately given to the application buffer pool, i.e. buffer
> exchange between application and capturer. That's also why the
I think to remember having created such a variant in the early rtcap
days. It works well beside one "minor" ugliness: the queuing order in
the rtcap pseudo device became chaotic due to deferred buffer release of
certain NICs and other effects. This means that you will also see a
non-chronological list in Ethereal! Ok, one may try to reorder the
packets in rtcap before forwarding it, but this adds further complexity
and delay (you first have to collect for a while, then reorder, and
finally forward the packets).
> cap_rtbuffer function should return the pointer to compensation
> buffer. BUT now, I would rather choose to let application decide when
> to capture the packet: stamping the time, assigning the compensation
> packet and putting into the queue of captured packet. That is more
> similiar to rtcap in RTnet.
>
> So the rt-buffer struct will be
> struct rt-buffer{
> ..........
> struct Cap_struct *aCap;
> struct rt-buffer *comp_buf;
> }
>
>
>
>>>/*function to create a Cap_struct*/
>>>struct Cap_struct *create_cap( int size, // the buffer size
>>> struct kernel_slab_pool
>>>*parent_pool,
>>> char *name) // the name
>>>of fake ethernet dev, should be
>>>
>>>//specific about application
>>>{
>>> if(*name already exists){
>>> return (address of existing Cap_struct)
>>> }
>>> .............
>>>}
>>>
>>>/*function to remove a Cap_struct*/
>>>void remove_cap(struct Cap_struct *aCap_struct)
>>>
>>
>>Ok, this makes sense.
>>
>>
>>>/*function to capture a buffer*/
>>>struct rt-buffer *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 compesating buffer from the cap pool
>>> // exchange buffers
>>> //deliver the captured buffer to fake ethernet dev
>>
>>I hope you do NOT deliver immediately, just pend the delivery for Linux
>>to get in the CPU again.
>>
>
> I thought this would not be real-time killing, since the main work is
> done in the signal handler invoked via netif_rx, but I just realized
> it also should include one time dynamic memory allocation, so now it
> will be wrapped in a Linux signal handler. Again like in RTnet.
Yep, this is fine if it's just that non-RT signal.
[mail #2]
> 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
> }
> }
>
In terms of rtcap: would cat_rtbuffer be something like
rtcap_report_incoming and would it be called from the xmit-hook for
outgoing packets?
But we will certainly still have something like rtcap_mark_incoming to
save the real packet dimension, don't we?
> [...]
> 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.
>
Well, the decision about capturing a packet or not is made for incoming
packets via rtmac_report_incoming. For outgoing ones, we have the hook
before the drivers transmission routing, a low intrusive approach
regarding code modification. To move to incoming capturing point would
be simple, but we would need a similar functions then also for outgoing
packets to gain more flexibility.
But this just raises the question for we what subsystems / packet
producer you want to instrument separately in this way? And how will the
user select the right one? Will there be bulks of pseudo network devices
for capturing?
> [...]
> 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.
>
That's a good step forward! Actually, I think we should keep all this
capturing discussion in min, but first start off with the "real" work.
RTnet's rtskbs and RT-FireWire's rtpks also began without capturing, so
we should also be able to easily extend the first common (and maybe
working) concept with this feature later.
Jan
|
|
From: Yuchen Z. <yuc...@gm...> - 2006-01-10 06:31:23
|
Hi Jan,
Just back from vacation:), now time to go back to work.
Best wishes before we kick out for 2006!!
On 12/19/05, Jan Kiszka <jan...@we...> wrote:
> Hi Yuchen,
>
> time to kick this discussion again ;) - no I didn't forget it!
>
> Yuchen Zhang wrote:
> > On 12/9/05, Jan Kiszka <jan...@we...> wrote:
> >
> >>Yuchen Zhang wrote:
> >
> >>>
> >>>Ok, now time for real debating:)
> >>>Let's first sketch the main frame code to support this service.
> >>>
> >>>struct Cap_struct {
> >>> struct net_dev *fakedev; /*the fake ethernet dev to deliver
> >>>captured packet to user-space*/
> >>> struct rt-buffer-pool *cap_pool; /*where the buffers to
> >>>compensate application memory come from*/
> >>> int buffer_size; /* the size of buffer that can be captured h=
ere */
> >>>}
> >>
> >>So, that structure describes a capturing instance, conceptually
> >>something like rtcap service of RTnet?
> >>
> >
> > Here the difference is, compared with rtcap in RTnet, every single
> > Capturer has its own buffer pool and interface-to-userspace (the fake
> > Ethernet). The latter can be seen the same in RTnet, as you have tap
> > dev for each rtdev.
>
> Ok, sounds interesting. But I guess this does not yet mean that there
> can be multiple capturers for the same packet? I guess it means that you
> decide later during the stack traversal (or earlier when looking at the
> transmission path) if you want to grab a certain packet or not. Some
> kind of in-kernel capturing filter instead of doing this later with
> Ethereal&friends?
>
Whether multiple capturers is supported or not depends on how many
pointers to compensation buffer are there in the rt_buffer struct.
Now, we have only one pointer so only one capturer is supported at one
time, but if we have two, then two capturer are supported at one time,
and so on. ONLY when all the compensation buffer are released, i.e.
all the pointers are null, the original buffer can be released. This
is checked everytime the free_rtbuffer is called.
> >
> > But all in all, the new Capturing is oriented to application instead
> > of network interface:
> > when rtcap module in RTnet is loaded, it changes the xmit_hook&rx_hook
> > of a certain rtdev with informing the applications, i.e. the
> > capturing service is fully transparent to applications. (Fix me, if I
> > am wrong:)) The new Capturing is new mainly because it lets
> > applications take over the control of capturing.
> >
>
> Mmh, doesn't this confuse the user and make the management of all those
> potential capturing sources a bit complicated? I already had problems to
> explain users why there is also a "rteth0-mac" that additionally records
> the queuing date of packets deferred by a RTmac discipline. Actually, I
> haven't stumbled over a useful use case for this feature on my own so far=
...
>
What I know is it will allow user to decide if they want to capture
the packets (i.e. recording the data flow) in their application.
Again, this is NOT only useful in our network case, but quite general
for any application that employes memory for data exchange,
e.g.between user and kernel space.
> >
> >>>struct rt-buffer{
> >>> .....
> >>> struct Cap_struct *aCap;
> >>>}
> >>>
> >>
> >>And this link is needed as there can be multiple capturers, right? But
> >>what about the additional fields required by rtcap to save the initial
> >>buffer layout, the compensation buffer, timestamp, and other stuff? Not=
e
> >>that rtcap does deferred capturing. Does your service in RT-FireWire
> >>work the same way?
> >>
> >
> > My idea was also deferred capturing, but somehow it was not clearly exp=
ressed:)
> > And yes, the timestamp will be in rt-buffer struct also. For
> > compensation buffer, my initial idea was to only capture the rt-buffer
> > when it is being freed. In that case, we dont need the compesation
> > buffer pointer in rt-buffer struct, since the compensation buffer will
> > be immediately given to the application buffer pool, i.e. buffer
> > exchange between application and capturer. That's also why the
>
> I think to remember having created such a variant in the early rtcap
> days. It works well beside one "minor" ugliness: the queuing order in
> the rtcap pseudo device became chaotic due to deferred buffer release of
> certain NICs and other effects. This means that you will also see a
> non-chronological list in Ethereal! Ok, one may try to reorder the
> packets in rtcap before forwarding it, but this adds further complexity
> and delay (you first have to collect for a while, then reorder, and
> finally forward the packets).
>
Yes, this becomes also my concern. But can we rely on the application
to re-order the captured packets? When the user is developing an
application where memory usage (packets) should be captured, he/she
should also develop the software behind the capturer, like in the
Ethereal side, where the captured packets can be re-ordered. The
re-ordering therefore can be depending on the application-specific
protocol. This is mainly used in case of packet fragmentation, right?
> > cap_rtbuffer function should return the pointer to compensation
> > buffer. BUT now, I would rather choose to let application decide when
> > to capture the packet: stamping the time, assigning the compensation
> > packet and putting into the queue of captured packet. That is more
> > similiar to rtcap in RTnet.
> >
> > So the rt-buffer struct will be
> > struct rt-buffer{
> > ..........
> > struct Cap_struct *aCap;
> > struct rt-buffer *comp_buf;
> > }
> >
> >
> >
> >>>/*function to create a Cap_struct*/
> >>>struct Cap_struct *create_cap( int size, // the buffer size
> >>> struct kernel_slab_pool
> >>>*parent_pool,
> >>> char *name) // the name
> >>>of fake ethernet dev, should be
> >>>
> >>>//specific about application
> >>>{
> >>> if(*name already exists){
> >>> return (address of existing Cap_struct)
> >>> }
> >>> .............
> >>>}
> >>>
> >>>/*function to remove a Cap_struct*/
> >>>void remove_cap(struct Cap_struct *aCap_struct)
> >>>
> >>
> >>Ok, this makes sense.
> >>
> >>
> >>>/*function to capture a buffer*/
> >>>struct rt-buffer *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 compesating buffer from the cap pool
> >>> // exchange buffers
> >>> //deliver the captured buffer to fake ethernet dev
> >>
> >>I hope you do NOT deliver immediately, just pend the delivery for Linux
> >>to get in the CPU again.
> >>
> >
> > I thought this would not be real-time killing, since the main work is
> > done in the signal handler invoked via netif_rx, but I just realized
> > it also should include one time dynamic memory allocation, so now it
> > will be wrapped in a Linux signal handler. Again like in RTnet.
>
> Yep, this is fine if it's just that non-RT signal.
>
> [mail #2]
>
> > 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
> > }
> > }
> >
>
> In terms of rtcap: would cat_rtbuffer be something like
> rtcap_report_incoming and would it be called from the xmit-hook for
> outgoing packets?
>
In principle, the cap_rtbuffer can be called anywhere, with a
rt-buffer and a Capturer (cap_struct). If the user want to capture all
the packets that his application is sending, he can insert the
cap_rtbuffer to the xmit path, which is quite different than in RTnet.
> But we will certainly still have something like rtcap_mark_incoming to
> save the real packet dimension, don't we?
>
(Em,my brain gets stuck here:)) Why the rtcap_mark_incoming is
necessary? What I know is, the Linux signal handler will dequeue a
captured packet, allocate a piece of memory (skb) which is of the
length rt-buffer->len, and copy the content of the captured pakcet to
the allocated skb, and deliver the skb and free the captured packet.
In this process, I dont see the place where rtcap_mark_incoming should
be used. Or do I miss sth?
> > [...]
> > 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.
> >
>
> Well, the decision about capturing a packet or not is made for incoming
> packets via rtmac_report_incoming. For outgoing ones, we have the hook
> before the drivers transmission routing, a low intrusive approach
> regarding code modification. To move to incoming capturing point would
> be simple, but we would need a similar functions then also for outgoing
> packets to gain more flexibility.
>
Could you point me to the implementation of rtmac_report_incoming in
the cross reference. Strange that I cant find it.
> But this just raises the question for we what subsystems / packet
> producer you want to instrument separately in this way? And how will the
> user select the right one? Will there be bulks of pseudo network devices
> for capturing?
>
> > [...]
> > 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.
> >
>
> That's a good step forward! Actually, I think we should keep all this
> capturing discussion in min, but first start off with the "real" work.
> RTnet's rtskbs and RT-FireWire's rtpks also began without capturing, so
> we should also be able to easily extend the first common (and maybe
> working) concept with this feature later.
>
You are right. To make the common buffer module work is of first
priority. Besides, I will try to make RT-FW work with Xenomai 2.1
asap.
Yuchen
|
|
From: Jan K. <jan...@we...> - 2006-01-10 08:42:51
Attachments:
signature.asc
|
Hi Yuchen,
good to hear from you again.
Yuchen Zhang wrote:
> Hi Jan,
>
> Just back from vacation:), now time to go back to work.
> Best wishes before we kick out for 2006!!
Ok, as you've been away, you are permitted to issue these late wishes -
for others, this is becoming a capital offence now! ;)
Seriously, all the best for you as well!
>
> On 12/19/05, Jan Kiszka <jan...@we...> wrote:
>
>>Hi Yuchen,
>>
>>time to kick this discussion again ;) - no I didn't forget it!
>>
>>Yuchen Zhang wrote:
>>
>>>On 12/9/05, Jan Kiszka <jan...@we...> wrote:
>>>
>>>
>>>>Yuchen Zhang wrote:
>>>
>>>>>Ok, now time for real debating:)
>>>>>Let's first sketch the main frame code to support this service.
>>>>>
>>>>>struct Cap_struct {
>>>>> struct net_dev *fakedev; /*the fake ethernet dev to deliver
>>>>>captured packet to user-space*/
>>>>> struct rt-buffer-pool *cap_pool; /*where the buffers to
>>>>>compensate application memory come from*/
>>>>> int buffer_size; /* the size of buffer that can be captured here */
>>>>>}
>>>>
>>>>So, that structure describes a capturing instance, conceptually
>>>>something like rtcap service of RTnet?
>>>>
>>>
>>>Here the difference is, compared with rtcap in RTnet, every single
>>>Capturer has its own buffer pool and interface-to-userspace (the fake
>>>Ethernet). The latter can be seen the same in RTnet, as you have tap
>>>dev for each rtdev.
>>
>>Ok, sounds interesting. But I guess this does not yet mean that there
>>can be multiple capturers for the same packet? I guess it means that you
>>decide later during the stack traversal (or earlier when looking at the
>>transmission path) if you want to grab a certain packet or not. Some
>>kind of in-kernel capturing filter instead of doing this later with
>>Ethereal&friends?
>>
>
> Whether multiple capturers is supported or not depends on how many
> pointers to compensation buffer are there in the rt_buffer struct.
> Now, we have only one pointer so only one capturer is supported at one
> time, but if we have two, then two capturer are supported at one time,
> and so on. ONLY when all the compensation buffer are released, i.e.
> all the pointers are null, the original buffer can be released. This
> is checked everytime the free_rtbuffer is called.
Sounds complex to implement. But we will better discuss this with code
in hands, I guess.
>
>
>>>But all in all, the new Capturing is oriented to application instead
>>>of network interface:
>>>when rtcap module in RTnet is loaded, it changes the xmit_hook&rx_hook
>>>of a certain rtdev with informing the applications, i.e. the
>>>capturing service is fully transparent to applications. (Fix me, if I
>>>am wrong:)) The new Capturing is new mainly because it lets
>>>applications take over the control of capturing.
>>>
>>
>>Mmh, doesn't this confuse the user and make the management of all those
>>potential capturing sources a bit complicated? I already had problems to
>>explain users why there is also a "rteth0-mac" that additionally records
>>the queuing date of packets deferred by a RTmac discipline. Actually, I
>>haven't stumbled over a useful use case for this feature on my own so far...
>>
>
> What I know is it will allow user to decide if they want to capture
> the packets (i.e. recording the data flow) in their application.
> Again, this is NOT only useful in our network case, but quite general
> for any application that employes memory for data exchange,
> e.g.between user and kernel space.
>
>
>>>>>struct rt-buffer{
>>>>> .....
>>>>> struct Cap_struct *aCap;
>>>>>}
>>>>>
>>>>
>>>>And this link is needed as there can be multiple capturers, right? But
>>>>what about the additional fields required by rtcap to save the initial
>>>>buffer layout, the compensation buffer, timestamp, and other stuff? Note
>>>>that rtcap does deferred capturing. Does your service in RT-FireWire
>>>>work the same way?
>>>>
>>>
>>>My idea was also deferred capturing, but somehow it was not clearly expressed:)
>>>And yes, the timestamp will be in rt-buffer struct also. For
>>>compensation buffer, my initial idea was to only capture the rt-buffer
>>>when it is being freed. In that case, we dont need the compesation
>>>buffer pointer in rt-buffer struct, since the compensation buffer will
>>>be immediately given to the application buffer pool, i.e. buffer
>>>exchange between application and capturer. That's also why the
>>
>>I think to remember having created such a variant in the early rtcap
>>days. It works well beside one "minor" ugliness: the queuing order in
>>the rtcap pseudo device became chaotic due to deferred buffer release of
>>certain NICs and other effects. This means that you will also see a
>>non-chronological list in Ethereal! Ok, one may try to reorder the
>>packets in rtcap before forwarding it, but this adds further complexity
>>and delay (you first have to collect for a while, then reorder, and
>>finally forward the packets).
>>
>
> Yes, this becomes also my concern. But can we rely on the application
> to re-order the captured packets? When the user is developing an
> application where memory usage (packets) should be captured, he/she
> should also develop the software behind the capturer, like in the
> Ethereal side, where the captured packets can be re-ordered. The
> re-ordering therefore can be depending on the application-specific
> protocol. This is mainly used in case of packet fragmentation, right?
>
As I said, all transmitted packets, fragmented or not, get delayed
against received packets due to the releasing characteristics of the
NICs. You will have to reorder a lot, and Ethereal would require some
plugins as far as I know (or is there some ordering function already
included meanwhile?).
>
>>>cap_rtbuffer function should return the pointer to compensation
>>>buffer. BUT now, I would rather choose to let application decide when
>>>to capture the packet: stamping the time, assigning the compensation
>>>packet and putting into the queue of captured packet. That is more
>>>similiar to rtcap in RTnet.
>>>
>>>So the rt-buffer struct will be
>>>struct rt-buffer{
>>> ..........
>>> struct Cap_struct *aCap;
>>> struct rt-buffer *comp_buf;
>>>}
>>>
>>>
>>>
>>>
>>>>>/*function to create a Cap_struct*/
>>>>>struct Cap_struct *create_cap( int size, // the buffer size
>>>>> struct kernel_slab_pool
>>>>>*parent_pool,
>>>>> char *name) // the name
>>>>>of fake ethernet dev, should be
>>>>>
>>>>>//specific about application
>>>>>{
>>>>> if(*name already exists){
>>>>> return (address of existing Cap_struct)
>>>>> }
>>>>> .............
>>>>>}
>>>>>
>>>>>/*function to remove a Cap_struct*/
>>>>>void remove_cap(struct Cap_struct *aCap_struct)
>>>>>
>>>>
>>>>Ok, this makes sense.
>>>>
>>>>
>>>>
>>>>>/*function to capture a buffer*/
>>>>>struct rt-buffer *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 compesating buffer from the cap pool
>>>>> // exchange buffers
>>>>> //deliver the captured buffer to fake ethernet dev
>>>>
>>>>I hope you do NOT deliver immediately, just pend the delivery for Linux
>>>>to get in the CPU again.
>>>>
>>>
>>>I thought this would not be real-time killing, since the main work is
>>>done in the signal handler invoked via netif_rx, but I just realized
>>>it also should include one time dynamic memory allocation, so now it
>>>will be wrapped in a Linux signal handler. Again like in RTnet.
>>
>>Yep, this is fine if it's just that non-RT signal.
>>
>>[mail #2]
>>
>>
>>>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
>>> }
>>>}
>>>
>>
>>In terms of rtcap: would cat_rtbuffer be something like
>>rtcap_report_incoming and would it be called from the xmit-hook for
>>outgoing packets?
>>
>
> In principle, the cap_rtbuffer can be called anywhere, with a
> rt-buffer and a Capturer (cap_struct). If the user want to capture all
> the packets that his application is sending, he can insert the
> cap_rtbuffer to the xmit path, which is quite different than in RTnet.
>
>
>>But we will certainly still have something like rtcap_mark_incoming to
>>save the real packet dimension, don't we?
>>
>
> (Em,my brain gets stuck here:)) Why the rtcap_mark_incoming is
> necessary? What I know is, the Linux signal handler will dequeue a
> captured packet, allocate a piece of memory (skb) which is of the
> length rt-buffer->len, and copy the content of the captured pakcet to
> the allocated skb, and deliver the skb and free the captured packet.
> In this process, I dont see the place where rtcap_mark_incoming should
> be used. Or do I miss sth?
>
rtcap_mark_incoming is very light-weight, just saving the original data
begin and length typical inside the receiption IRQ handler. The actual
invocation of the capturing service with all its memory allocation etc.
can then happen in RTnet inside the stack manager, i.e. a real-time
task. And that's after the first protocol header has been removed.
Actually rtcap_report_incoming could be moved freely along the incoming
path.
>
>>>[...]
>>>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.
>>>
>>
>>Well, the decision about capturing a packet or not is made for incoming
>>packets via rtmac_report_incoming. For outgoing ones, we have the hook
>>before the drivers transmission routing, a low intrusive approach
>>regarding code modification. To move to incoming capturing point would
>>be simple, but we would need a similar functions then also for outgoing
>>packets to gain more flexibility.
>>
>
> Could you point me to the implementation of rtmac_report_incoming in
> the cross reference. Strange that I cant find it.
http://www.rts.uni-hannover.de/rtnet/lxr/ident?i=rtcap_report_incoming
>
>
>>But this just raises the question for we what subsystems / packet
>>producer you want to instrument separately in this way? And how will the
>>user select the right one? Will there be bulks of pseudo network devices
>>for capturing?
>>
>>
>>>[...]
>>>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.
>>>
>>
>>That's a good step forward! Actually, I think we should keep all this
>>capturing discussion in min, but first start off with the "real" work.
>>RTnet's rtskbs and RT-FireWire's rtpks also began without capturing, so
>>we should also be able to easily extend the first common (and maybe
>>working) concept with this feature later.
>>
>
> You are right. To make the common buffer module work is of first
> priority. Besides, I will try to make RT-FW work with Xenomai 2.1
> asap.
>
That's good to hear. Looking forward!
Jan
|
