* Re: [PATCH 4/6] vlan: Optimize multiple unregistration
From: Eric Dumazet @ 2009-10-29 14:30 UTC (permalink / raw)
To: Patrick McHardy; +Cc: David S. Miller, Linux Netdev List
In-Reply-To: <4AE9A554.8030207@trash.net>
Patrick McHardy a écrit :
> Patrick McHardy wrote:
>> Eric Dumazet wrote:
>>> Patrick McHardy a écrit :
>>>>> +{
>>>>> + LIST_HEAD(list);
>>>>> + int i;
>>>>> + struct net_device *vlandev;
>>>>> + struct vlan_group save;
>>>>> +
>>>>> + memcpy(&save, grp, sizeof(save));
>>>>> + memset(&grp->vlan_devices_arrays, 0, sizeof(grp->vlan_devices_arrays));
>>>> This shouldn't be necessary since the lower device is already in the
>>>> process of being unregistered. If it was necessary, it could cause
>>>> crashes since the individual pointers are not set to zero atomically.
>>>> Or maybe I'm misunderstanding the purpose entirely :)
>>> Very good point indeed, even if in practice memset() use long word transferts
>>>
>>> I'll make a cleanup patch, or do you want to do it ?
>> I can take care of this, patch will follow shortly.
>
> How about this? I moved the code back into vlan_device_event() since
> its now only a very minimal change to the original code.
>
> vlan-orig.diff contains the diff between the original code and the
> code after this patch for reference.
>
>
I have no problem with this solution, but I wonder why you re-added the curious
/* unregistration of last vlan destroys group, abort
* afterwards */
if (grp->nr_vlans == 1)
i = VLAN_GROUP_ARRAY_LEN;
unregister_vlan_dev(vlandev, &list);
while doing
unregister_vlan_dev(vlandev, &list);
if (grp->nr_vlans == 0)
break;
seems more natural :)
^ permalink raw reply
* Re: [PATCH 4/6] vlan: Optimize multiple unregistration
From: Patrick McHardy @ 2009-10-29 14:33 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, Linux Netdev List
In-Reply-To: <4AE9A6F6.5040209@gmail.com>
Eric Dumazet wrote:
> Patrick McHardy a écrit :
>> How about this? I moved the code back into vlan_device_event() since
>> its now only a very minimal change to the original code.
>>
>> vlan-orig.diff contains the diff between the original code and the
>> code after this patch for reference.
>>
>>
>
> I have no problem with this solution, but I wonder why you re-added the curious
>
> /* unregistration of last vlan destroys group, abort
> * afterwards */
> if (grp->nr_vlans == 1)
> i = VLAN_GROUP_ARRAY_LEN;
>
> unregister_vlan_dev(vlandev, &list);
>
> while doing
>
> unregister_vlan_dev(vlandev, &list);
> if (grp->nr_vlans == 0)
> break;
>
> seems more natural :)
Indeed, but unregister_vlan_dev() destroys the group once the
count has reached zero, so we must not access it after that.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Bartlomiej Zolnierkiewicz @ 2009-10-29 14:34 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <20091029.072001.153801635.davem@davemloft.net>
On Thursday 29 October 2009 15:20:01 David Miller wrote:
> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Date: Thu, 29 Oct 2009 15:13:54 +0100
>
> > John has chosen to ignore my concerns and you are sending me back to him?
>
> That's exactly why I won't overreach his maintainership role,
> because you're inability to interact with and work with the
> wireless maintainer isn't my problem.
>
> In case you're concerned, I actually agree with John and others
> on this issue, and disagree with your position.
>
> So even if I felt it legitimate to overreach John, I still wouldn't
> make the change you are requesting in this case.
Sorry but you are also wrong then and you are just in the way of progress.
> Does it really eat you so hard when someone disagrees with you?
>
> That's not going to work in the long term Bart, if John disagrees with
> you he's the maintainer of wireless and that's it. You're going to
> have to learn to work with people, and not just automatically go to a
> "higher power" as soon as someone disagrees with you.
I'm not going to waste my time on stupid or hopeless things just because you
or John like to call themselves "maintainers".
If Red Hat or some other company wants to hire me and pay me for spinning
inside networking bureaucracy than please contact me in private but as
long as it is my own time I'll just do what I think makes sense on technical
merits and not on who is the "maintainer" of this or that..
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Michael Buesch @ 2009-10-29 14:39 UTC (permalink / raw)
To: David Miller
Cc: bzolnier-Re5JQEeQqe8AvxtiuMwx3w, penberg-bbCR+/B0CizivPeTLB3BmA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linville-2XuSBdqkA4R54TAoqtyWWQ
In-Reply-To: <20091029.072101.109209962.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Thursday 29 October 2009 15:21:01 David Miller wrote:
> The issue is that John disagrees with you can you can't handle
> that.
>
> So instead of continuing to discuss things with him and the
> other wireless folks, you want me to just overreach everybody
> and revert someone else's work.
In the end this results in the driver maintainer being forced to maintain
code and handle bugreports for code that he disagrees with in the first place.
This is unacceptable and has to be resolved in some way.
If it's not possible to get it reverted through John (for whatever reason),
you're in charge to help the actual code maintainer out.
> I'm not going to do that sorry, learn how to work with the
> wireless people instead.
This is not the problem.
The problem is that stuff is merged without ack from the maintainer
and it's virtually impossible to get the stuff reverted. The only real
way for the maintainer to resolve this is 1) live with it or 2) fix it.
And that's bad, because it completely invalidates his priority queue.
Just like you must not bypass John, the driver maintainers must not be bypassed, too.
The quality control does _only_ work if nobody in the chain is bypassed.
But in this situation the quality control did already fail and it should be
tried hard to resolve (=revert) the situation instead of pointing at John.
--
Greetings, Michael.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: SRIOV driver for 82599
From: Jeff Kirsher @ 2009-10-29 14:40 UTC (permalink / raw)
To: Satish Chowdhury; +Cc: netdev
In-Reply-To: <be5d34890910090003s4c518c44q3ae395d0efbeb225@mail.gmail.com>
On Fri, Oct 9, 2009 at 00:03, Satish Chowdhury
<satish.chowdhury@oneconvergence.com> wrote:
> Hi,
>
> I want to test the SRIOV functionality of Intel 82599 based NIC card.
> Is there a version of ixgbe driver with SRIOV functionality support
> and is there a ixgbe VF driver?
>
> Thanks
> -Satish
> --
Not currently. We are currently working on the patches to add SRIOV support.
--
Cheers,
Jeff
^ permalink raw reply
* Re: [PATCH 4/6] vlan: Optimize multiple unregistration
From: Eric Dumazet @ 2009-10-29 14:43 UTC (permalink / raw)
To: Patrick McHardy; +Cc: David S. Miller, Linux Netdev List
In-Reply-To: <4AE9A7AA.70107@trash.net>
Patrick McHardy a écrit :
> Indeed, but unregister_vlan_dev() destroys the group once the
> count has reached zero, so we must not access it after that.
Well, I hoped call_rcu() callback doesnt fire and kfree(grp) until we exited
from unregister_vlan_dev_alls(), with RTNL locked...
^ permalink raw reply
* Shared i2c adapter locking (Was: linux-next: manual merge of the net tree with the i2c tree)
From: Jean Delvare @ 2009-10-29 14:43 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, netdev, linux-next, linux-kernel, Mika Kuoppala,
Ben Hutchings, Linux I2C
In-Reply-To: <20091026133757.7cf87e49.sfr@canb.auug.org.au>
Hi Stephen,
On Mon, 26 Oct 2009 13:37:57 +1100, Stephen Rothwell wrote:
> Today's linux-next merge of the net tree got a conflict in
> drivers/net/sfc/sfe4001.c between commit
> 3f7c0648f727a6d5baf6117653e4001dc877b90b ("i2c: Prevent priority
> inversion on top of bus lock") from the i2c tree and commit
> c9597d4f89565b6562bd3026adbe6eac6c317f47 ("sfc: Merge sfe4001.c into
> falcon_boards.c") from the net tree.
>
> I have applied the following merge fixup patch (after removing
> drivers/net/sfc/sfe4001.c) and can carry it as necessary.
Thanks for fixing it. The core problem here IMHO is that the sfc
network driver touches i2c internals which it would rather leave alone.
This is the only driver I know of which does this.
I can think of 3 different ways to address the issue.
Method #1: add a public API to grab/release an I2C segment.
void i2c_adapter_lock(struct i2c_adapter *adapter)
{
rt_mutex_lock(&adapter->bus_lock);
}
void i2c_adapter_unlock(struct i2c_adapter *adapter)
{
rt_mutex_unlock(&adapter->bus_lock);
}
It has the advantage of simplicity. The problem is that it is not
symmetric. Whatever shares the pins with I2C, I2C is considered the
main user in that its mutex is used to guarantee mutual exclusion. If
the other subsystem also has a mandatory locking mechanism, there will
have to be a decision on who is locked first. If not all drivers agree,
lockdep will get confused.
Method #2: let the driver implement its own "main" locking, and have
all pin users (i2c etc.) take it in addition to any subsystem-specific
mutex. As far as the sfc network driver is concerned, that would mean
adding pre-xfer and post-xfer hooks to i2c-algo-bit, where the "main"
mutex in question would be taken resp. released.
It has the advantage of symmetry. The problem is performance, as
regular operation will require to take and release two mutexes instead
of just one. But it is a fairly generic approach which could solve
other issues too.
Method #3: let individual bus drivers implement segment locking
themselves, with custom locking/unlocking hooks. This way, a device
sharing pins between several functions can have its own mutex
protecting these pins globally, and all user subsystems (i2c etc.) use
this single mutex.
It has the advantage of performance and symmetry, at the price of
fragility. If the i2c bus driver implements locking improperly... I am
also worried by inconsistencies that may arise, if different i2c
adapters are protected by different mutex types (mutex vs. real-time
mutex vs. spinlock etc.) but maybe this will be seen as an advantage
rather than a problem.
I'm not really sure if I have a preference yet, so please speak up if
you do.
--
Jean Delvare
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Gertjan van Wingerde @ 2009-10-29 14:44 UTC (permalink / raw)
To: Michael Buesch
Cc: David Miller, bzolnier, penberg, linux-wireless, netdev,
linux-kernel, linville
In-Reply-To: <200910291539.16476.mb@bu3sch.de>
On Thu, Oct 29, 2009 at 3:39 PM, Michael Buesch <mb@bu3sch.de> wrote:
> On Thursday 29 October 2009 15:21:01 David Miller wrote:
>> The issue is that John disagrees with you can you can't handle
>> that.
>>
>> So instead of continuing to discuss things with him and the
>> other wireless folks, you want me to just overreach everybody
>> and revert someone else's work.
>
> In the end this results in the driver maintainer being forced to maintain
> code and handle bugreports for code that he disagrees with in the first place.
> This is unacceptable and has to be resolved in some way.
> If it's not possible to get it reverted through John (for whatever reason),
> you're in charge to help the actual code maintainer out.
>
>> I'm not going to do that sorry, learn how to work with the
>> wireless people instead.
>
> This is not the problem.
> The problem is that stuff is merged without ack from the maintainer
> and it's virtually impossible to get the stuff reverted. The only real
> way for the maintainer to resolve this is 1) live with it or 2) fix it.
> And that's bad, because it completely invalidates his priority queue.
>
> Just like you must not bypass John, the driver maintainers must not be bypassed, too.
> The quality control does _only_ work if nobody in the chain is bypassed.
> But in this situation the quality control did already fail and it should be
> tried hard to resolve (=revert) the situation instead of pointing at John.
>
Hold on here. In this case it is the driver maintainer (i.e. Ivo for
the rt2x00 project) that
submitted this driver for inclusion, so the driver maintainer has not
been bypassed in
this case.
Apparently Bart has issues with the code submitted by the maintainers
and has been
unsuccessful in convincing others about these issues.
---
Gertjan.
^ permalink raw reply
* Re: WAN device configuration, again...
From: Krzysztof Halasa @ 2009-10-29 14:48 UTC (permalink / raw)
To: Dan Williams; +Cc: netdev
In-Reply-To: <1256745788.3850.31.camel@localhost.localdomain>
Dan Williams <dcbw@redhat.com> writes:
>> I think of something:
>> - using netlink or similar interface
>
> If you're doing a new config interface, I'd suggest netlink like the
> wireless guys did to replace WEXT with cfg80211. Using netlink makes
> your interface easily available from programs/libraries without having
> to screenscrape anything. If you want some advice on netlink API stuff,
> ask Johannes Berg.
Thanks for your mail. It seems I'll do it this way.
--
Krzysztof Halasa
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Michael Buesch @ 2009-10-29 14:48 UTC (permalink / raw)
To: Gertjan van Wingerde
Cc: David Miller, bzolnier-Re5JQEeQqe8AvxtiuMwx3w,
penberg-bbCR+/B0CizivPeTLB3BmA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linville-2XuSBdqkA4R54TAoqtyWWQ
In-Reply-To: <14add3d10910290744n3abd1cf8w42a6311108eb2fa7-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thursday 29 October 2009 15:44:42 Gertjan van Wingerde wrote:
> Hold on here. In this case it is the driver maintainer (i.e. Ivo for
> the rt2x00 project) that
> submitted this driver for inclusion, so the driver maintainer has not
> been bypassed in
> this case.
>
> Apparently Bart has issues with the code submitted by the maintainers
> and has been
> unsuccessful in convincing others about these issues.
So Bart is not a maintainer? That of course changes the situation.
--
Greetings, Michael.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC] net,socket: introduce build_sockaddr_check helper to catch overflow at build time
From: Cyrill Gorcunov @ 2009-10-29 14:50 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20091029.030019.44832583.davem@davemloft.net>
[David Miller - Thu, Oct 29, 2009 at 03:00:19AM -0700]
...
| > Eventually inet_getname is switched to use DECLARE_SOCKADDR
| > (to show example of usage).
| >
| > Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
|
| I like this, applied to net-next-2.6, thanks!
|
Thanks David. I'll handle other protocols in a couple
of days.
-- Cyrill
^ permalink raw reply
* [patch]convert kaweth to use usb_reset_configuration()
From: Oliver Neukum @ 2009-10-29 15:07 UTC (permalink / raw)
To: Sarah Sharp, davem, netdev
For USB 3.0 it is necessary that all drivers use the standard
API to reset a configuration. This removes a home-grown
implementation.
Signed-off-by: Oliver Neukum <oliver@neukum.org>
Hi David,
please take this for the next merge window.
Regards
Oliver
--
--- a/drivers/net/usb/kaweth.c
+++ b/drivers/net/usb/kaweth.c
@@ -471,16 +471,7 @@ static int kaweth_reset(struct kaweth_device *kaweth)
int result;
dbg("kaweth_reset(%p)", kaweth);
- result = kaweth_control(kaweth,
- usb_sndctrlpipe(kaweth->dev, 0),
- USB_REQ_SET_CONFIGURATION,
- 0,
- kaweth->dev->config[0].desc.bConfigurationValue,
- 0,
- NULL,
- 0,
- KAWETH_CONTROL_TIMEOUT);
-
+ result = usb_reset_configuration(kaweth->dev);
mdelay(10);
dbg("kaweth_reset() returns %d.",result);
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Luis R. Rodriguez @ 2009-10-29 15:08 UTC (permalink / raw)
To: Michael Buesch
Cc: Gertjan van Wingerde, David Miller,
bzolnier-Re5JQEeQqe8AvxtiuMwx3w, penberg-bbCR+/B0CizivPeTLB3BmA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linville-2XuSBdqkA4R54TAoqtyWWQ
In-Reply-To: <200910291548.27235.mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org>
On Thu, Oct 29, 2009 at 7:48 AM, Michael Buesch <mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org> wrote:
> On Thursday 29 October 2009 15:44:42 Gertjan van Wingerde wrote:
>> Hold on here. In this case it is the driver maintainer (i.e. Ivo for
>> the rt2x00 project) that
>> submitted this driver for inclusion, so the driver maintainer has not
>> been bypassed in
>> this case.
>>
>> Apparently Bart has issues with the code submitted by the maintainers
>> and has been
>> unsuccessful in convincing others about these issues.
>
> So Bart is not a maintainer? That of course changes the situation.
But you were :-P
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Shared i2c adapter locking (Was: linux-next: manual merge of the net tree with the i2c tree)
From: Ben Hutchings @ 2009-10-29 15:09 UTC (permalink / raw)
To: Jean Delvare
Cc: Stephen Rothwell, David Miller, netdev, linux-next, linux-kernel,
Mika Kuoppala, Linux I2C
In-Reply-To: <20091029154317.651904b9@hyperion.delvare>
On Thu, 2009-10-29 at 15:43 +0100, Jean Delvare wrote:
> Hi Stephen,
>
> On Mon, 26 Oct 2009 13:37:57 +1100, Stephen Rothwell wrote:
> > Today's linux-next merge of the net tree got a conflict in
> > drivers/net/sfc/sfe4001.c between commit
> > 3f7c0648f727a6d5baf6117653e4001dc877b90b ("i2c: Prevent priority
> > inversion on top of bus lock") from the i2c tree and commit
> > c9597d4f89565b6562bd3026adbe6eac6c317f47 ("sfc: Merge sfe4001.c into
> > falcon_boards.c") from the net tree.
> >
> > I have applied the following merge fixup patch (after removing
> > drivers/net/sfc/sfe4001.c) and can carry it as necessary.
>
> Thanks for fixing it. The core problem here IMHO is that the sfc
> network driver touches i2c internals which it would rather leave alone.
I'm just a little proud of having the idea that we could avoid using an
I/O-expander on this board, but yes, the software side of this
multiplexing is a hack.
> This is the only driver I know of which does this.
>
> I can think of 3 different ways to address the issue.
>
> Method #1: add a public API to grab/release an I2C segment.
>
> void i2c_adapter_lock(struct i2c_adapter *adapter)
> {
> rt_mutex_lock(&adapter->bus_lock);
> }
>
> void i2c_adapter_unlock(struct i2c_adapter *adapter)
> {
> rt_mutex_unlock(&adapter->bus_lock);
> }
[...]
> I'm not really sure if I have a preference yet, so please speak up if
> you do.
Indirect lock operations are a recipe for deadlock, and there doesn't
seem to be any other user for this, so method 1 seems best.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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: [PATCH 2/3] net: TCP thin linear timeouts
From: apetlund @ 2009-10-29 15:14 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Andreas Petlund, Netdev, LKML, shemminger, David Miller
I apologise that some of you received this mail more than once. My email
client played a HTML-trick on me.
>> + icsk->icsk_backoff = 0;
>> + icsk->icsk_rto = min(((tp->srtt >> 3) + tp->rttvar), TCP_RTO_MAX);
>
> The first part is nowadays done with __tcp_set_rto(tp).
>
> --
> i.
>
I will address this in the next iteration of the patch.
-AP
^ permalink raw reply
* Re: [PATCH 2/3] net: TCP thin linear timeouts
From: apetlund @ 2009-10-29 15:19 UTC (permalink / raw)
To: Arnd Hannemann
Cc: Eric Dumazet, Andreas Petlund, netdev, linux-kernel, shemminger,
ilpo.jarvinen, davem
I apologise that some of you received this mail more than once. My email
client played a HTML-trick on me.
> Eric Dumazet schrieb:
>> Andreas Petlund a écrit :
>>> This patch will make TCP use only linear timeouts if the stream is
thin. This will help to avoid the very high latencies that thin stream
suffer because of exponential backoff. This mechanism is only active
if
>>> enabled by iocontrol or syscontrol and the stream is identified as thin.
>> Wont this reduce the session timeout to something very small, ie 15
retransmits, way under the minute ?
>
> The session timeout no longer depends on the actual number of
retransmits.
> Instead its a time interval,
> which is roughly equivalent to the time a TCP, performing exponential
backoff would need to perform
> 15 retransmits.
>
> However, addressing the proposal:
> I wonder how one can seriously suggest to just skip congestion response
during timeout-based
> loss recovery? I believe that in a heavily congested scenarios, this
would
> lead to a goodput
> goodput disaster... Not to mention that in a heavily congested scenario,
suddenly every flow
> will become "thin", so this will even amplify the problems. Or did I
miss
> something?
We have found no noticeable degradation of the goodput in a series of
experiments we have performed in order to map the effects of the
modifications. Furthermore, the modifications implemented in the patches
are explicitly enabled only for applications where the developer knows
that streams will be thin, thus only a small subset of the streams will
apply the modifications.
Graphs presenting results from experiments performed to analyse latency
and fairness issues can be found here:
http://folk.uio.no/apetlund/lktmp/
-AP
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/4] net: introduce mc list helpers
From: Jiri Pirko @ 2009-10-29 15:19 UTC (permalink / raw)
To: Ben Hutchings
Cc: eric.dumazet, e1000-devel, netdev, bruce.w.allan,
jesse.brandeburg, mchehab, john.ronciak, jeffrey.t.kirsher, davem,
linux-media
In-Reply-To: <1256221112.2785.13.camel@achroite>
Thu, Oct 22, 2009 at 04:18:32PM CEST, bhutchings@solarflare.com wrote:
>On Thu, 2009-10-22 at 15:52 +0200, Jiri Pirko wrote:
>> This helpers should be used by network drivers to access to netdev
>> multicast lists.
>[...]
>> +static inline void netdev_mc_walk(struct net_device *dev,
>> + void (*func)(void *, unsigned char *),
>> + void *data)
>> +{
>> + struct dev_addr_list *mclist;
>> + int i;
>> +
>> + for (i = 0, mclist = dev->mc_list; mclist && i < dev->mc_count;
>> + i++, mclist = mclist->next)
>> + func(data, mclist->dmi_addr);
>> +}
>[...]
>
>We usually implement iteration as macros so that any context doesn't
>have to be squeezed through a single untyped (void *) variable. A macro
>for this would look something like:
>
>#define netdev_for_each_mc_addr(dev, addr) \
> for (addr = (dev)->mc_list ? (dev)->mc_list->dmi_addr : NULL; \
> addr; \
> addr = (container_of(addr, struct dev_addr_list, dmi_addr)->next ? \
> container_of(addr, struct dev_addr_list, dmi_addr)->next->dmi_addr : \
> NULL))
>
>Once you change the list type this can presumably be made less ugly.
Looking at this, I'm not sure how to deal with this macro once we need to
convert it to work with list_head. I see two options:
1) traverse through the list by hand in this macro (ugly)
2) introduce something like "list_for_each_struct_entry" which takes pointer of
the structure member as a cursor. Then netdev_for_each_mc_addr would be just
wrap-up of this.
What do you think?
Thanks
Jirka
>
>Ben.
>
>--
>Ben Hutchings, Senior Software Engineer, Solarflare Communications
>Not speaking for my employer; that's the marketing department's job.
>They asked us to note that Solarflare product names are trademarked.
>
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
^ permalink raw reply
* Re: [PATCH 3/3] net: TCP thin dupack
From: apetlund @ 2009-10-29 15:23 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Andreas Petlund, Netdev, LKML, shemminger, David Miller
I apologise that some of you received this mail more than once. My email
client played a HTML-trick on me.
>> + /* If a thin stream is detected, retransmit after first
>> + * received dupack */
>> + if ((tp->thin_dupack || sysctl_tcp_force_thin_dupack) &&
>> + tcp_dupack_heurestics(tp) > 1 && tcp_stream_is_thin(tp))
>> + return 1;
>> +
>> return 0;
>> }
>
> Have you tested it? ...I doubt this will work like you say and
retransmit
> something when the window is small. ...Besides, you should have built
this
> patch on top of the function rename you submitted earlier as after DaveM
applied that this will no longer even compile...
>
> --
> i.
>
We have performed extensive tests mapping the effect of the patch you
commented on some months ago. Since then, the only change was the one you
requested of switching tcp_fackets_out() with tcp_dupack_heurestics().
After inspecting the code, I believed the effect should be equal to the
previous, only making considerations for SACK and FACK availability.
Please tell if this will break the intended effect, and I will modify the
patch accordingly.
Graphs from our tests of the original patch can be found at the location
linked to below. I have tested the new one for functionality, but have
not et performed tests on this scope as the changes were minor. I will, of
course, fix the function rename in the next iteration. Sorry for that.
http://folk.uio.no/apetlund/lktmp/
-AP
^ permalink raw reply
* Connection tracking and vlan
From: Adayadil Thomas @ 2009-10-29 15:43 UTC (permalink / raw)
To: netdev
Greetings!
If two connections have same 5 tuple, src ip, dst ip, src port, dst
port, protocol(tcp/udp)
but on different vlans (different vlan id), does the conntrack separate these ?
I am using kernel version 2.6.20; the conntrack tuple structure do not
seem to have vlan information.
Any information is much appreciated.
Thanks
^ permalink raw reply
* Re: [PATCH 2/3] net: TCP thin linear timeouts
From: apetlund @ 2009-10-29 15:43 UTC (permalink / raw)
To: Eric Dumazet
Cc: Andreas Petlund, Ilpo Järvinen, Arnd Hannemann, Netdev, LKML,
shemminger, David Miller
> Andreas Petlund a écrit :
>
>> The removal of exponential backoff on a general basis has been
>> investigated and discussed already, for instance here:
>> http://ccr.sigcomm.org/online/?q=node/416
>> Such steps are, however considered drastic, and I agree that caution
must be made to thoroughly investigate the effects of such changes. The
changes introduced by the proposed patches, however, are not
default
>> behaviour, but an option for applications that suffer from the
>> thin-stream TCP increased retransmission latencies. They will, as such,
not affect all streams. In addition, the changes will only be active
for
>> streams which are perpetually thin or in the early phase of expanding
their cwnd. Also, experiments performed on congested bottlenecks with
tail-drop queues show very little (if any at all) effect on goodput for
the modified scenario compared to a scenario with unmodified TCP
streams.
>> Graphs both for latency-results and fairness tests can be found here:
http://folk.uio.no/apetlund/lktmp/
>
> There should be a limit to linear timeouts, to say ... no more than 6
retransmits
> (eventually tunable), then switch to exponential backoff. Maybe your
patch
> already implement such heuristic ?
>
The limitation you suggest to the linear timeouts makes very good sense.
Our experiments performed on the Internet indicate that it is extremely
rare that more than 6 retransmissions are needed to recover. It is not
included in the current patch, so I will include this in the next
iteration.
> True link collapses do happen, it would be good if not all streams
wakeup
> in the same
> second and make recovery very slow.
>
Each stream will have its own schedule for wakeup, so such events will
still be subject to coincidence. The timer granularity of the TCP wakeup
timer will also influence how many streams will wake at the same time. The
experiments we have performed on severely congested bottlenecks (link
above) indicate that the modifications will not create a large negative
effect. In fact, when goodput is drastically reduced due to severe
overload, regular TCP and the LT and dupACK modifications seem to perform
nearly identically. Other scenarios may exist where different effects can
be observed, and I am open to suggestions for further testing.
> Thats too easy to accept possibly dangerous features with the excuse of
saying
> "It wont be used very much", because you cannot predict the future.
I agree that it is no argument to say that it won't be used much; indeed,
my hope is that it will be used much. However, our experiments indicate no
negative effects while showing a large improvement on retransmission
latency for the scenario in question. I therefore think that the option
for such an improvement should be made available for time-dependent
thin-stream applications.
-AP
^ permalink raw reply
* Re: [PATCH 2/3] net: TCP thin linear timeouts
From: Eric Dumazet @ 2009-10-29 15:50 UTC (permalink / raw)
To: apetlund
Cc: Ilpo Järvinen, Arnd Hannemann, Netdev, LKML, shemminger,
David Miller
In-Reply-To: <69812160e5682c9fb4acba05bc082664.squirrel@webmail.uio.no>
apetlund@simula.no a écrit :
>> Andreas Petlund a écrit :
>> There should be a limit to linear timeouts, to say ... no more than 6
> retransmits
>> (eventually tunable), then switch to exponential backoff. Maybe your
> patch
>> already implement such heuristic ?
>>
>
> The limitation you suggest to the linear timeouts makes very good sense.
> Our experiments performed on the Internet indicate that it is extremely
> rare that more than 6 retransmissions are needed to recover. It is not
> included in the current patch, so I will include this in the next
> iteration.
>
>> True link collapses do happen, it would be good if not all streams
> wakeup
>> in the same
>> second and make recovery very slow.
>>
>
> Each stream will have its own schedule for wakeup, so such events will
> still be subject to coincidence. The timer granularity of the TCP wakeup
> timer will also influence how many streams will wake at the same time. The
> experiments we have performed on severely congested bottlenecks (link
> above) indicate that the modifications will not create a large negative
> effect. In fact, when goodput is drastically reduced due to severe
> overload, regular TCP and the LT and dupACK modifications seem to perform
> nearly identically. Other scenarios may exist where different effects can
> be observed, and I am open to suggestions for further testing.
>
>> Thats too easy to accept possibly dangerous features with the excuse of
> saying
>> "It wont be used very much", because you cannot predict the future.
>
> I agree that it is no argument to say that it won't be used much; indeed,
> my hope is that it will be used much. However, our experiments indicate no
> negative effects while showing a large improvement on retransmission
> latency for the scenario in question. I therefore think that the option
> for such an improvement should be made available for time-dependent
> thin-stream applications.
>
Thanks ! I must say I am very interested by these experiments, I am looking
forward your next iteration.
^ permalink raw reply
* Re: [PATCH 2/3] net: TCP thin linear timeouts
From: Arnd Hannemann @ 2009-10-29 16:11 UTC (permalink / raw)
To: Andreas Petlund
Cc: Eric Dumazet, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, shemminger@vyatta.com,
ilpo.jarvinen@helsinki.fi, davem@davemloft.net
In-Reply-To: <07CD1135-C68B-4264-8CD3-C4BC0400FDA2@simula.no>
Andreas Petlund schrieb:
> We have found no noticeable degradation of the goodput in a series of
> experiments we have performed in order to map the effects of the
> modifications. Furthermore, the modifications implemented in the patches
> are explicitly enabled only for applications where the developer knows
> that streams will be thin, thus only a small subset of the streams will
> apply the modifications.
>
> Graphs presenting results from experiments performed to analyse latency
> and fairness issues can be found here:
> http://folk.uio.no/apetlund/lktmp/
How often did you hit consecutive RTOs in these measurements?
As I see you did a measurement with 512 thick vs. 512 thin streams.
Lets do a hypothetical calculation with only 512 "thin" streams.
Lets further assume the rtt is low, so that RTO is around 200ms.
Assume each segment has 128 Bytes (already very small...).
Assume after a period of normal operation all streams are in
timeout-based loss recovery. (e.g. because destination endpoint
suddenly behaves like a black hole)
As all streams are in timeout-based loss recovery, each stream
will transmit 5 segments each second with your modification.
This would result in a throughput around 512*5*1024bit = 2560 kbit/s
and a goodput of 0 kbit/s (because the receiver is a black hole).
So you can easily saturate a 2 MBit/s link, only with retransmissions.
Unfortunately in Germany an ADSL uplink of 786 kbit/s is still quite
common, and its already called "broadband"...
Regarding the "small subset", why have a global sysctl option, then?
And I think "tcp_stream_is_thin(tp)" will be true for every flow
in the RTO case, at least for consecutive RTOs.
Best regards,
Arnd Hannemann
^ permalink raw reply
* Re: [PATCH 1/3] net: TCP thin-stream detection
From: Arnd Hannemann @ 2009-10-29 16:32 UTC (permalink / raw)
To: Andreas Petlund
Cc: William Allen Simpson, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, shemminger@vyatta.com,
ilpo.jarvinen@helsinki.fi, davem@davemloft.net
In-Reply-To: <38EB8C31-A96A-4C5C-88D8-8F6BF0E9225F@simula.no>
Andreas Petlund schrieb:
> Den 28. okt. 2009 kl. 04.09 skrev William Allen Simpson:
>
>> Andreas Petlund wrote:
>>> +/* Determines whether this is a thin stream (which may suffer from
>>> + * increased latency). Used to trigger latency-reducing mechanisms.
>>> + */
>>> +static inline unsigned int tcp_stream_is_thin(const struct
>>> tcp_sock *tp)
>>> +{
>>> + return tp->packets_out < 4;
>>> +}
>>> +
>> This bothers me a bit. Having just looked at your Linux presentation,
>> and not (yet) read your papers, it seems much of your justification
>> was
>> with 1 packet per RTT. Here, you seem to be concentrating on 4,
>> probably
>> because many implementations quickly ramp up to 4.
>>
>
> The limit of 4 packets in flight is based on the fact that less than 4
> packets in flight makes fast retransmissions impossible, thus limiting
> the retransmit options to timeout-retransmissions. The criterion is
There is Limited Transmit! So this is generally not true.
> therefore as conservative as possible while still serving its purpose.
> If further losses occur, the exponential backoff will increase latency
> further. The concept of using this limit is also discussed in the
> Internet draft for Early Retransmit by Allman et al.:
> http://www.icir.org/mallman/papers/draft-ietf-tcpm-early-rexmt-01.txt
This ID is covering exactly the cases which Limited Transmit does not
cover and works "automagically" without help of application. So why not
just implement this ID?
Best regards,
Arnd
^ permalink raw reply
* Re: [RFC] multiqueue changes
From: Patrick McHardy @ 2009-10-29 16:37 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Eric Dumazet, David S. Miller, Linux Netdev List
In-Reply-To: <20091028212337.GA3218@ami.dom.local>
Jarek Poplawski wrote:
> On Wed, Oct 28, 2009 at 06:27:10PM +0100, Patrick McHardy wrote:
>> We don't seem to be supporting changing real_num_tx_queues for
>> registered devices currently (at least I couldn't find it).
>> So I guess it depends on how this would be implemented.
>>
>> Simply changing the dev->real_num_tx_queues value while the
>> device is down would require qdisc operations to operate on
>> all possible queues since the amount of queues in use could
>> be changed after the qdisc is created/configured, but before
>> the device is set up. This approach has more complications
>> like switching between mq and non-mq root qdiscs, taking care
>> of non-default root qdisc (cloning them to the new queues), etc.
>>
>> A simpler alternative would be to destroy the existing root
>> qdisc on any change to real_num_tx_queues and have dev_activate()
>> set it up from scratch. In this case, we could (as you suggested)
>> use real_num_tx_queues, which should fix the problem Eric reported.
>
> Actually, I changed my mind after Eric's and especially David's
> explanations. Probably there will be needed some changes in handling
> the real_num_tx_queues, but there is no reason to misuse them for
> masking a totally useless num_tx_queues value, like in this case. So,
> IMHO, its mainly about the driver(s) (and maybe a bit of API change)
> here.
Well, we do need both values for supporting changes to the actually
used numbers of TX queues. If I understood Dave's explanation correctly,
this is also what's intended. It also doesn't seem unreasonable
what bnx2 is doing.
But getting back to the problem Eric reported - so you're suggesting
that bnx2.c should also adjust num_tx_queues in case the hardware
doesn't support multiqueue? That seems reasonable as well.
^ permalink raw reply
* [PATCH 6/6] sky2: version 1.26
From: Stephen Hemminger @ 2009-10-29 16:37 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20091029163704.793246334@vyatta.com>
[-- Attachment #1: sky2-1.26.patch --]
[-- Type: text/plain, Size: 343 bytes --]
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/drivers/net/sky2.c 2009-10-29 08:57:43.512001253 -0700
+++ b/drivers/net/sky2.c 2009-10-29 08:59:34.782375629 -0700
@@ -50,7 +50,7 @@
#include "sky2.h"
#define DRV_NAME "sky2"
-#define DRV_VERSION "1.25"
+#define DRV_VERSION "1.26"
#define PFX DRV_NAME " "
/*
--
^ permalink raw reply
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