From: Denys Vlasenko
Date: Tue, 18 Aug 2009 06:56:53 +0200
> Since DHCP and any other networking activity like TCP connects
> accomodate packet loss, things should work even without any delay
> in kernel IP config code. The delay will be just shifted to the
> moment when first DHCP/TCP/whatever n
From: Tim Bird
Date: Mon, 17 Aug 2009 18:40:48 -0700
> David Miller wrote:
>> From: Tim Bird
>> Date: Mon, 17 Aug 2009 18:24:26 -0700
>>
>>> David Miller wrote:
>>>> I have card/switch combinations that take up to 10 seconds to
>>>> negot
From: Tim Bird
Date: Mon, 17 Aug 2009 18:24:26 -0700
> David Miller wrote:
>> I have card/switch combinations that take up to 10 seconds to
>> negotiate a proper link.
>
> What types of delays are these timeouts supposed to
> cover?
The problem is that if you don&#x
From: Tim Bird
Date: Mon, 17 Aug 2009 15:35:01 -0700
> Tim Bird wrote:
>> See the definitions of CONF_PRE_OPEN and CON_POST_OPEN
>> in net/ipv4/ipconfig.c
>>
>> They are set to ridiculously long values. In my experience,
>> you can cut them down considerably with no dangerous side
>> effects (b
From: Paul Mundt <[EMAIL PROTECTED]>
Date: Thu, 28 Aug 2008 09:32:13 +0900
> On Wed, Aug 27, 2008 at 08:35:44PM +0300, Adrian Bunk wrote:
> > CONFIG_DEBUG_STACKOVERFLOW should give you the same information, and if
> > wanted with an arbitrary limit.
>
> In some cases, yes. In the CONFIG_DEBUG_STAC
From: David Woodhouse <[EMAIL PROTECTED]>
Date: Thu, 31 Jul 2008 12:46:41 +0100
> I only said I'd submit them directly to Linus because I _think_ he'd
> agree with Andrew and I, and take them despite your objections. And
> because I think that's the right thing for him to do.
I guess Linus is una
From: David Woodhouse <[EMAIL PROTECTED]>
Date: Thu, 31 Jul 2008 12:29:30 +0100
> After an offline discussion, I understand that if we can sort out the
> actual technical issues, you'll carry this in the net tree. Thanks.
I will, but only because you threatened to bypass me and send them
directly
From: David Woodhouse <[EMAIL PROTECTED]>
Date: Thu, 31 Jul 2008 11:54:24 +0100
> Other potential approaches include not enabling LRO by default if
> !CONFIG_ETHTOOL. Or having the driver(s) which _do_ enable LRO by
> default 'select ETHTOOL'.
It is possible for us to generically enable LRO for
From: David Woodhouse <[EMAIL PROTECTED]>
Date: Thu, 31 Jul 2008 11:42:47 +0100
> It's alleged that these functions are called from 'core' network code in
> some places, although I can't actually see any evidence of that anywhere
> in Linus' tree except for vlans and bridging.
>
> If that's actua
From: Ben Hutchings <[EMAIL PROTECTED]>
Date: Thu, 31 Jul 2008 11:40:05 +0100
> You also need to conditionalise dev_disable_lro().
That can only be done once the CONFIG_ETHTOOL select statement
is added for CONFIG_INET.
Which basically makes this CONFIG_ETHTOOL thing completely pointless.
--
To
From: David Woodhouse <[EMAIL PROTECTED]>
Date: Thu, 31 Jul 2008 11:15:16 +0100
> While I agree with Andrew's observation, I'd also respectfully submit
> that your argument is more fundamentally bogus than that. TCP and UDP
> are _not_ universally available. They go away if you set CONFIG_INET=n.
From: David Woodhouse <[EMAIL PROTECTED]>
Date: Thu, 31 Jul 2008 10:59:15 +0100
> I have drivers which don't even _have_ ethtool support, and they seem to
> work fine. But leaving aside the debate on that point, your statement
> also seemed to be covering the other patches, such as the IGMP one an
From: David Woodhouse <[EMAIL PROTECTED]>
Date: Thu, 31 Jul 2008 10:51:52 +0100
> But there are a lot of people who really don't need these features
> and really want the option of leaving them out.
I'll say it one last time.
If you have ipv4 enabled, you need ETHTOOL.
--
To unsubscribe from thi
From: Thomas Petazzoni <[EMAIL PROTECTED]>
Date: Thu, 31 Jul 2008 11:27:03 +0200
> Changes since previous post:
>
> * Add Matt Mackall's Signed-off-by on all patches
> * Make bonding and bridging select ethtool in the ethtool-related
>patch.
The ethtool config option needs to be selected b
14 matches
Mail list logo
