* Re: [RFC PATCH] common receive API + r8169 use
From: Eric Dumazet @ 2011-08-08 16:47 UTC (permalink / raw)
To: Michał Mirosław; +Cc: Stephen Hemminger, netdev
In-Reply-To: <20110802214349.GA17411@rere.qmqm.pl>
Le mardi 02 août 2011 à 23:43 +0200, Michał Mirosław a écrit :
> I don't have fast enough transmitter yet, so have no real data. Eric's
> testing showed dramatic reduction in CPU usage after changing igb to use
> build_skb(). Inlined version of this patch should give similar results.
>
> Eric: can you share the igb changes? I have no hardware for it, but could
> merge our changes for you to test.
>
Hi Michal
I am just coming back from one vacation period, I'll send patches before
another one, maybe tomorrow, stay tuned ;)
^ permalink raw reply
* Re: Bonding problem
From: Jay Vosburgh @ 2011-08-08 17:06 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: Eduard Sinelnikov, netdev
In-Reply-To: <20110808162645.GT21309@gospo.rdu.redhat.com>
Andy Gospodarek <andy@greyhouse.net> wrote:
>On Sun, Aug 07, 2011 at 03:00:30PM +0300, Eduard Sinelnikov wrote:
>> Hi,
>>
>> In the kernel 2.6.39.3 ( /drivers/net/bond/bond_main.c).
>> In the function ‘bond_xmit_roundrobin’
>> The code check if the bond is active via
>> ‘bond_is_active_slave(slave)’ Function call.
>> Which actually checks if the slave is backup or active
>> What is the meaning of slave being backup in round robin mode?
>> Correct me if I wrong but in round robin every slave should send a
>> packet, regardless of being active or backup.
>>
>> Thank you,
>> Eduard
>
>There probably is not a compelling reason to continue to have it. There
>may be a reason historically, but I'm not aware what that might be at
>this point. For modes other than active-backup, the value of
>slave->link and slave->backup should always contain a value that
>indicates the slave is up and available for transmit.
If you read Eduard's other posts regarding this, the actual
issue is that when changing from another mode into round-robin,
occasionally slaves will still be marked as "backup" and won't be used:
>Date: Mon, 8 Aug 2011 11:16:39 +0300
>Subject: On line Bonding configuration change fails
>From: Eduard Sinelnikov <eduard.sinelnikov@gmail.com>
>To: netdev@vger.kernel.org
>Sender: netdev-owner@vger.kernel.org
>
>Hi,
>
>My configuration is a follows:
>
> | eth0 -------------->
>Ububntu | eth1 --------------> Swith ------------> Other computer
>
>Scenario:
>• change the bond mode to active/backup
>• unplug some of the cable
>• plug-in the unplugged cable
>• change bond mode to round robin
>
>I can see that only one eth1 is sending data. When I unplug it the ping stops.
>
>Is it a bug or some mis-configuration?
>
>In the kernel ( /drivers/net/bond/bond_main.c).
>In the function ‘bond_xmit_roundrobin
>’
>The code check if the bond is active via
>‘bond_is_active_slave(slave)’ Function call.
>Which actually checks if the slave is backup or active
>What is the meaning of backup in round robin?
>Correct me if I wrong but in round robin every slave should send a
>packet, regardless of being active or backup.
So from looking at the code, it seems that the actual problem is
that when transitioning to round-robin mode, one or more slaves can
remain marked as "backup," and in round-robin mode, that won't ever
change. We could probably work around that by removing the "is_active"
test (essentially declaring that "is_active" is only valid in
active-backup mode). That might produce a few odd messages here and
there (when removing a slave or during a link failure, for example).
From inspection, the bond_xmit_xor function likely has this same
problem.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: Bonding problem
From: Andy Gospodarek @ 2011-08-08 17:31 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: Andy Gospodarek, Eduard Sinelnikov, netdev
In-Reply-To: <26478.1312823165@death>
On Mon, Aug 08, 2011 at 10:06:05AM -0700, Jay Vosburgh wrote:
>
> Andy Gospodarek <andy@greyhouse.net> wrote:
>
> >On Sun, Aug 07, 2011 at 03:00:30PM +0300, Eduard Sinelnikov wrote:
> >> Hi,
> >>
> >> In the kernel 2.6.39.3 ( /drivers/net/bond/bond_main.c).
> >> In the function ‘bond_xmit_roundrobin’
> >> The code check if the bond is active via
> >> ‘bond_is_active_slave(slave)’ Function call.
> >> Which actually checks if the slave is backup or active
> >> What is the meaning of slave being backup in round robin mode?
> >> Correct me if I wrong but in round robin every slave should send a
> >> packet, regardless of being active or backup.
> >>
> >> Thank you,
> >> Eduard
> >
> >There probably is not a compelling reason to continue to have it. There
> >may be a reason historically, but I'm not aware what that might be at
> >this point. For modes other than active-backup, the value of
> >slave->link and slave->backup should always contain a value that
> >indicates the slave is up and available for transmit.
>
> If you read Eduard's other posts regarding this, the actual
> issue is that when changing from another mode into round-robin,
> occasionally slaves will still be marked as "backup" and won't be used:
>
I did notice that one after I sent this first response.
> >Date: Mon, 8 Aug 2011 11:16:39 +0300
> >Subject: On line Bonding configuration change fails
> >From: Eduard Sinelnikov <eduard.sinelnikov@gmail.com>
> >To: netdev@vger.kernel.org
> >Sender: netdev-owner@vger.kernel.org
> >
> >Hi,
> >
> >My configuration is a follows:
> >
> > | eth0 -------------->
> >Ububntu | eth1 --------------> Swith ------------> Other computer
> >
> >Scenario:
> >• change the bond mode to active/backup
> >• unplug some of the cable
> >• plug-in the unplugged cable
> >• change bond mode to round robin
> >
> >I can see that only one eth1 is sending data. When I unplug it the ping stops.
> >
> >Is it a bug or some mis-configuration?
> >
> >In the kernel ( /drivers/net/bond/bond_main.c).
> >In the function ‘bond_xmit_roundrobin
> >’
> >The code check if the bond is active via
> >‘bond_is_active_slave(slave)’ Function call.
> >Which actually checks if the slave is backup or active
> >What is the meaning of backup in round robin?
> >Correct me if I wrong but in round robin every slave should send a
> >packet, regardless of being active or backup.
>
> So from looking at the code, it seems that the actual problem is
> that when transitioning to round-robin mode, one or more slaves can
> remain marked as "backup," and in round-robin mode, that won't ever
> change. We could probably work around that by removing the "is_active"
> test (essentially declaring that "is_active" is only valid in
> active-backup mode). That might produce a few odd messages here and
> there (when removing a slave or during a link failure, for example).
>
> From inspection, the bond_xmit_xor function likely has this same
> problem.
>
Agreed.
> -J
>
> ---
> -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [BUG] 3.0-rc1 Bridge not forwarding unicast packages
From: Michael Guntsche @ 2011-08-08 17:42 UTC (permalink / raw)
To: netdev, linux-kernel
Hi list,
I just upgraded my router/bridge combo to 3.1-rc1 from 3.0 for
testing. On a first look everything seemed to work fine, but when I
tried to connect via openvpn to my internal network (tap0 being bridged
with the internal network) I noticed that I was not able to access the
server on my internal network. I could access the bridge (which is
acting as the openvpn server as well) just fine though.
To debug this I ran tcpdump on the openvpn client and started a ping to the
internal network. I could see the ARP requests being answered.
19:23:49.247846 ARP, Request who-has 192.168.42.127 tell 192.168.42.96,
length 28
19:23:49.287752 ARP, Reply 192.168.42.127 is-at 00:13:d4:4f:a2:dc,
length 46
in this case .127 is the server on the internal net and .96 the openvpn
client, but the icmp request did not arrive on the server.
The strange thing I noticed was that I could see broadcasts packages
from the server on the client
19:23:28.135185 IP 192.168.42.127.631 > 192.168.42.255.631: UDP, length
187
19:23:29.470975 IP 192.168.42.96.5353 > 224.0.0.251.5353: .......
but no icmp packages arrived on the server side.
brctl showmacs lan
port no mac addr is local? ageing timer
1 00:0c:42:28:de:4e yes 0.00
2 00:0c:42:61:7f:f2 yes 0.00
1 00:13:d4:4f:a2:dc no 0.00 <---- server on the lan side
3 8e:22:41:d9:95:23 yes 0.00
3 b6:e1:e3:06:c9:1a no 5.00 <---- client connected via tap0
Reverting to 3.0 solves the problem for me. I tried just reverting the bridge code on the server to the 3.0 version to make sure that it is really Bridge related, but there are too many changes outside the bridge tree so compilation fails for me.
If you need more information, please to not hesitate to conact me.
Kind regards,
Michael Guntsche
^ permalink raw reply
* Re: [BUG] 3.0-rc1 Bridge not forwarding unicast packages
From: Stephen Hemminger @ 2011-08-08 17:48 UTC (permalink / raw)
To: Michael Guntsche; +Cc: netdev, linux-kernel
In-Reply-To: <20110808192646@it-loops.com>
On Mon, 8 Aug 2011 19:42:19 +0200
Michael Guntsche <mike@it-loops.com> wrote:
> Hi list,
>
> I just upgraded my router/bridge combo to 3.1-rc1 from 3.0 for
> testing. On a first look everything seemed to work fine, but when I
> tried to connect via openvpn to my internal network (tap0 being bridged
> with the internal network) I noticed that I was not able to access the
> server on my internal network. I could access the bridge (which is
> acting as the openvpn server as well) just fine though.
> To debug this I ran tcpdump on the openvpn client and started a ping to the
> internal network. I could see the ARP requests being answered.
>
> 19:23:49.247846 ARP, Request who-has 192.168.42.127 tell 192.168.42.96,
> length 28
> 19:23:49.287752 ARP, Reply 192.168.42.127 is-at 00:13:d4:4f:a2:dc,
> length 46
>
> in this case .127 is the server on the internal net and .96 the openvpn
> client, but the icmp request did not arrive on the server.
> The strange thing I noticed was that I could see broadcasts packages
> from the server on the client
>
> 19:23:28.135185 IP 192.168.42.127.631 > 192.168.42.255.631: UDP, length
> 187
> 19:23:29.470975 IP 192.168.42.96.5353 > 224.0.0.251.5353: .......
>
> but no icmp packages arrived on the server side.
>
>
> brctl showmacs lan
> port no mac addr is local? ageing timer
> 1 00:0c:42:28:de:4e yes 0.00
> 2 00:0c:42:61:7f:f2 yes 0.00
> 1 00:13:d4:4f:a2:dc no 0.00 <---- server on the lan side
> 3 8e:22:41:d9:95:23 yes 0.00
> 3 b6:e1:e3:06:c9:1a no 5.00 <---- client connected via tap0
>
> Reverting to 3.0 solves the problem for me. I tried just reverting the bridge code on the server to the 3.0 version to make sure that it is really Bridge related, but there are too many changes outside the bridge tree so compilation fails for me.
>
> If you need more information, please to not hesitate to conact me.
>
> Kind regards,
> Michael Guntsche
Do you have spanning tree enabled?
If so you may have a packet loop and now it is being detected.
^ permalink raw reply
* Re: [RFC PATCH v2 0/9] bql: Byte Queue Limits
From: Tom Herbert @ 2011-08-08 17:51 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: davem, netdev
In-Reply-To: <20110808084016.063a0699@nehalam.ftrdhcpuser.net>
On Mon, Aug 8, 2011 at 8:40 AM, Stephen Hemminger <shemminger@vyatta.com> wrote:
> On Sun, 7 Aug 2011 21:43:13 -0700 (PDT)
> Tom Herbert <therbert@google.com> wrote:
>
>> netdev_tx_completed_queue: Called at end of transmit completion
>> to inform stack of number of bytes and packets processed.
>> netdev_tx_sent_queue: Called to inform stack when packets are
>> queued.
>
> Couldn't these be done for the device in the existing qdisc infra
> structure (or dev_start_xmit). Alternatively, rename ndo_start_xmit
> to something else and make all the callers use the wrapper.
>
> Changing all the drivers for something that the driver has no real
> need to care about seems like incorrect object design.
>
The netdev_tx_completed_queue is needed to inform the stack of number
of packets and bytes completed in an execution of transmit completion
(epic). I don't see a way to get that information outside of the
driver.
Tom
^ permalink raw reply
* Re: [RFC PATCH v2 0/9] bql: Byte Queue Limits
From: Stephen Hemminger @ 2011-08-08 17:55 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <CA+mtBx_vgsH+uHLi6p80E8CEhU7SHXY=Fw1Z-W2OFWy44LP-ig@mail.gmail.com>
On Mon, 8 Aug 2011 10:51:06 -0700
Tom Herbert <therbert@google.com> wrote:
> On Mon, Aug 8, 2011 at 8:40 AM, Stephen Hemminger <shemminger@vyatta.com> wrote:
> > On Sun, 7 Aug 2011 21:43:13 -0700 (PDT)
> > Tom Herbert <therbert@google.com> wrote:
> >
> >> netdev_tx_completed_queue: Called at end of transmit completion
> >> to inform stack of number of bytes and packets processed.
> >> netdev_tx_sent_queue: Called to inform stack when packets are
> >> queued.
> >
> > Couldn't these be done for the device in the existing qdisc infra
> > structure (or dev_start_xmit). Alternatively, rename ndo_start_xmit
> > to something else and make all the callers use the wrapper.
> >
> > Changing all the drivers for something that the driver has no real
> > need to care about seems like incorrect object design.
> >
> The netdev_tx_completed_queue is needed to inform the stack of number
> of packets and bytes completed in an execution of transmit completion
> (epic). I don't see a way to get that information outside of the
> driver.
>
> Tom
Since transmit completion means calling dev_kfree_skb() why not account
there? You could add some info to netdev if necessary to get compile
the statistics.
I just hate driver api complexity growth.
^ permalink raw reply
* Re: [RFC PATCH v2 0/9] bql: Byte Queue Limits
From: Tom Herbert @ 2011-08-08 17:56 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: davem, netdev
In-Reply-To: <20110808105529.4c8c52e1@nehalam.ftrdhcpuser.net>
On Mon, Aug 8, 2011 at 10:55 AM, Stephen Hemminger
<shemminger@vyatta.com> wrote:
> On Mon, 8 Aug 2011 10:51:06 -0700
> Tom Herbert <therbert@google.com> wrote:
>
>> On Mon, Aug 8, 2011 at 8:40 AM, Stephen Hemminger <shemminger@vyatta.com> wrote:
>> > On Sun, 7 Aug 2011 21:43:13 -0700 (PDT)
>> > Tom Herbert <therbert@google.com> wrote:
>> >
>> >> netdev_tx_completed_queue: Called at end of transmit completion
>> >> to inform stack of number of bytes and packets processed.
>> >> netdev_tx_sent_queue: Called to inform stack when packets are
>> >> queued.
>> >
>> > Couldn't these be done for the device in the existing qdisc infra
>> > structure (or dev_start_xmit). Alternatively, rename ndo_start_xmit
>> > to something else and make all the callers use the wrapper.
>> >
>> > Changing all the drivers for something that the driver has no real
>> > need to care about seems like incorrect object design.
>> >
>> The netdev_tx_completed_queue is needed to inform the stack of number
>> of packets and bytes completed in an execution of transmit completion
>> (epic). I don't see a way to get that information outside of the
>> driver.
>>
>> Tom
>
> Since transmit completion means calling dev_kfree_skb() why not account
> there? You could add some info to netdev if necessary to get compile
> the statistics.
>
> I just hate driver api complexity growth.
>
>
^ permalink raw reply
* Re: [RFC PATCH v2 0/9] bql: Byte Queue Limits
From: Tom Herbert @ 2011-08-08 18:01 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: davem, netdev
In-Reply-To: <20110808105529.4c8c52e1@nehalam.ftrdhcpuser.net>
> Since transmit completion means calling dev_kfree_skb() why not account
> there? You could add some info to netdev if necessary to get compile
> the statistics.
>
The algorithm depends on knowing the total number of packets competed
in a single execution of transmit completion (epic based). We only
want to recalculate the limits once per completion, which happens when
the completion function is called.
> I just hate driver api complexity growth.
>
>
^ permalink raw reply
* Re: [BUG] 3.0-rc1 Bridge not forwarding unicast packages
From: Michael Guntsche @ 2011-08-08 18:02 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, linux-kernel
In-Reply-To: <20110808104803.2762dbf7@nehalam.ftrdhcpuser.net>
On 08 Aug 11 10:48, Stephen Hemminger wrote:
> On Mon, 8 Aug 2011 19:42:19 +0200
> Michael Guntsche <mike@it-loops.com> wrote:
>
> > Hi list,
> >
> > I just upgraded my router/bridge combo to 3.1-rc1 from 3.0 for
> > testing. On a first look everything seemed to work fine, but when I
> > tried to connect via openvpn to my internal network (tap0 being bridged
> > with the internal network) I noticed that I was not able to access the
> > server on my internal network. I could access the bridge (which is
> > acting as the openvpn server as well) just fine though.
> > To debug this I ran tcpdump on the openvpn client and started a ping to the
> > internal network. I could see the ARP requests being answered.
> >
> > 19:23:49.247846 ARP, Request who-has 192.168.42.127 tell 192.168.42.96,
> > length 28
> > 19:23:49.287752 ARP, Reply 192.168.42.127 is-at 00:13:d4:4f:a2:dc,
> > length 46
> >
> > in this case .127 is the server on the internal net and .96 the openvpn
> > client, but the icmp request did not arrive on the server.
> > The strange thing I noticed was that I could see broadcasts packages
> > from the server on the client
> >
> > 19:23:28.135185 IP 192.168.42.127.631 > 192.168.42.255.631: UDP, length
> > 187
> > 19:23:29.470975 IP 192.168.42.96.5353 > 224.0.0.251.5353: .......
> >
> > but no icmp packages arrived on the server side.
> >
> >
> > brctl showmacs lan
> > port no mac addr is local? ageing timer
> > 1 00:0c:42:28:de:4e yes 0.00
> > 2 00:0c:42:61:7f:f2 yes 0.00
> > 1 00:13:d4:4f:a2:dc no 0.00 <---- server on the lan side
> > 3 8e:22:41:d9:95:23 yes 0.00
> > 3 b6:e1:e3:06:c9:1a no 5.00 <---- client connected via tap0
> >
> > Reverting to 3.0 solves the problem for me. I tried just reverting the bridge code on the server to the 3.0 version to make sure that it is really Bridge related, but there are too many changes outside the bridge tree so compilation fails for me.
> >
> > If you need more information, please to not hesitate to conact me.
> >
> > Kind regards,
> > Michael Guntsche
>
> Do you have spanning tree enabled?
> If so you may have a packet loop and now it is being detected.
No STP is not enabled
brctl show lan
bridge name bridge id STP enabled interfaces
lan 8000.000c4228de4e no lan_wire
tap0
wlan0
No ebtables rules either just checked that.
Is there a way to revert just the bridge code to the 3.0 version so i can make sure it is really the bridge code, and not something else?
Kind regards,
Mike
PS: And of COURSE the subject line should be 3.1-rc1!!!! Sorry
^ permalink raw reply
* Re: [RFC PATCH v2 0/9] bql: Byte Queue Limits
From: Stephen Hemminger @ 2011-08-08 18:19 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <CA+mtBx_bdCGvR+xBMq9px0vOV6a6kFn0wYyJH26+CdSPLtvgfw@mail.gmail.com>
On Mon, 8 Aug 2011 11:01:57 -0700
Tom Herbert <therbert@google.com> wrote:
> > Since transmit completion means calling dev_kfree_skb() why not account
> > there? You could add some info to netdev if necessary to get compile
> > the statistics.
> >
> The algorithm depends on knowing the total number of packets competed
> in a single execution of transmit completion (epic based). We only
> want to recalculate the limits once per completion, which happens when
> the completion function is called.
So just add some stats to netdev and count the number of dev_kfree_skb
calls and do your work at napi complete.
^ permalink raw reply
* Re: [BUG] 3.0-rc1 Bridge not forwarding unicast packages
From: Stephen Hemminger @ 2011-08-08 18:20 UTC (permalink / raw)
To: Michael Guntsche; +Cc: netdev, linux-kernel
In-Reply-To: <20110808195930@it-loops.com>
On Mon, 8 Aug 2011 20:02:52 +0200
Michael Guntsche <mike@it-loops.com> wrote:
> On 08 Aug 11 10:48, Stephen Hemminger wrote:
> > On Mon, 8 Aug 2011 19:42:19 +0200
> > Michael Guntsche <mike@it-loops.com> wrote:
> >
> > > Hi list,
> > >
> > > I just upgraded my router/bridge combo to 3.1-rc1 from 3.0 for
> > > testing. On a first look everything seemed to work fine, but when I
> > > tried to connect via openvpn to my internal network (tap0 being bridged
> > > with the internal network) I noticed that I was not able to access the
> > > server on my internal network. I could access the bridge (which is
> > > acting as the openvpn server as well) just fine though.
> > > To debug this I ran tcpdump on the openvpn client and started a ping to the
> > > internal network. I could see the ARP requests being answered.
> > >
> > > 19:23:49.247846 ARP, Request who-has 192.168.42.127 tell 192.168.42.96,
> > > length 28
> > > 19:23:49.287752 ARP, Reply 192.168.42.127 is-at 00:13:d4:4f:a2:dc,
> > > length 46
> > >
> > > in this case .127 is the server on the internal net and .96 the openvpn
> > > client, but the icmp request did not arrive on the server.
> > > The strange thing I noticed was that I could see broadcasts packages
> > > from the server on the client
> > >
> > > 19:23:28.135185 IP 192.168.42.127.631 > 192.168.42.255.631: UDP, length
> > > 187
> > > 19:23:29.470975 IP 192.168.42.96.5353 > 224.0.0.251.5353: .......
> > >
> > > but no icmp packages arrived on the server side.
> > >
> > >
> > > brctl showmacs lan
> > > port no mac addr is local? ageing timer
> > > 1 00:0c:42:28:de:4e yes 0.00
> > > 2 00:0c:42:61:7f:f2 yes 0.00
> > > 1 00:13:d4:4f:a2:dc no 0.00 <---- server on the lan side
> > > 3 8e:22:41:d9:95:23 yes 0.00
> > > 3 b6:e1:e3:06:c9:1a no 5.00 <---- client connected via tap0
> > >
> > > Reverting to 3.0 solves the problem for me. I tried just reverting the bridge code on the server to the 3.0 version to make sure that it is really Bridge related, but there are too many changes outside the bridge tree so compilation fails for me.
> > >
> > > If you need more information, please to not hesitate to conact me.
> > >
> > > Kind regards,
> > > Michael Guntsche
> >
> > Do you have spanning tree enabled?
> > If so you may have a packet loop and now it is being detected.
> No STP is not enabled
>
> brctl show lan
> bridge name bridge id STP enabled interfaces
> lan 8000.000c4228de4e no lan_wire
> tap0
> wlan0
>
> No ebtables rules either just checked that.
> Is there a way to revert just the bridge code to the 3.0 version so i can make sure it is really the bridge code, and not something else?
>
You need to use git bisect, it is not necessarily the bridge code.
Could be vpn, tap, wlan or lots of other things.
^ permalink raw reply
* Re: [PATCH 11/12] headers, scc: Add missing #include to <linux/scc.h>
From: Ben Hutchings @ 2011-08-08 18:20 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Joerg Reuter, Klaus Kudielka, linux-hams
In-Reply-To: <1312809869.2591.1151.camel@deadeye>
On Mon, Aug 08, 2011 at 02:24:29PM +0100, Ben Hutchings wrote:
> <linux/scc.h> uses SIOCDEVPRIVATE, defined in <linux/sockios.h>.
Unfortunately SIOCDEVPRIVATE is also defined elsewhere by glibc,
so including <linux/sockios.h> can result in duplicate definitions.
So I don't think we can make this change.
Ben.
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> ---
> This file isn't listed in MAINTAINERS but appears to be associated with
> one of the hamradio drivers; please could one of the hams claim it?
>
> Ben.
>
> include/linux/scc.h | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/scc.h b/include/linux/scc.h
> index 3495bd9..d5916e5 100644
> --- a/include/linux/scc.h
> +++ b/include/linux/scc.h
> @@ -3,6 +3,7 @@
> #ifndef _SCC_H
> #define _SCC_H
>
> +#include <linux/sockios.h>
>
> /* selection of hardware types */
>
> --
> 1.7.5.4
>
>
>
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
^ permalink raw reply
* Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock source.
From: Wolfgang Grandegger @ 2011-08-08 18:37 UTC (permalink / raw)
To: Robin Holt
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, Marc Kleine-Budde,
U Bhaskar-B22300
In-Reply-To: <20110808160810.GF4926-sJ/iWh9BUns@public.gmane.org>
On 08/08/2011 06:08 PM, Robin Holt wrote:
> On Mon, Aug 08, 2011 at 06:03:06PM +0200, Wolfgang Grandegger wrote:
...
> So we would stay with the clk_* functions. I assume clk_get() would
> return NULL, clk_get_rate() would just return fsl_get_sys_freq() and
> the other functions would do nothing. Doesn't this really polute what
> clk_* functions are supposed to do? Aren't we making flexcan dictate
> a different behavior for powerpc than for the arm (and possibly other)
> architectures?
Well, I see it as one way to provide compatibility with the ARM port. If
the PowerPC people don't like it, we can switch to something else,
whatever they suggest.
Wolfgang.
^ permalink raw reply
* Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock source.
From: Marc Kleine-Budde @ 2011-08-08 18:53 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300
In-Reply-To: <4E4001E1.3030508-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1333 bytes --]
On 08/08/2011 05:33 PM, Wolfgang Grandegger wrote:
>> ACK - The device tree bindings as in mainline's Documentation is a mess.
>> If the powerpc guys are happy with a clock interfaces based approach
>> somewhere in arch/ppc, I'm more than happy to remove:
>> - fsl,flexcan-clock-source (not implemented, even in the fsl driver)
>>
>> - fsl,flexcan-clock-divider \__ replace with code in arch/ppc, or
>> - clock-frequency / a single clock-frequency attribute
>
> In the "net-next-2.6" tree there is also:
>
> $ grep flexcan arch/powerpc/boots/dts/*.dts
> p1010rdb.dts: fsl,flexcan-clock-source = "platform";
> p1010rdb.dts: fsl,flexcan-clock-source = "platform";
> p1010si.dtsi: compatible = "fsl,flexcan-v1.0";
> p1010si.dtsi: fsl,flexcan-clock-divider = <2>;
> p1010si.dtsi: compatible = "fsl,flexcan-v1.0";
> p1010si.dtsi: fsl,flexcan-clock-divider = <2>;
>
> Especially the fsl,flexcan-clock-divider = <2>; might make people think,
> that they could set something else.
ARGH... :D
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock source.
From: Robin Holt @ 2011-08-08 19:14 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, Marc Kleine-Budde,
U Bhaskar-B22300
In-Reply-To: <4E402CF1.1040300-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On Mon, Aug 08, 2011 at 08:37:37PM +0200, Wolfgang Grandegger wrote:
> On 08/08/2011 06:08 PM, Robin Holt wrote:
> > On Mon, Aug 08, 2011 at 06:03:06PM +0200, Wolfgang Grandegger wrote:
> ...
> > So we would stay with the clk_* functions. I assume clk_get() would
> > return NULL, clk_get_rate() would just return fsl_get_sys_freq() and
> > the other functions would do nothing. Doesn't this really polute what
> > clk_* functions are supposed to do? Aren't we making flexcan dictate
> > a different behavior for powerpc than for the arm (and possibly other)
> > architectures?
>
> Well, I see it as one way to provide compatibility with the ARM port. If
> the PowerPC people don't like it, we can switch to something else,
> whatever they suggest.
I have spent the last few hours and I think I found the communication
problem and I think it is me.
I assumed long ago we would be better off implementing a Kconfig language
which does "select PPC_CLOCK". This assumption was in part because I
did not understand what I was doing when I started this (still don't
honestly), but I did know the freescale patch series did a select
PPC_CLOCK.
Here is my patch for introducing the p1010 clock source. Am I finally
starting to understand your guidance?
Thanks,
Robin
------------------------------------------------------------------------
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index 498534c..ed4cf92 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -26,6 +26,10 @@ config MPC8560_ADS
help
This option enables support for the MPC 8560 ADS board
+config 85xx_HAVE_CAN_FLEXCAN
+ bool
+ select HAVE_CAN_FLEXCAN if NET && CAN
+
config MPC85xx_CDS
bool "Freescale MPC85xx CDS"
select DEFAULT_UIMAGE
@@ -70,6 +74,8 @@ config MPC85xx_RDB
config P1010_RDB
bool "Freescale P1010RDB"
select DEFAULT_UIMAGE
+ select 85xx_HAVE_CAN_FLEXCAN
+ select PPC_CLOCK if CAN_FLEXCAN
help
This option enables support for the MPC85xx RDB (P1010 RDB) board
diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile
index a971b32..64ad7a4 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_MPC85xx_DS) += mpc85xx_ds.o
obj-$(CONFIG_MPC85xx_MDS) += mpc85xx_mds.o
obj-$(CONFIG_MPC85xx_RDB) += mpc85xx_rdb.o
obj-$(CONFIG_P1010_RDB) += p1010rdb.o
+obj-$(CONFIG_PPC_CLOCK) += clock.o
obj-$(CONFIG_P1022_DS) += p1022_ds.o
obj-$(CONFIG_P1023_RDS) += p1023_rds.o
obj-$(CONFIG_P2040_RDB) += p2040_rdb.o corenet_ds.o
diff --git a/arch/powerpc/platforms/85xx/p1010rdb.c b/arch/powerpc/platforms/85xx/p1010rdb.c
index d7387fa..29e04d6 100644
--- a/arch/powerpc/platforms/85xx/p1010rdb.c
+++ b/arch/powerpc/platforms/85xx/p1010rdb.c
@@ -81,6 +81,13 @@ static void __init p1010_rdb_setup_arch(void)
printk(KERN_INFO "P1010 RDB board from Freescale Semiconductor\n");
}
+static void __init p1010_rdb_init(void)
+{
+#ifdef PPC_CLOCK
+ p1010_rdb_clk_init();
+#endif
+}
+
static struct of_device_id __initdata p1010rdb_ids[] = {
{ .type = "soc", },
{ .compatible = "soc", },
@@ -111,6 +118,7 @@ define_machine(p1010_rdb) {
.name = "P1010 RDB",
.probe = p1010_rdb_probe,
.setup_arch = p1010_rdb_setup_arch,
+ .init = p1010_rdb_init,
.init_IRQ = p1010_rdb_pic_init,
#ifdef CONFIG_PCI
.pcibios_fixup_bus = fsl_pcibios_fixup_bus,
--
1.7.2.1
^ permalink raw reply related
* Re: 802.3ad bonding brain damaged?
From: Phillip Susi @ 2011-08-08 20:06 UTC (permalink / raw)
To: David Lamparter; +Cc: netdev
In-Reply-To: <1312790234.7020.26.camel@arkology.n2.diac24.net>
On 8/8/2011 3:57 AM, David Lamparter wrote:
> No, it isn't. 802.3ad/.1AX explicitly requires that no packet
> re-ordering may ever occur, which can only be guaranteed by enqueueing
> packets for one host on one TX interface. This behaviour is mandated by
> 802.1AX-2008 page 15 which reads:
Outch, that does cause a big problem for store-and-forward switching.
You basically can't split up packets from a single stream without very
careful cut-through switching, which we obviously can't do in Linux.
That seems a rather silly requirement given that higher level protocols
already deal with packet reordering. Why not an option to say stuff the
standard?
^ permalink raw reply
* Re: [PATCHv4] Bridge: Always send NETDEV_CHANGEADDR up on br MAC change.
From: Stephen Hemminger @ 2011-08-08 20:12 UTC (permalink / raw)
To: Andrei Warkentin; +Cc: netdev
In-Reply-To: <1312578250-2944-2-git-send-email-andreiw@motorola.com>
On Fri, 5 Aug 2011 16:04:10 -0500
Andrei Warkentin <andreiw@motorola.com> wrote:
> This ensures the neighbor entries associated with the bridge
> dev are flushed, also invalidating the associated cached L2 headers.
>
> This means we br_add_if/br_del_if ports to implement hand-over and
> not wind up with bridge packets going out with stale MAC.
>
> This means we can also change MAC of port device and also not wind
> up with bridge packets going out with stale MAC.
>
> This builds on Stephen Hemminger's patch, also handling the br_del_if
> case and the port MAC change case.
>
> Cc: Stephen Hemminger <shemminger@vyatta.com>
> Signed-off-by: Andrei Warkentin <andreiw@motorola.com>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
^ permalink raw reply
* Re: 802.3ad bonding brain damaged?
From: Chris Adams @ 2011-08-08 20:08 UTC (permalink / raw)
To: netdev
In-Reply-To: <4E4041B5.5040908@cfl.rr.com>
Once upon a time, Phillip Susi <psusi@cfl.rr.com> said:
> On 8/8/2011 3:57 AM, David Lamparter wrote:
> >No, it isn't. 802.3ad/.1AX explicitly requires that no packet
> >re-ordering may ever occur, which can only be guaranteed by enqueueing
> >packets for one host on one TX interface. This behaviour is mandated by
> >802.1AX-2008 page 15 which reads:
>
> Outch, that does cause a big problem for store-and-forward switching.
> You basically can't split up packets from a single stream without very
> careful cut-through switching, which we obviously can't do in Linux.
> That seems a rather silly requirement given that higher level protocols
> already deal with packet reordering. Why not an option to say stuff the
> standard?
Packet reordering introduces jitter, which is bad for things like VOIP.
--
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
^ permalink raw reply
* Re: 802.3ad bonding brain damaged?
From: Chris Friesen @ 2011-08-08 20:14 UTC (permalink / raw)
To: Phillip Susi; +Cc: David Lamparter, netdev
In-Reply-To: <4E4041B5.5040908@cfl.rr.com>
On 08/08/2011 02:06 PM, Phillip Susi wrote:
> On 8/8/2011 3:57 AM, David Lamparter wrote:
>> No, it isn't. 802.3ad/.1AX explicitly requires that no packet
>> re-ordering may ever occur, which can only be guaranteed by enqueueing
>> packets for one host on one TX interface. This behaviour is mandated by
>> 802.1AX-2008 page 15 which reads:
>
> Outch, that does cause a big problem for store-and-forward switching.
> You basically can't split up packets from a single stream without very
> careful cut-through switching, which we obviously can't do in Linux.
> That seems a rather silly requirement given that higher level protocols
> already deal with packet reordering. Why not an option to say stuff the
> standard?
Bonding doesn't know about "higher level protocols". Also, assuming
that higher level protocols already deal with reordering can be
dangerous. I've dealt with network protocols and apps that assumed
there would be no reordering because at the time they were written they
used point-to-point links. They actually work fairly well with single
links, so it would be reasonable to try and keep them working with
bonded links.
Chris
--
Chris Friesen
Software Developer
GENBAND
chris.friesen@genband.com
www.genband.com
^ permalink raw reply
* Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock source.
From: Robin Holt @ 2011-08-08 20:27 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Robin Holt, socketcan-core, netdev, U Bhaskar-B22300,
Marc Kleine-Budde
In-Reply-To: <20110808191403.GG4926@sgi.com>
On Mon, Aug 08, 2011 at 02:14:03PM -0500, Robin Holt wrote:
> On Mon, Aug 08, 2011 at 08:37:37PM +0200, Wolfgang Grandegger wrote:
> > On 08/08/2011 06:08 PM, Robin Holt wrote:
> > > On Mon, Aug 08, 2011 at 06:03:06PM +0200, Wolfgang Grandegger wrote:
> > ...
> > > So we would stay with the clk_* functions. I assume clk_get() would
> > > return NULL, clk_get_rate() would just return fsl_get_sys_freq() and
> > > the other functions would do nothing. Doesn't this really polute what
> > > clk_* functions are supposed to do? Aren't we making flexcan dictate
> > > a different behavior for powerpc than for the arm (and possibly other)
> > > architectures?
> >
> > Well, I see it as one way to provide compatibility with the ARM port. If
> > the PowerPC people don't like it, we can switch to something else,
> > whatever they suggest.
>
> I have spent the last few hours and I think I found the communication
> problem and I think it is me.
>
> I assumed long ago we would be better off implementing a Kconfig language
> which does "select PPC_CLOCK". This assumption was in part because I
> did not understand what I was doing when I started this (still don't
> honestly), but I did know the freescale patch series did a select
> PPC_CLOCK.
>
> Here is my patch for introducing the p1010 clock source. Am I finally
> starting to understand your guidance?
>
> Thanks,
> Robin
>
Here is _ALL_ of the patch. Sorry about the earlier noise.
Robin
------------------------------------------------------------------------
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index 498534c..ed4cf92 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -26,6 +26,10 @@ config MPC8560_ADS
help
This option enables support for the MPC 8560 ADS board
+config 85xx_HAVE_CAN_FLEXCAN
+ bool
+ select HAVE_CAN_FLEXCAN if NET && CAN
+
config MPC85xx_CDS
bool "Freescale MPC85xx CDS"
select DEFAULT_UIMAGE
@@ -70,6 +74,8 @@ config MPC85xx_RDB
config P1010_RDB
bool "Freescale P1010RDB"
select DEFAULT_UIMAGE
+ select 85xx_HAVE_CAN_FLEXCAN
+ select PPC_CLOCK if CAN_FLEXCAN
help
This option enables support for the MPC85xx RDB (P1010 RDB) board
diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile
index a971b32..64ad7a4 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_MPC85xx_DS) += mpc85xx_ds.o
obj-$(CONFIG_MPC85xx_MDS) += mpc85xx_mds.o
obj-$(CONFIG_MPC85xx_RDB) += mpc85xx_rdb.o
obj-$(CONFIG_P1010_RDB) += p1010rdb.o
+obj-$(CONFIG_PPC_CLOCK) += clock.o
obj-$(CONFIG_P1022_DS) += p1022_ds.o
obj-$(CONFIG_P1023_RDS) += p1023_rds.o
obj-$(CONFIG_P2040_RDB) += p2040_rdb.o corenet_ds.o
diff --git a/arch/powerpc/platforms/85xx/clock.c b/arch/powerpc/platforms/85xx/clock.c
new file mode 100644
index 0000000..a25cbf3
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/clock.c
@@ -0,0 +1,59 @@
+
+#include <linux/device.h>
+#include <linux/err.h>
+
+#include <asm/clk_interface.h>
+
+#include <sysdev/fsl_soc.h>
+
+/*
+ * p1010rdb needs to provide a clock source for the flexcan driver.
+ */
+struct clk {
+ unsigned long rate;
+} p1010_rdb_system_clock;
+
+static struct clk *p1010_rdb_clk_get(struct device *dev, const char *id)
+{
+ const char *dev_init_name;
+
+ if (!dev)
+ return ERR_PTR(-ENOENT);
+
+ /*
+ * The can devices are named ffe1c000.can0 and ffe1d000.can1 on
+ * the p1010rdb. Check for the "can" portion of that name before
+ * returning a clock source.
+ */
+ dev_init_name = dev_name(dev);
+ if (strlen(dev_init_name) != 13)
+ return ERR_PTR(-ENOENT);
+ dev_init_name += 9;
+ if (strncmp(dev_init_name, "can", 3))
+ return ERR_PTR(-ENOENT);
+
+ return &p1010_rdb_system_clock;
+}
+
+static void p1010_rdb_clk_put(struct clk *clk)
+{
+ return;
+}
+
+static unsigned long p1010_rdb_clk_get_rate(struct clk *clk)
+{
+ return clk->rate;
+}
+
+static struct clk_interface p1010_rdb_clk_functions = {
+ .clk_get = p1010_rdb_clk_get,
+ .clk_get_rate = p1010_rdb_clk_get_rate,
+ .clk_put = p1010_rdb_clk_put,
+};
+
+void __init p1010_rdb_clk_init(void)
+{
+ p1010_rdb_system_clock.rate = fsl_get_sys_freq();
+ clk_functions = p1010_rdb_clk_functions;
+}
+
diff --git a/arch/powerpc/platforms/85xx/p1010rdb.c b/arch/powerpc/platforms/85xx/p1010rdb.c
index d7387fa..29e04d6 100644
--- a/arch/powerpc/platforms/85xx/p1010rdb.c
+++ b/arch/powerpc/platforms/85xx/p1010rdb.c
@@ -81,6 +81,13 @@ static void __init p1010_rdb_setup_arch(void)
printk(KERN_INFO "P1010 RDB board from Freescale Semiconductor\n");
}
+static void __init p1010_rdb_init(void)
+{
+#ifdef PPC_CLOCK
+ p1010_rdb_clk_init();
+#endif
+}
+
static struct of_device_id __initdata p1010rdb_ids[] = {
{ .type = "soc", },
{ .compatible = "soc", },
@@ -111,6 +118,7 @@ define_machine(p1010_rdb) {
.name = "P1010 RDB",
.probe = p1010_rdb_probe,
.setup_arch = p1010_rdb_setup_arch,
+ .init = p1010_rdb_init,
.init_IRQ = p1010_rdb_pic_init,
#ifdef CONFIG_PCI
.pcibios_fixup_bus = fsl_pcibios_fixup_bus,
--
1.7.2.1
^ permalink raw reply related
* Re: 802.3ad bonding brain damaged?
From: Phillip Susi @ 2011-08-08 20:32 UTC (permalink / raw)
To: Chris Friesen; +Cc: David Lamparter, netdev
In-Reply-To: <4E4043AB.1060500@genband.com>
On 8/8/2011 4:14 PM, Chris Friesen wrote:
> Bonding doesn't know about "higher level protocols". Also, assuming that
> higher level protocols already deal with reordering can be dangerous.
> I've dealt with network protocols and apps that assumed there would be
> no reordering because at the time they were written they used
> point-to-point links. They actually work fairly well with single links,
> so it would be reasonable to try and keep them working with bonded links.
Try, sure, but if you can't without seriously affecting performance,
then having a knob for damn the torpedoes, full speed ahead mode seems
reasonable.
I wonder how it is that people have reported that Windows machines
manage to do this? Come to think of it, can windows even bond in
software? Maybe it's only possible on Windows with dual port cards
where the drivers and hardware can make sure that the bonded interfaces
service a single queue and maintain ordering that way?
^ permalink raw reply
* Re: 802.3ad bonding brain damaged?
From: Ben Hutchings @ 2011-08-08 20:42 UTC (permalink / raw)
To: Phillip Susi; +Cc: Chris Friesen, David Lamparter, netdev
In-Reply-To: <4E4047CF.5030705@cfl.rr.com>
On Mon, 2011-08-08 at 16:32 -0400, Phillip Susi wrote:
> On 8/8/2011 4:14 PM, Chris Friesen wrote:
> > Bonding doesn't know about "higher level protocols". Also, assuming that
> > higher level protocols already deal with reordering can be dangerous.
> > I've dealt with network protocols and apps that assumed there would be
> > no reordering because at the time they were written they used
> > point-to-point links. They actually work fairly well with single links,
> > so it would be reasonable to try and keep them working with bonded links.
>
> Try, sure, but if you can't without seriously affecting performance,
> then having a knob for damn the torpedoes, full speed ahead mode seems
> reasonable.
>
> I wonder how it is that people have reported that Windows machines
> manage to do this? Come to think of it, can windows even bond in
> software? Maybe it's only possible on Windows with dual port cards
> where the drivers and hardware can make sure that the bonded interfaces
> service a single queue and maintain ordering that way?
Microsoft doesn't provide a generic bonding driver for Windows. (This
probably a sensible choice, considering how many different things people
expect the Linux bonding driver to do.) Some hardware vendors provide
bonding or 'teaming' drivers that work with their own hardware, and
sometimes with other drivers as well. So if people report that 'Windows
machines manage to do this' then you need to ask those people *which*
driver they are using.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: 802.3ad bonding brain damaged?
From: Rick Jones @ 2011-08-08 20:54 UTC (permalink / raw)
To: Phillip Susi; +Cc: David Lamparter, netdev
In-Reply-To: <4E4041B5.5040908@cfl.rr.com>
On 08/08/2011 01:06 PM, Phillip Susi wrote:
> On 8/8/2011 3:57 AM, David Lamparter wrote:
>> No, it isn't. 802.3ad/.1AX explicitly requires that no packet
>> re-ordering may ever occur, which can only be guaranteed by enqueueing
>> packets for one host on one TX interface. This behaviour is mandated by
>> 802.1AX-2008 page 15 which reads:
>
> Outch, that does cause a big problem for store-and-forward switching.
> You basically can't split up packets from a single stream without very
> careful cut-through switching, which we obviously can't do in Linux.
> That seems a rather silly requirement given that higher level protocols
> already deal with packet reordering. Why not an option to say stuff the
> standard?
At even in the case of protocols that deal with packet reordering, it is
still quite possible to be sub-optimal. Try running a TCP_STREAM test
through a mode-rr bond with 4 or more links in it. I suspect that even
without injecting the occasional "other" packet there can be enough
re-ordering to trigger spurious fast retransmissions. At the very least
it will trigger lots of immediate ACKnowledgements, which will drive-up
the CPU utilization per KB transferred. And if these spread packets
arrive still spread at the receiver, round-robin will probably preclude
effective GRO and certainly preclude LRO.
Apart from some very carefully controlled conditions, if one needs a
single flow to go faster than a single link, it is probably time to move
up to the next higher link speed.
rick jones
^ permalink raw reply
* [Patch] Correct assignment of uid to gid in credentials
From: Tim Chen @ 2011-08-08 22:08 UTC (permalink / raw)
To: Eric W. Biederman, Eric Dumazet, David S. Miller, Al Viro
Cc: ak, Al Viro, linux-kernel, netdev
This patch corrects an erroneous assignment of uid to gid in credentials
update.
Tim
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
diff --git a/net/core/scm.c b/net/core/scm.c
index 4c1ef02..811b53f 100644
--- a/net/core/scm.c
+++ b/net/core/scm.c
@@ -192,7 +192,7 @@ int __scm_send(struct socket *sock, struct msghdr
*msg, struct scm_cookie *p)
goto error;
cred->uid = cred->euid = p->creds.uid;
- cred->gid = cred->egid = p->creds.uid;
+ cred->gid = cred->egid = p->creds.gid;
put_cred(p->cred);
p->cred = cred;
}
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox