rtnet-developers — development-related list

Re: [RTnet-developers] Maintaining UDP sockets in a hash instead of a list.

[Gilles C. <gil...@xe...>]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> +    rtdm_lock_get_irqsave(&udp_socket_base_lock, context);
>> +    if ((index = sock->prot.inet.reg_index) < 0) {
>> +	    rtdm_lock_put_irqrestore(&udp_socket_base_lock, context);
>> +        /* socket is being closed */
>> +	    return -EBADF;
>> +    }
>> +    port_registry[index].receiving = 1;
>> +    rtdm_lock_put_irqrestore(&udp_socket_base_lock, context);
>> +	    
> 
> This is the only part of the patch I don't like. I don't want to add
> another lock site to the RX path. I see the problem, but I think we need
> some other solution. Maybe something that disables reception, and thus
> unwanted buffer consumption.

Actually, what we can do is put the "receiving" member in the udp socket 
structure, so that there is no risk, when setting this member to 1, to 
set to 1 the member of another socket.

-- 
                                                  Gilles.

Re: [RTnet-developers] Maintaining UDP sockets in a hash instead of a list.

[Gilles C. <gil...@xe...>]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Gilles Chanteperdrix wrote:
>>>>> Hi,
>>>>>
>>>>> here is another patch to RTnet, which replaces the list of UDP sockets
>>>>> with a hash, so makes the searching for an RTnet registered socket a
>>>>> bit
>>>>> faster.
>>>> Ok. Should have read the patch better before sending it. There are two
>>>> more features poured into this patch:
>>>> - we add a "receiving" member to the UDP socket structure, which is only
>>>> sets either if the program using the socket has called recv, or if the
>>>> program has bound the socket to a particular port, this is to prevent a
>>>> problem which happens when putting an RTnet box on an heterogenous
>>>> network, with an application which only uses a socket to send packets:
>>>> if the network sends some packets to the automatically assigned port,
>>>> they use rtskbs from the socket pool, until the socket pool becomes
>>>> empty, and no more packet can be sent using the socket.
>>>> - when a socket is bound to a particular IP address, we use this IP as
>>>> the source IP of the packets sent by this socket, even if they end-up
>>>> being sent through another interface, this is Linux behaviour, and was
>>>> required for one of our applications to work correctly with
>>>> off-the-shelf IP phones (they do filtering based on the source IP).
>>> Could you break those two changes out and post them separately? Such
>>> changes are too critical to have them all-in-one.
>> Ok. Here it comes, extracted from revision control history.
>> Apply in order:
>> - rtnet-fix-src-ip.diff
> 
>> --- stack/ipv4/udp.c	(révision 3250)
>> +++ stack/ipv4/udp.c	(révision 5093)
>> @@ -576,14 +576,8 @@ ssize_t rt_udp_sendmsg(struct rtdm_dev_c
>>      if (err)
>>          return err;
>>  
>> -    /* check if specified source address fits */
>> -    if ((saddr != INADDR_ANY) && (saddr != rt.rtdev->local_ip)) {
>> -        rtdev_dereference(rt.rtdev);
>> -        return -EHOSTUNREACH;
>> -    }
>> -
>>      /* we found a route, remember the routing dest-addr could be the netmask */
>> -    ufh.saddr     = rt.rtdev->local_ip;
>> +    ufh.saddr     = saddr ?: rt.rtdev->local_ip;
> 
> One minor remark: I would prefer "saddr != INADDR_ANY ? saddr : ..."
> here (the compiler should produce the same output).
> 
> I guess you tested this with CONFIG_RTNET_RTIPV4_ROUTE_SRC enabled,
> right? I wonder if we shouldn't turn this unconditionally on now, it
> won't cost us much in the hot path, but it would make the code more
> readable.

No, I run rtnet without CONFIG_RTNET_RTIPV4_ROUTE_SRC. All routing, 
nating, bridging is done by Linux in my configuration. Also, it looks to 
me like this code is run unconditonnally, maybe is it because I am using 
an older release ?

> 
>> - rtnet-check-receiving.diff
> 
>> @@ -375,13 +379,23 @@ ssize_t rt_udp_recvmsg(struct rtdm_dev_c
>>      struct udphdr       *uh;
>>      struct sockaddr_in  *sin;
>>      nanosecs_rel_t      timeout = sock->timeout;
>> -    int                 ret;
>> +    int                 ret, index;
>> +    rtdm_lockctx_t  context;
>>  
>>  
>>      /* non-blocking receive? */
>>      if (testbits(msg_flags, MSG_DONTWAIT))
>>          timeout = -1;
>>  
>> +    rtdm_lock_get_irqsave(&udp_socket_base_lock, context);
>> +    if ((index = sock->prot.inet.reg_index) < 0) {
>> +	    rtdm_lock_put_irqrestore(&udp_socket_base_lock, context);
>> +        /* socket is being closed */
>> +	    return -EBADF;
>> +    }
>> +    port_registry[index].receiving = 1;
>> +    rtdm_lock_put_irqrestore(&udp_socket_base_lock, context);
>> +	    
> 
> This is the only part of the patch I don't like. I don't want to add
> another lock site to the RX path. I see the problem, but I think we need
> some other solution. Maybe something that disables reception, and thus
> unwanted buffer consumption.

You are lucky, because I can not remember why I did this :-) Maybe the 
lock is not needed after all...

> 
>> - rtnet-hash-port.diff
> 
> This needs more thoughts than I've left for tonight (no fundamental
> problems, I just want to exclude that I'm overseeing some pitfalls of it).

FWIW, the patch is running for some time now, even on production 
systems, without any problems. The only thing which I only tested in 
unit tests and had not to test on real systems is the case where two 
applications open bind the same port on two different IPs.

-- 
                                                  Gilles.

Re: [RTnet-developers] Maintaining UDP sockets in a hash instead of a list.

[Jan K. <jan...@we...>]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Hi,
>>>>
>>>> here is another patch to RTnet, which replaces the list of UDP sockets
>>>> with a hash, so makes the searching for an RTnet registered socket a
>>>> bit
>>>> faster.
>>> Ok. Should have read the patch better before sending it. There are two
>>> more features poured into this patch:
>>> - we add a "receiving" member to the UDP socket structure, which is only
>>> sets either if the program using the socket has called recv, or if the
>>> program has bound the socket to a particular port, this is to prevent a
>>> problem which happens when putting an RTnet box on an heterogenous
>>> network, with an application which only uses a socket to send packets:
>>> if the network sends some packets to the automatically assigned port,
>>> they use rtskbs from the socket pool, until the socket pool becomes
>>> empty, and no more packet can be sent using the socket.
>>> - when a socket is bound to a particular IP address, we use this IP as
>>> the source IP of the packets sent by this socket, even if they end-up
>>> being sent through another interface, this is Linux behaviour, and was
>>> required for one of our applications to work correctly with
>>> off-the-shelf IP phones (they do filtering based on the source IP).
>>
>> Could you break those two changes out and post them separately? Such
>> changes are too critical to have them all-in-one.
> 
> Ok. Here it comes, extracted from revision control history.
> Apply in order:
> - rtnet-fix-src-ip.diff

> --- stack/ipv4/udp.c	(révision 3250)
> +++ stack/ipv4/udp.c	(révision 5093)
> @@ -576,14 +576,8 @@ ssize_t rt_udp_sendmsg(struct rtdm_dev_c
>      if (err)
>          return err;
>  
> -    /* check if specified source address fits */
> -    if ((saddr != INADDR_ANY) && (saddr != rt.rtdev->local_ip)) {
> -        rtdev_dereference(rt.rtdev);
> -        return -EHOSTUNREACH;
> -    }
> -
>      /* we found a route, remember the routing dest-addr could be the netmask */
> -    ufh.saddr     = rt.rtdev->local_ip;
> +    ufh.saddr     = saddr ?: rt.rtdev->local_ip;

One minor remark: I would prefer "saddr != INADDR_ANY ? saddr : ..."
here (the compiler should produce the same output).

I guess you tested this with CONFIG_RTNET_RTIPV4_ROUTE_SRC enabled,
right? I wonder if we shouldn't turn this unconditionally on now, it
won't cost us much in the hot path, but it would make the code more
readable.

> - rtnet-check-receiving.diff

> @@ -375,13 +379,23 @@ ssize_t rt_udp_recvmsg(struct rtdm_dev_c
>      struct udphdr       *uh;
>      struct sockaddr_in  *sin;
>      nanosecs_rel_t      timeout = sock->timeout;
> -    int                 ret;
> +    int                 ret, index;
> +    rtdm_lockctx_t  context;
>  
>  
>      /* non-blocking receive? */
>      if (testbits(msg_flags, MSG_DONTWAIT))
>          timeout = -1;
>  
> +    rtdm_lock_get_irqsave(&udp_socket_base_lock, context);
> +    if ((index = sock->prot.inet.reg_index) < 0) {
> +	    rtdm_lock_put_irqrestore(&udp_socket_base_lock, context);
> +        /* socket is being closed */
> +	    return -EBADF;
> +    }
> +    port_registry[index].receiving = 1;
> +    rtdm_lock_put_irqrestore(&udp_socket_base_lock, context);
> +	    

This is the only part of the patch I don't like. I don't want to add
another lock site to the RX path. I see the problem, but I think we need
some other solution. Maybe something that disables reception, and thus
unwanted buffer consumption.

> - rtnet-hash-port.diff

This needs more thoughts than I've left for tonight (no fundamental
problems, I just want to exclude that I'm overseeing some pitfalls of it).

Jan

Re: [RTnet-developers] Maintaining UDP sockets in a hash instead of a list.

[Gilles C. <gil...@xe...>]

Wolfgang Grandegger wrote:
> Hi Gilles,
> 
> Gilles Chanteperdrix wrote:
>> Hi,
>>
>> here is another patch to RTnet, which replaces the list of UDP sockets
>> with a hash, so makes the searching for an RTnet registered socket a bit
>> faster.
> 
> What does a "bit faster" mean. I'm curious, do you have some benchmark 
> figures at hand?

No, but the current scheme is to test every packet against every socket 
(until one is found). This is O(N).
With a hash, and a well dimensioned/behaved system, you get O(1).
So, no doubt there is a gain, at least on systems with many sockets 
opened, and especially when you receive many non real-time UDP packets 
which you must send to the proxy: non real-time packets are tested 
against all opened sockets, to finally find that they are matching none 
of them.

-- 
                                                  Gilles.

Re: [RTnet-developers] Maintaining UDP sockets in a hash instead of a list.

[Gilles C. <gil...@xe...>]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Gilles Chanteperdrix wrote:
>>> Hi,
>>>
>>> here is another patch to RTnet, which replaces the list of UDP sockets
>>> with a hash, so makes the searching for an RTnet registered socket a bit
>>> faster.
>> Ok. Should have read the patch better before sending it. There are two
>> more features poured into this patch:
>> - we add a "receiving" member to the UDP socket structure, which is only
>> sets either if the program using the socket has called recv, or if the
>> program has bound the socket to a particular port, this is to prevent a
>> problem which happens when putting an RTnet box on an heterogenous
>> network, with an application which only uses a socket to send packets:
>> if the network sends some packets to the automatically assigned port,
>> they use rtskbs from the socket pool, until the socket pool becomes
>> empty, and no more packet can be sent using the socket.
>> - when a socket is bound to a particular IP address, we use this IP as
>> the source IP of the packets sent by this socket, even if they end-up
>> being sent through another interface, this is Linux behaviour, and was
>> required for one of our applications to work correctly with
>> off-the-shelf IP phones (they do filtering based on the source IP).
> 
> Could you break those two changes out and post them separately? Such
> changes are too critical to have them all-in-one.

Ok. Here it comes, extracted from revision control history.
Apply in order:
- rtnet-fix-src-ip.diff
- rtnet-check-receiving.diff
- rtnet-hash-port.diff

-- 
                                                  Gilles.

Re: [RTnet-developers] network statistic for rt_8139too.koo?

[Gilles C. <gil...@xe...>]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Gilles Chanteperdrix wrote:
>>>>> Jens Köhler wrote:
>>>>>> Hello all,
>>>>>>
>>>>>> I am using the rt_8139too.koo network driver. Is there a
>>>>>> possibility to get
>>>>>> a statistic about received, sent packets and errors?
>>>>> Hi,
>>>>>
>>>>> In case it could be for interest to anyone, here is a patch which adds
>>>>> supports for rtnet per-device statistics, and make them accessible
>>>>> through rtifconfig.
>>>>>
>>>>> Note that to make these statistics work, you will have to write a
>>>>> per-driver callback, but for most drivers the callback is already
>>>>> there,
>>>>> you only have to uncomment it.
>>>>>
>>>>> Note that this patch was extracted from a bunch of other stuff, so,
>>>>> there may be some things missing, if it happens and this patch is of
>>>>> some interest to you, let me know.
>>>> This is definitely an interesting patch, and I would welcome (ie.
>>>> merge) this framework + potential driver patches.
>>> Ok. I will send the drivers patches, as I said maintaining the stats is
>>> already done in most drivers what need to be done is simply to uncomment
>>> or implement the function which returns the pointer to the statistics
>>> structure, so, the job should not be to hard.
>>>
>> Here comes the drivers patch. Only e1000 and rt_loopback were left aside
>> since they do not do any accounting.
> 
> Thanks, merged. With some pain, though.
> 
> Seems like it also came from an older RTnet version. rt2x00 stuff didn't
> build, skipped it. And the rt_mpc52xx_fec bits didn't apply. Wolfgang,
> could you have a look at the latter?

My bad, the original patch were made against 0.9.8, I adapted them to 
0.9.9 because I thought it was the latest release

-- 
                                                  Gilles.

Re: [RTnet-developers] network statistic for rt_8139too.koo?

[Wolfgang G. <wg...@gr...>]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Gilles Chanteperdrix wrote:
>>>>> Jens Köhler wrote:
>>>>>> Hello all,
>>>>>>
>>>>>> I am using the rt_8139too.koo network driver. Is there a
>>>>>> possibility to get
>>>>>> a statistic about received, sent packets and errors?
>>>>> Hi,
>>>>>
>>>>> In case it could be for interest to anyone, here is a patch which adds
>>>>> supports for rtnet per-device statistics, and make them accessible
>>>>> through rtifconfig.
>>>>>
>>>>> Note that to make these statistics work, you will have to write a
>>>>> per-driver callback, but for most drivers the callback is already
>>>>> there,
>>>>> you only have to uncomment it.
>>>>>
>>>>> Note that this patch was extracted from a bunch of other stuff, so,
>>>>> there may be some things missing, if it happens and this patch is of
>>>>> some interest to you, let me know.
>>>> This is definitely an interesting patch, and I would welcome (ie.
>>>> merge) this framework + potential driver patches.
>>> Ok. I will send the drivers patches, as I said maintaining the stats is
>>> already done in most drivers what need to be done is simply to uncomment
>>> or implement the function which returns the pointer to the statistics
>>> structure, so, the job should not be to hard.
>>>
>> Here comes the drivers patch. Only e1000 and rt_loopback were left aside
>> since they do not do any accounting.
> 
> Thanks, merged. With some pain, though.
> 
> Seems like it also came from an older RTnet version. rt2x00 stuff didn't
> build, skipped it. And the rt_mpc52xx_fec bits didn't apply. Wolfgang,
> could you have a look at the latter?

I will take care. Hope to find some time towards the end of this week.

Thanks,

Wolfgang.

Re: [RTnet-developers] Maintaining UDP sockets in a hash instead of a list.

[Wolfgang G. <wg...@gr...>]

Hi Gilles,

Gilles Chanteperdrix wrote:
> Hi,
> 
> here is another patch to RTnet, which replaces the list of UDP sockets
> with a hash, so makes the searching for an RTnet registered socket a bit
> faster.

What does a "bit faster" mean. I'm curious, do you have some benchmark 
figures at hand?

Wolfgang.

Re: [RTnet-developers] Maintaining UDP sockets in a hash instead of a list.

[Jan K. <jan...@we...>]

Gilles Chanteperdrix wrote:
> Gilles Chanteperdrix wrote:
>> Hi,
>>
>> here is another patch to RTnet, which replaces the list of UDP sockets
>> with a hash, so makes the searching for an RTnet registered socket a bit
>> faster.
> 
> Ok. Should have read the patch better before sending it. There are two
> more features poured into this patch:
> - we add a "receiving" member to the UDP socket structure, which is only
> sets either if the program using the socket has called recv, or if the
> program has bound the socket to a particular port, this is to prevent a
> problem which happens when putting an RTnet box on an heterogenous
> network, with an application which only uses a socket to send packets:
> if the network sends some packets to the automatically assigned port,
> they use rtskbs from the socket pool, until the socket pool becomes
> empty, and no more packet can be sent using the socket.
> - when a socket is bound to a particular IP address, we use this IP as
> the source IP of the packets sent by this socket, even if they end-up
> being sent through another interface, this is Linux behaviour, and was
> required for one of our applications to work correctly with
> off-the-shelf IP phones (they do filtering based on the source IP).

Could you break those two changes out and post them separately? Such
changes are too critical to have them all-in-one.

TiA,
Jan

Re: [RTnet-developers] network statistic for rt_8139too.koo?

[Jan K. <jan...@we...>]

Gilles Chanteperdrix wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Jens Köhler wrote:
>>>>> Hello all,
>>>>>
>>>>> I am using the rt_8139too.koo network driver. Is there a
>>>>> possibility to get
>>>>> a statistic about received, sent packets and errors?
>>>> Hi,
>>>>
>>>> In case it could be for interest to anyone, here is a patch which adds
>>>> supports for rtnet per-device statistics, and make them accessible
>>>> through rtifconfig.
>>>>
>>>> Note that to make these statistics work, you will have to write a
>>>> per-driver callback, but for most drivers the callback is already
>>>> there,
>>>> you only have to uncomment it.
>>>>
>>>> Note that this patch was extracted from a bunch of other stuff, so,
>>>> there may be some things missing, if it happens and this patch is of
>>>> some interest to you, let me know.
>>> This is definitely an interesting patch, and I would welcome (ie.
>>> merge) this framework + potential driver patches.
>>
>> Ok. I will send the drivers patches, as I said maintaining the stats is
>> already done in most drivers what need to be done is simply to uncomment
>> or implement the function which returns the pointer to the statistics
>> structure, so, the job should not be to hard.
>>
> 
> Here comes the drivers patch. Only e1000 and rt_loopback were left aside
> since they do not do any accounting.

Thanks, merged. With some pain, though.

Seems like it also came from an older RTnet version. rt2x00 stuff didn't
build, skipped it. And the rt_mpc52xx_fec bits didn't apply. Wolfgang,
could you have a look at the latter?

Jan

Re: [RTnet-developers] network statistic for rt_8139too.koo?

[Jan K. <jan...@we...>]

Gilles Chanteperdrix wrote:
> Jens Köhler wrote:
>> Hello all,
>>
>> I am using the rt_8139too.koo network driver. Is there a possibility to get
>> a statistic about received, sent packets and errors?
> 
> Hi,
> 
> In case it could be for interest to anyone, here is a patch which adds
> supports for rtnet per-device statistics, and make them accessible
> through rtifconfig.
> 
> Note that to make these statistics work, you will have to write a
> per-driver callback, but for most drivers the callback is already there,
> you only have to uncomment it.
> 
> Note that this patch was extracted from a bunch of other stuff, so,
> there may be some things missing, if it happens and this patch is of
> some interest to you, let me know.

Patch merged with some minor restructuring.

Thanks,
Jan

Re: [RTnet-developers] Maintaining UDP sockets in a hash instead of a list.

[Gilles C. <gil...@xe...>]

Gilles Chanteperdrix wrote:
> Hi,
> 
> here is another patch to RTnet, which replaces the list of UDP sockets
> with a hash, so makes the searching for an RTnet registered socket a bit
> faster.

Ok. Should have read the patch better before sending it. There are two
more features poured into this patch:
- we add a "receiving" member to the UDP socket structure, which is only
sets either if the program using the socket has called recv, or if the
program has bound the socket to a particular port, this is to prevent a
problem which happens when putting an RTnet box on an heterogenous
network, with an application which only uses a socket to send packets:
if the network sends some packets to the automatically assigned port,
they use rtskbs from the socket pool, until the socket pool becomes
empty, and no more packet can be sent using the socket.
- when a socket is bound to a particular IP address, we use this IP as
the source IP of the packets sent by this socket, even if they end-up
being sent through another interface, this is Linux behaviour, and was
required for one of our applications to work correctly with
off-the-shelf IP phones (they do filtering based on the source IP).

-- 
                                                 Gilles.

[RTnet-developers] Maintaining UDP sockets in a hash instead of a list.

[Gilles C. <gil...@xe...>]

Hi,

here is another patch to RTnet, which replaces the list of UDP sockets
with a hash, so makes the searching for an RTnet registered socket a bit
faster.

Regards.

-- 
                                                 Gilles.

Re: [RTnet-developers] network statistic for rt_8139too.koo?

[Gilles C. <gil...@xe...>]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jens Köhler wrote:
>>>> Hello all,
>>>>
>>>> I am using the rt_8139too.koo network driver. Is there a possibility to get
>>>> a statistic about received, sent packets and errors?
>>> Hi,
>>>
>>> In case it could be for interest to anyone, here is a patch which adds
>>> supports for rtnet per-device statistics, and make them accessible
>>> through rtifconfig.
>>>
>>> Note that to make these statistics work, you will have to write a
>>> per-driver callback, but for most drivers the callback is already there,
>>> you only have to uncomment it.
>>>
>>> Note that this patch was extracted from a bunch of other stuff, so,
>>> there may be some things missing, if it happens and this patch is of
>>> some interest to you, let me know.
>> This is definitely an interesting patch, and I would welcome (ie. merge) 
>> this framework + potential driver patches.
> 
> Ok. I will send the drivers patches, as I said maintaining the stats is
> already done in most drivers what need to be done is simply to uncomment
> or implement the function which returns the pointer to the statistics
> structure, so, the job should not be to hard.
> 

Here comes the drivers patch. Only e1000 and rt_loopback were left aside 
since they do not do any accounting.

-- 
                                                  Gilles.

Re: [RTnet-developers] network statistic for rt_8139too.koo?

[Gilles C. <gil...@xe...>]

Jens Köhler wrote:
> Hello Gilles,
> 
> thank you for the patch. I patched the source file, recompiled the source
> file. When I now use the rtifconfig command I do not get a statistic. Have
> you an example for a per-driver callback?
> 
> rteth0    Medium: Ethernet  Hardware address: 00:00:00:01:00:01
>           IP address: 172.23.0.17  Broadcast address: 172.23.255.255
>           UP BROADCAST RUNNING  MTU: 1500
> 
> 
> Thanks,
> Jens

I am glad to learn that it at least compiles.

I am preparing the patch for per-driver callbacks, and have not finished
yet. A typical get_stats loopback looks like this:

static struct net_device_stats *rtl8139_get_stats(struct rtnet_device
*rtdev)
{
	struct rtl8139_private *tp = rtdev->priv;
	return &tp->stats;
}

Then, in the rtl8139_init_one function, you have to add:
rtdev->get_stats = rtl8139_get_stats;

That is all !

-- 
                                                 Gilles.

Re: [RTnet-developers] network statistic for rt_8139too.koo?

[Gilles C. <gil...@xe...>]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jens Köhler wrote:
>>> Hello all,
>>>
>>> I am using the rt_8139too.koo network driver. Is there a possibility to get
>>> a statistic about received, sent packets and errors?
>> Hi,
>>
>> In case it could be for interest to anyone, here is a patch which adds
>> supports for rtnet per-device statistics, and make them accessible
>> through rtifconfig.
>>
>> Note that to make these statistics work, you will have to write a
>> per-driver callback, but for most drivers the callback is already there,
>> you only have to uncomment it.
>>
>> Note that this patch was extracted from a bunch of other stuff, so,
>> there may be some things missing, if it happens and this patch is of
>> some interest to you, let me know.
> 
> This is definitely an interesting patch, and I would welcome (ie. merge) 
> this framework + potential driver patches.

Ok. I will send the drivers patches, as I said maintaining the stats is
already done in most drivers what need to be done is simply to uncomment
or implement the function which returns the pointer to the statistics
structure, so, the job should not be to hard.

-- 


					    Gilles.

Re: [RTnet-developers] network statistic for rt_8139too.koo?

[Jan K. <jan...@we...>]

Gilles Chanteperdrix wrote:
> Jens Köhler wrote:
>> Hello all,
>>
>> I am using the rt_8139too.koo network driver. Is there a possibility to get
>> a statistic about received, sent packets and errors?
> 
> Hi,
> 
> In case it could be for interest to anyone, here is a patch which adds
> supports for rtnet per-device statistics, and make them accessible
> through rtifconfig.
> 
> Note that to make these statistics work, you will have to write a
> per-driver callback, but for most drivers the callback is already there,
> you only have to uncomment it.
> 
> Note that this patch was extracted from a bunch of other stuff, so,
> there may be some things missing, if it happens and this patch is of
> some interest to you, let me know.

This is definitely an interesting patch, and I would welcome (ie. merge) 
this framework + potential driver patches.

Jan

Re: [RTnet-developers] network statistic for rt_8139too.koo?

[Gilles C. <gil...@xe...>]

Jens Köhler wrote:
> Hello all,
> 
> I am using the rt_8139too.koo network driver. Is there a possibility to get
> a statistic about received, sent packets and errors?

Hi,

In case it could be for interest to anyone, here is a patch which adds
supports for rtnet per-device statistics, and make them accessible
through rtifconfig.

Note that to make these statistics work, you will have to write a
per-driver callback, but for most drivers the callback is already there,
you only have to uncomment it.

Note that this patch was extracted from a bunch of other stuff, so,
there may be some things missing, if it happens and this patch is of
some interest to you, let me know.

Regards.

-- 
                                                 Gilles Chanteperdrix

Re: [RTnet-developers] network statistic for rt_8139too.koo?

[Jan K. <jan...@si...>]

Karl Reichert wrote:
>> Hello all,
>>
>> I am using the rt_8139too.koo network driver. Is there a possibility to
>> get
>> a statistic about received, sent packets and errors?
>>
>> Thanks and regards,
>> Jens
> 
> Please check /sys/class/net for statistics.

Those stats are maintained for network devices registered with the Linux
stack. But RTnet does not do this for RT-NICs.

If you find "rteth0"&friends under /sys, then you are using RTcap. That
can, at beast, be considered as a workaround (overhead, no
differentiation RX/TX).

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [RTnet-developers] network statistic for rt_8139too.koo?

[Karl R. <Kar...@gm...>]

> Hello all,
> 
> I am using the rt_8139too.koo network driver. Is there a possibility to
> get
> a statistic about received, sent packets and errors?
> 
> Thanks and regards,
> Jens

Please check /sys/class/net for statistics.

Best regards
Karl
-- 
von Karl Reichert

[RTnet-developers] network statistic for rt_8139too.koo?

[J. K. <jen...@go...>]

Hello all,

I am using the rt_8139too.koo network driver. Is there a possibility to get
a statistic about received, sent packets and errors?

Thanks and regards,
Jens

Re: [RTnet-developers] rtnet and multicast

[Bruno C. <b.c...@ip...>]

Hello diego,

make 1588 work with rtnet was actually what led me to contribute in the 
multicast patch.
It would interest me to know more precisely what are your own plans.

- the attached patch should work with the lattest version (1158 in svn) 
but be careful with potential conflicts.
- I only adapted e1000 driver but it should be easy (?) to modify the 
8139too one :  you have to add a function set_multicast_list and to bind 
it with the rtdev->set_multicast_list in the devinit function of your 
driver (maybe could you find hints in the rt e1000 driver but also in 
the regular 8139too driver because this relies on hardware functions ) 
good luck !

I'm not working on this thread for the time being, but wil be glad to 
help you and work with you.

Bruno.


ds...@i2... a écrit :
> Hello Carlus,
>
> First of all, I am not sure if I am doing correctly, like Jan told me in
> his last email that he sent me, about to add the mailing list to the Cc. I
> only know to you, Jan and Carlus. I have just registered to myself in the
> web sourceforge.net, If I have to do something particulary, to participate
> with you, tell me about it.
>
> Well, Now I am going to talk about my doubts;
>
> We are trying to implement Rtai with Rtnet, and use over it, the protocol
> IEEE 1588. Then we need that rtnet will be Multicast. We have seen the
> patch that carlus has put int the mailing list, in www.rtnet.org, but it
> says that the version of Rtnet used, is the rtnet-0.9.10-rc2, then my
> questions are:
>
> 1.Can we  use the patch, in the last version that there is in www.rtnet.org?
> 2.In the patch I have seen that only, youmodify the drivers of the e1000,
> we are using the 8139too. What thing you recommend me?
>
> If there is something more important, please tellme about it.
>
> And if you need information, about what  are  we doing, please ask for it.
>
> your sincerely
>
> Diego
>
>
>   

[RTnet-developers] Porting ExpressCard ethernet driver to RTnet - Bounty

[Wolfgang K. <wk...@ko...>]

Hello,

I have been searching an ExpressCard Ethernet Adapter that is supported
by RTnet. I have not found any. So it seems necessary *) to port a Linux
driver to RTnet.

There seem to be 2 major Chipsets for ExpressCard Ethernet Adapters:
1. Marvell with the linux driver skge
2. Agere with the linux driver et131x

Is anyone interested in porting one of these drivers (or another
widely used chipset driver) to RTnet for me ?

The driver should work reliably, at least with 100Mbit/s, and it should
be integrated into the official rtnet tarball. The code should be good
enough that it works and is accepted by the RTnet maintainers. And it
should be completed within the next few weeks.

I could spend 250 EUR. I know this is not very much. Is anyone willing
to add some money ? How much would be needed ? Or is someone willing to
work for the fame of having portet the first RTnet ExpressCard Ethernet
driver (and take the money as an extra) ?

Bye,
Wolfgang

*) Alternatives exist (ExpressCard to PC Card adapters, Notebooks with
PC Card or even Desktop Computers), but a RTnet driver would be the
prettier solution.

http://en.wikipedia.org/wiki/ExpressCard
http://www.rts.uni-hannover.de/rtnet/lxr/source/Documentation/README.drvporting

---

On Wed, 30 Apr 2008 20:59:29 +0200
Wolfgang Köbler <wk...@ko...> wrote:
> Hello,
> 
> On Wed, 30 Apr 2008 19:37:29 +0200
> Wolfgang Grandegger <wg...@gr...> wrote:
> > Wolfgang Köbler wrote:
> > > Is there any Expresscard Ethernet Network Interface Card that is
> > > supported by RTnet ?
> > The E1000 RTnet driver seems to support some PCI express cards.
> > Have a look to  e1000_hw.c for further details.
> Yes, that could be some Intel Pro/1000 cards I have already seen in
> Online-Shops.
> 
> But I am looking for Cards that fit into a (modern) Notebook. The
> ExpressCard slot replaces the CardBus PC card slot, has about its size
> but has PCI-E signals instead of PCI signals.
> 
> I found RTL-8139 Cards for Cardbus, but what about ExpressCard ?
> 
> Bye,
> Wolfgang

Re: [RTnet-developers] Multicast patch

[Gilles C. <gil...@gm...>]

On Tue, Apr 22, 2008 at 6:06 PM, Bruno Carlus <b.c...@ip...> wrote:
> Hi all,
>
>  i'm sending you an up to date multicast patch, but not the final one (i'm
> not still happy with everything yet ...!)
>  I've tested it but it could remain bugs ...

I see many:

if (!(rtdev->flags & IFF_LOOPBACK) && (rtdev->flags & IFF_MULTICAST))

why not:

if (rtdev->flags & (IFF_LOOPBACK | IFF_MULTICAST) == IFF_MULTICAST)

?


-- 
 Gilles

[RTnet-developers] Multicast patch

[Bruno C. <b.c...@ip...>]

Hi all,

i'm sending you an up to date multicast patch, but not the final one 
(i'm not still happy with everything yet ...!)
I've tested it but it could remain bugs ...

Bruno.