* Re: [RFC net-next 01/14] Add Default
From: Alexander Duyck @ 2012-06-19 16:37 UTC (permalink / raw)
To: Yuval Mintz; +Cc: netdev, davem, eilong
In-Reply-To: <1340118848-30978-2-git-send-email-yuvalmin@broadcom.com>
On 06/19/2012 08:13 AM, Yuval Mintz wrote:
> Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
> ---
> include/linux/etherdevice.h | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
> index 3d406e0..bb1ecaf 100644
> --- a/include/linux/etherdevice.h
> +++ b/include/linux/etherdevice.h
> @@ -44,7 +44,10 @@ extern int eth_mac_addr(struct net_device *dev, void *p);
> extern int eth_change_mtu(struct net_device *dev, int new_mtu);
> extern int eth_validate_addr(struct net_device *dev);
>
> -
> +/* The maximal number of RSS queues a driver should have unless configured
> + * so explicitly.
> + */
> +#define DEFAULT_MAX_NUM_RSS_QUEUES (8)
>
> extern struct net_device *alloc_etherdev_mqs(int sizeof_priv, unsigned int txqs,
> unsigned int rxqs);
I'm not a big fan of just having this as a fixed define in the code. It
seems like it would make much more sense to have this in the Kconfig
somewhere as a range value if you plan on making this changeable in the
future.
Thanks,
Alex
^ permalink raw reply
* Re: [RFC] micrel KSZ8041 disable auto negotiation with fiber
From: Ben Hutchings @ 2012-06-19 17:08 UTC (permalink / raw)
To: Aníbal Almeida Pinto; +Cc: netdev
In-Reply-To: <4FE090A7.801@efacec.com>
On Tue, 2012-06-19 at 15:45 +0100, Aníbal Almeida Pinto wrote:
> Hi,
>
> I am working on a custom board based on a OMAP L138 with a KSZ8041TL-FTL
> phy that have fibber and copper support.
>
> When using with fibber the board can't connect to a switch, only after
> exec :
>
> ethtool -s eth1 speed 100 duplex full autoneg off
>
> the phy get link and start working.
>
> On some switches it appears that autoneg don't work well with fibber,
> ethtool reports that its at 10MB/s after exec
>
> ethtool -s eth1 autoneg on
I'm not aware of any specification for autoneg over fibre, so I imagine
the PHY is being programmed with an invalid configuration and sending
weird signals.
> The auto negotiation bit on phy register is disable on start when using
> the fibber but Linux don't appear to look at it.
>
> Found a thread [1] that solve the problem but don't appear to be fully
> accepted.
>
> The problem is modifying the phy code without interfere with ethtool use.
>
> Any official/accepted solution to this problem ?
The net driver or PHY driver needs to disable autoneg by default when
connected to fibre, and reject attempts to turn it on.
As for *how* the driver is supposed to know whether that's the case, I
have no idea...
> [1] - http://marc.info/?l=linuxppc-embedded&m=131107263711714
...which seems to be where the previous discussion ended.
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: [RFC net-next 01/14] Add Default
From: Eilon Greenstein @ 2012-06-19 17:41 UTC (permalink / raw)
To: Alexander Duyck; +Cc: Yuval Mintz, netdev, davem
In-Reply-To: <4FE0AABE.4070100@intel.com>
On Tue, 2012-06-19 at 09:37 -0700, Alexander Duyck wrote:
> On 06/19/2012 08:13 AM, Yuval Mintz wrote:
> > Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
> > Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
> > ---
> > include/linux/etherdevice.h | 5 ++++-
> > 1 files changed, 4 insertions(+), 1 deletions(-)
> >
> > diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
> > index 3d406e0..bb1ecaf 100644
> > --- a/include/linux/etherdevice.h
> > +++ b/include/linux/etherdevice.h
> > @@ -44,7 +44,10 @@ extern int eth_mac_addr(struct net_device *dev, void *p);
> > extern int eth_change_mtu(struct net_device *dev, int new_mtu);
> > extern int eth_validate_addr(struct net_device *dev);
> >
> > -
> > +/* The maximal number of RSS queues a driver should have unless configured
> > + * so explicitly.
> > + */
> > +#define DEFAULT_MAX_NUM_RSS_QUEUES (8)
> >
> > extern struct net_device *alloc_etherdev_mqs(int sizeof_priv, unsigned int txqs,
> > unsigned int rxqs);
> I'm not a big fan of just having this as a fixed define in the code. It
> seems like it would make much more sense to have this in the Kconfig
> somewhere as a range value if you plan on making this changeable in the
> future.
My original suggestion was a kernel command line parameter, but Dave was
less than enthusiastic. If you will follow the original thread, you can
probably understand why I decided to adopt Dave's constant approach
without suggesting Kconfig:
http://marc.info/?l=linux-netdev&m=133992386010982&w=2
However, 8 is not a holy number - I'm open for suggestions.
Thanks,
Eilon
^ permalink raw reply
* Re: [RFC] micrel KSZ8041 disable auto negotiation with fiber
From: Aníbal Almeida Pinto @ 2012-06-19 17:53 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev
In-Reply-To: <1340125709.2692.23.camel@bwh-desktop.uk.solarflarecom.com>
Em Ter 19 Jun 2012 18:08:29 WEST, Ben Hutchings escreveu:
> On Tue, 2012-06-19 at 15:45 +0100, Aníbal Almeida Pinto wrote:
>> Hi,
>>
>> I am working on a custom board based on a OMAP L138 with a KSZ8041TL-FTL
>> phy that have fibber and copper support.
>>
>> When using with fibber the board can't connect to a switch, only after
>> exec :
>>
>> ethtool -s eth1 speed 100 duplex full autoneg off
>>
>> the phy get link and start working.
>>
>> On some switches it appears that autoneg don't work well with fibber,
>> ethtool reports that its at 10MB/s after exec
>>
>> ethtool -s eth1 autoneg on
>
> I'm not aware of any specification for autoneg over fibre, so I imagine
> the PHY is being programmed with an invalid configuration and sending
> weird signals.
>
>> The auto negotiation bit on phy register is disable on start when using
>> the fibber but Linux don't appear to look at it.
>>
>> Found a thread [1] that solve the problem but don't appear to be fully
>> accepted.
>>
>> The problem is modifying the phy code without interfere with ethtool use.
>>
>> Any official/accepted solution to this problem ?
>
> The net driver or PHY driver needs to disable autoneg by default when
> connected to fibre, and reject attempts to turn it on.
>
> As for *how* the driver is supposed to know whether that's the case, I
> have no idea...
On this chip you have a pin where you can specify if is fibber or
copper, at power up it cleat/set the bit of auto negotiation.
The driver can save the bit state after phy power up or reset, and with
that validate if is copper or fibber.
In the case of fibber shouldn't allow change the auto negotiation.
>
>> [1] - http://marc.info/?l=linuxppc-embedded&m=131107263711714
>
> ...which seems to be where the previous discussion ended.
>
> Ben.
>
^ permalink raw reply
* Re: [RFC net-next 05/14] Fix intel/ixgbevf
From: Greg Rose @ 2012-06-19 18:07 UTC (permalink / raw)
To: eilong; +Cc: Alexander Duyck, Yuval Mintz, netdev, davem, Jeff Kirsher
In-Reply-To: <1340122013.2486.14.camel@lb-tlvb-eilong.il.broadcom.com>
On Tue, 19 Jun 2012 19:06:53 +0300
Eilon Greenstein <eilong@broadcom.com> wrote:
> On Tue, 2012-06-19 at 08:39 -0700, Alexander Duyck wrote:
> > On 06/19/2012 08:13 AM, Yuval Mintz wrote:
> > > Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
> > > Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
> > >
> > > Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > > ---
> > > drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 5 +++--
> > > 1 files changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> > > b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c index
> > > f69ec42..3ad46c2 100644 ---
> > > a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c +++
> > > b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c @@ -2014,7
> > > +2014,7 @@ err_tx_ring_allocation: static int
> > > ixgbevf_set_interrupt_capability(struct ixgbevf_adapter *adapter)
> > > { int err = 0;
> > > - int vector, v_budget;
> > > + int vector, v_budget, ncpu;
> > >
> > > /*
> > > * It's easy to be greedy for MSI-X vectors, but it
> > > really @@ -2022,8 +2022,9 @@ static int
> > > ixgbevf_set_interrupt_capability(struct ixgbevf_adapter *adapter)
> > > * than CPU's. So let's be conservative and only ask for
> > > * (roughly) twice the number of vectors as there are
> > > CPU's. */
> > > + ncpu = min_t(int, num_online_cpus(),
> > > DEFAULT_MAX_NUM_RSS_QUEUES); v_budget =
> > > min(adapter->num_rx_queues + adapter->num_tx_queues,
> > > - (int)(num_online_cpus() * 2)) +
> > > NON_Q_VECTORS;
> > > + ncpu * 2) + NON_Q_VECTORS;
> > >
> > > /* A failure in MSI-X entry allocation isn't fatal, but
> > > it does
> > > * mean we disable MSI-X capabilities of the adapter. */
> > This change is pointless on the ixgbevf driver. The VF hardware can
> > support at most 4 RSS queues. As such num_rx_queues + num_tx_queues
> > will never exceed 8 so you are essentially adding a necessary
> > min(x,8).
>
> It is pointless with the current value, but if someone will edit the
> kernel source code and replace the 8 with a 2, it will become
> meaningful. The compiler will optimize this part, and I think that for
> completion, it is best to keep this reference so a future default
> number change will not be missed.
>
> Eilon
I don't feel there is any real point to making this change to the
ixgbevf driver. 82599 virtual functions have 3 MSI-X vectors, one of
which is for the mailbox and the other two can be shared with tx/rx
queue pairs or assigned separately to tx or rx queues. So this code is
pointless no matter what value is set for DEFAULT_MAX_NUM_RSS_QUEUES.
Perhaps the patches to the other drivers in your RFC will have some
effect but this one looks like a no-op for the ixgbevf driver so there
is no reason for it.
- Greg
>
>
> --
> 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
* Re: [RFC net-next 05/14] Fix intel/ixgbevf
From: Eilon Greenstein @ 2012-06-19 18:24 UTC (permalink / raw)
To: Greg Rose; +Cc: Alexander Duyck, Yuval Mintz, netdev, davem, Jeff Kirsher
In-Reply-To: <20120619110704.000045b2@unknown>
On Tue, 2012-06-19 at 11:07 -0700, Greg Rose wrote:
> On Tue, 19 Jun 2012 19:06:53 +0300
> Eilon Greenstein <eilong@broadcom.com> wrote:
>
> > On Tue, 2012-06-19 at 08:39 -0700, Alexander Duyck wrote:
> > > On 06/19/2012 08:13 AM, Yuval Mintz wrote:
> > > > Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
> > > > Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
> > > >
> > > > Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > > > ---
> > > > drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 5 +++--
> > > > 1 files changed, 3 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> > > > b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c index
> > > > f69ec42..3ad46c2 100644 ---
> > > > a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c +++
> > > > b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c @@ -2014,7
> > > > +2014,7 @@ err_tx_ring_allocation: static int
> > > > ixgbevf_set_interrupt_capability(struct ixgbevf_adapter *adapter)
> > > > { int err = 0;
> > > > - int vector, v_budget;
> > > > + int vector, v_budget, ncpu;
> > > >
> > > > /*
> > > > * It's easy to be greedy for MSI-X vectors, but it
> > > > really @@ -2022,8 +2022,9 @@ static int
> > > > ixgbevf_set_interrupt_capability(struct ixgbevf_adapter *adapter)
> > > > * than CPU's. So let's be conservative and only ask for
> > > > * (roughly) twice the number of vectors as there are
> > > > CPU's. */
> > > > + ncpu = min_t(int, num_online_cpus(),
> > > > DEFAULT_MAX_NUM_RSS_QUEUES); v_budget =
> > > > min(adapter->num_rx_queues + adapter->num_tx_queues,
> > > > - (int)(num_online_cpus() * 2)) +
> > > > NON_Q_VECTORS;
> > > > + ncpu * 2) + NON_Q_VECTORS;
> > > >
> > > > /* A failure in MSI-X entry allocation isn't fatal, but
> > > > it does
> > > > * mean we disable MSI-X capabilities of the adapter. */
> > > This change is pointless on the ixgbevf driver. The VF hardware can
> > > support at most 4 RSS queues. As such num_rx_queues + num_tx_queues
> > > will never exceed 8 so you are essentially adding a necessary
> > > min(x,8).
> >
> > It is pointless with the current value, but if someone will edit the
> > kernel source code and replace the 8 with a 2, it will become
> > meaningful. The compiler will optimize this part, and I think that for
> > completion, it is best to keep this reference so a future default
> > number change will not be missed.
> >
> > Eilon
>
> I don't feel there is any real point to making this change to the
> ixgbevf driver. 82599 virtual functions have 3 MSI-X vectors, one of
> which is for the mailbox and the other two can be shared with tx/rx
> queue pairs or assigned separately to tx or rx queues. So this code is
> pointless no matter what value is set for DEFAULT_MAX_NUM_RSS_QUEUES.
> Perhaps the patches to the other drivers in your RFC will have some
> effect but this one looks like a no-op for the ixgbevf driver so there
> is no reason for it.
OK - I guess we can just add a comment in this location saying that
using DEFAULT_MAX_NUM_RSS_QUEUES is meaningless for the ixgbevf with
that explanation so it will not look as if it was simply over looked.
Thanks,
Eilon
^ permalink raw reply
* Re: [PATCH] ipv4: Early TCP socket demux.
From: Stephen Hemminger @ 2012-06-19 18:31 UTC (permalink / raw)
To: David Miller; +Cc: xiaosuo, stephen.hemminger, netdev
In-Reply-To: <20120618.211613.921381844240194486.davem@davemloft.net>
On Mon, 18 Jun 2012 21:16:13 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Changli Gao <xiaosuo@gmail.com>
> Date: Tue, 19 Jun 2012 12:13:48 +0800
>
> > On Tue, Jun 19, 2012 at 12:03 PM, Stephen Hemminger
> > <stephen.hemminger@vyatta.com> wrote:
> >>
> >>>
> >>> You know you want it.
> >>>
> >>> Signed-off-by: David S. Miller <davem@davemloft.net>
> >>
> >> David, I understand it, Eric understands it, and maybe one or
> >> two others. But on the principal of what is "good for the goose
> >> is good for the gander", you really need to provide a reasonable
> >> change log entry. Just because you are the network maintainer
> >> doesn't mean you get to skip all the documented rules about submitting
> >> patches.
> >
> > Agree. Thanks.
>
> That's the last time I try to be even slightly humerous on this
> list.
>
> Thanks for killing the fun Stephen.
We all need to lighten up, keep trying to be humorous.
Maybe you just need better material. The IP stack is just in too good
a shape, how about something with more natural whackiness like bluetooth.
^ permalink raw reply
* Re: [RFC] micrel KSZ8041 disable auto negotiation with fiber
From: Ben Hutchings @ 2012-06-19 18:45 UTC (permalink / raw)
To: Aníbal Almeida Pinto; +Cc: netdev
In-Reply-To: <4FE0BC99.2030101@efacec.com>
On Tue, 2012-06-19 at 18:53 +0100, Aníbal Almeida Pinto wrote:
> Em Ter 19 Jun 2012 18:08:29 WEST, Ben Hutchings escreveu:
> > On Tue, 2012-06-19 at 15:45 +0100, Aníbal Almeida Pinto wrote:
> >> Hi,
> >>
> >> I am working on a custom board based on a OMAP L138 with a KSZ8041TL-FTL
> >> phy that have fibber and copper support.
[...]
> > The net driver or PHY driver needs to disable autoneg by default when
> > connected to fibre, and reject attempts to turn it on.
> >
> > As for *how* the driver is supposed to know whether that's the case, I
> > have no idea...
>
> On this chip you have a pin where you can specify if is fibber or
> copper, at power up it cleat/set the bit of auto negotiation.
>
> The driver can save the bit state after phy power up or reset, and with
> that validate if is copper or fibber.
>
> In the case of fibber shouldn't allow change the auto negotiation.
So presumably the problem is where to put this logic?
It looks like you'll be using the davinci_emac net driver, which uses
phylib (i.e. separate PHY drivers) so you need to change ks8041_driver
and related functions in drivers/net/phy/micrel.c.
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: [RFC net-next 01/14] Add Default
From: Alexander Duyck @ 2012-06-19 19:01 UTC (permalink / raw)
To: eilong; +Cc: Yuval Mintz, netdev, davem
In-Reply-To: <1340127678.2486.18.camel@lb-tlvb-eilong.il.broadcom.com>
On 06/19/2012 10:41 AM, Eilon Greenstein wrote:
> On Tue, 2012-06-19 at 09:37 -0700, Alexander Duyck wrote:
>> On 06/19/2012 08:13 AM, Yuval Mintz wrote:
>>> Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
>>> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
>>> ---
>>> include/linux/etherdevice.h | 5 ++++-
>>> 1 files changed, 4 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
>>> index 3d406e0..bb1ecaf 100644
>>> --- a/include/linux/etherdevice.h
>>> +++ b/include/linux/etherdevice.h
>>> @@ -44,7 +44,10 @@ extern int eth_mac_addr(struct net_device *dev, void *p);
>>> extern int eth_change_mtu(struct net_device *dev, int new_mtu);
>>> extern int eth_validate_addr(struct net_device *dev);
>>>
>>> -
>>> +/* The maximal number of RSS queues a driver should have unless configured
>>> + * so explicitly.
>>> + */
>>> +#define DEFAULT_MAX_NUM_RSS_QUEUES (8)
>>>
>>> extern struct net_device *alloc_etherdev_mqs(int sizeof_priv, unsigned int txqs,
>>> unsigned int rxqs);
>> I'm not a big fan of just having this as a fixed define in the code. It
>> seems like it would make much more sense to have this in the Kconfig
>> somewhere as a range value if you plan on making this changeable in the
>> future.
> My original suggestion was a kernel command line parameter, but Dave was
> less than enthusiastic. If you will follow the original thread, you can
> probably understand why I decided to adopt Dave's constant approach
> without suggesting Kconfig:
> http://marc.info/?l=linux-netdev&m=133992386010982&w=2
There is a huge difference between a kernel parameter an a kconfig
value. The main idea behind the kconfig value is that you are going to
have different preferences depending on architectures and such so it
would make much more sense to have the default as a config option.
> However, 8 is not a holy number - I'm open for suggestions.
>
> Thanks,
> Eilon
I'm not sure why you couldn't just limit it to 16. From what I can tell
that is the largest number that gets used for RSS queues on almost all
the different hardware out there.
As far as the rest of the patches for the Intel drivers go you might be
better off if you understood how we allocate queues on the ixgbe/ixgbevf
drivers. Usually we have the number of queues determined before we set
the number of vectors so your patches that limited the number of vectors
aren't going to have the effect you desire. So for example RSS
configuration is currently handled in either ixgbe_set_rss_queues or
ixgbe_set_dcb_queues depending on the mode the driver is in. You would
be much better off looking there for how to limit the RSS queueing on
the ixgbe adapter.
Thanks,
Alex
^ permalink raw reply
* [PATCH net] batman-adv: fix skb->data assignment
From: Antonio Quartulli @ 2012-06-19 19:26 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r,
stable-u79uwXL29TY76Z2rM5mHXA
skb_linearize(skb) possibly rearranges the skb internal data and then changes
the skb->data pointer value. For this reason any other pointer in the code that
was assigned skb->data before invoking skb_linearise(skb) must be re-assigned.
In the current tt_query message handling code this is not done and therefore, in
case of skb linearization, the pointer used to handle the packet header ends up
in pointing to free'd memory.
This bug was introduced by a73105b8d4c765d9ebfb664d0a66802127d8e4c7
(batman-adv: improved client announcement mechanism)
Signed-off-by: Antonio Quartulli <ordex-GaUfNO9RBHfsrOwW+9ziJQ@public.gmane.org>
Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
---
This patch has already been merged in net-next. I am sorry about that, but we
were missing some knowledge about sending patches for stable.
Thank you,
Antonio
net/batman-adv/routing.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/batman-adv/routing.c b/net/batman-adv/routing.c
index 840e2c6..015471d 100644
--- a/net/batman-adv/routing.c
+++ b/net/batman-adv/routing.c
@@ -617,6 +617,8 @@ int recv_tt_query(struct sk_buff *skb, struct hard_iface *recv_if)
* changes */
if (skb_linearize(skb) < 0)
goto out;
+ /* skb_linearize() possibly changed skb->data */
+ tt_query = (struct tt_query_packet *)skb->data;
tt_len = tt_query->tt_data * sizeof(struct tt_change);
--
1.7.9.4
^ permalink raw reply related
* Re: [RFC net-next 01/14] Add Default
From: Eilon Greenstein @ 2012-06-19 19:53 UTC (permalink / raw)
To: Alexander Duyck; +Cc: Yuval Mintz, netdev, davem
In-Reply-To: <4FE0CCA2.304@intel.com>
On Tue, 2012-06-19 at 12:01 -0700, Alexander Duyck wrote:
> On 06/19/2012 10:41 AM, Eilon Greenstein wrote:
> > On Tue, 2012-06-19 at 09:37 -0700, Alexander Duyck wrote:
> >> On 06/19/2012 08:13 AM, Yuval Mintz wrote:
> >>> Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
> >>> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
> >>> ---
> >>> include/linux/etherdevice.h | 5 ++++-
> >>> 1 files changed, 4 insertions(+), 1 deletions(-)
> >>>
> >>> diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
> >>> index 3d406e0..bb1ecaf 100644
> >>> --- a/include/linux/etherdevice.h
> >>> +++ b/include/linux/etherdevice.h
> >>> @@ -44,7 +44,10 @@ extern int eth_mac_addr(struct net_device *dev, void *p);
> >>> extern int eth_change_mtu(struct net_device *dev, int new_mtu);
> >>> extern int eth_validate_addr(struct net_device *dev);
> >>>
> >>> -
> >>> +/* The maximal number of RSS queues a driver should have unless configured
> >>> + * so explicitly.
> >>> + */
> >>> +#define DEFAULT_MAX_NUM_RSS_QUEUES (8)
> >>>
> >>> extern struct net_device *alloc_etherdev_mqs(int sizeof_priv, unsigned int txqs,
> >>> unsigned int rxqs);
> >> I'm not a big fan of just having this as a fixed define in the code. It
> >> seems like it would make much more sense to have this in the Kconfig
> >> somewhere as a range value if you plan on making this changeable in the
> >> future.
> > My original suggestion was a kernel command line parameter, but Dave was
> > less than enthusiastic. If you will follow the original thread, you can
> > probably understand why I decided to adopt Dave's constant approach
> > without suggesting Kconfig:
> > http://marc.info/?l=linux-netdev&m=133992386010982&w=2
> There is a huge difference between a kernel parameter an a kconfig
> value. The main idea behind the kconfig value is that you are going to
> have different preferences depending on architectures and such so it
> would make much more sense to have the default as a config option.
Yes, I'm aware of that. Coming from the orientation of number of CPUs
and memory constrains, the kernel parameter came to mind first, after
receiving the reply about using just a good default, I have considered
the kconfig alternative but decided not to make further suggestions and
just go with a good default.
> I'm not sure why you couldn't just limit it to 16. From what I can tell
> that is the largest number that gets used for RSS queues on almost all
> the different hardware out there.
cxgb4 32, myril10ge 32, efx 32, niu 24.
The point is that I was requested by a customer to support more queues,
but simply enabling that much more MSI-X vectors in the FW will cause
the driver to consume too much memory and this is probably not desired
for most users. Having the set_channels API is good solution to have a
default value which is different than the maximal value, and that brings
us to where we are now - finding a default value for all multi-queue
drivers.
> As far as the rest of the patches for the Intel drivers go you might be
> better off if you understood how we allocate queues on the ixgbe/ixgbevf
> drivers. Usually we have the number of queues determined before we set
> the number of vectors so your patches that limited the number of vectors
> aren't going to have the effect you desire. So for example RSS
> configuration is currently handled in either ixgbe_set_rss_queues or
> ixgbe_set_dcb_queues depending on the mode the driver is in. You would
> be much better off looking there for how to limit the RSS queueing on
> the ixgbe adapter.
OK, we will move the logic to those functions.
^ permalink raw reply
* pull request: wireless-next 2012-06-19
From: John W. Linville @ 2012-06-19 19:57 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
[-- Attachment #1: Type: text/plain, Size: 17569 bytes --]
commit b3c911eeb47d08aada986f769b6a060794dfe9d0
Dave,
This is a sizeable batch of updates intended for 3.6...
The bulk of the changes here are Bluetooth. Gustavo says:
Here goes the first Bluetooth pull request for 3.6, we have
queued quite a lot of work. Andrei Emeltchenko added the AMP
Manager code, a lot of work is needed, but the first bit are
already there. This code is disabled by default. Mat Martineau
changed the whole L2CAP ERTM state machine code, replacing
the old one with a new implementation. Besides that we had
lot of coding style fixes (to follow net rules), more l2cap
core separation from socket and many clean ups and fixed all
over the tree.
Along with the above, there is a healthy dose of ath9k, iwlwifi,
and other driver updates. There is also another pull from the
wireless tree to resolve some merge issues. I also fixed-up some
merge discrepencies between net-next and wireless-next.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 43b03f1f6d6832d744918947d185a7aee89d1e0f:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2012-06-12 21:59:18 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next.git for-davem
Andre Guedes (4):
Bluetooth: Change default MTU for L2CAP ATT channel
Bluetooth: Check MTU value in l2cap_sock_setsockopt_old
Bluetooth: Rename L2CAP_LE_DEFAULT_MTU
Bluetooth: Filter duplicated reports in LE scan
Andrei Emeltchenko (35):
Bluetooth: Silent sparse warnings
Bluetooth: Use defined link key size
Bluetooth: Preserve L2CAP flags values
Bluetooth: trivial: Remove empty line
Bluetooth: Define L2CAP conf continuation flag
Bluetooth: Define and use PSM identifiers
Bluetooth: Use __constant when dealing with constants
Bluetooth: Use __constant modifier in HCI code
Bluetooth: Define HCI AMP cmd struct
Bluetooth: Move clean up code and set of SOCK_ZAPPED to l2cap_sock.c
Bluetooth: Add l2cap_chan->ops->ready()
Bluetooth: trivial: Use defined PSMLEN instead of magic
Bluetooth: A2MP: Create A2MP channel
Bluetooth: A2MP: AMP Manager basic functions
Bluetooth: A2MP: Build and Send msg helpers
Bluetooth: A2MP: Add chan callbacks
Bluetooth: A2MP: Definitions for A2MP commands
Bluetooth: A2MP: Define A2MP status codes
Bluetooth: A2MP: Process A2MP messages
Bluetooth: A2MP: Process A2MP Command Reject
Bluetooth: A2MP: Process A2MP Discover Request
Bluetooth: A2MP: Process A2MP Change Notify
Bluetooth: A2MP: Process A2MP Get Info Request
Bluetooth: A2MP: Process A2MP Get AMP Assoc Request
Bluetooth: A2MP: Process A2MP Create Physlink Request
Bluetooth: A2MP: Process A2MP Disc Physlink Request
Bluetooth: A2MP: Process A2MP Command Responses
Bluetooth: A2MP: Handling fixed channels
Bluetooth: A2MP: Manage incoming connections
Bluetooth: Do not check func ready existence
Bluetooth: A2MP: Do not reference hci_conn
Bluetooth: Make l2cap_data_channel return void
Bluetooth: Make l2cap_conless_channel return void
Bluetooth: Make l2cap_att_channel return void
Bluetooth: Remove magic disconnect reason
Andrzej Kaczmarek (3):
Bluetooth: Allow only one LE connection attempt
Bluetooth: Return proper mgmt state when LE pairing connection failed
Bluetooth: Fix not removing hci_conn for failed LE connection
Arend van Spriel (4):
brcmsmac: remove brcms_set_hint() function
brcmsmac: fix smatch warning found in ampdu.c
brcmfmac: add debugfs helper functions
brcmfmac: expose sdio internal counters in debugfs
Ashok Nagarajan (1):
mac80211: add missing kernel-doc
Avinash Patil (1):
mwifiex: fix incorrect privacy setting in beacon and probe response
Bing Zhao (1):
Bluetooth: btmrvl: add SD8787 Bluetooth AMP device ID
Brandon Misemer (1):
iwlwifi: Fix Makefile build order for built-in driver
Dan Carpenter (2):
iwlwifi: turn on a lockdep assertion
iwlwifi: unlock on error path
David Spinadel (1):
mac80211: stop polling in disassociation
Eliad Peller (2):
cfg80211: fix potential deadlock in regulatory
mac80211: check sdata_running on ieee80211_set_bitrate_mask
Emmanuel Grumbach (10):
iwlwifi: s/iwl_read_targ_mem_words/iwl_read_targ_mem_bytes
iwlwifi: iwl_{read,write}_targ_mem_words takes dwords
iwlwifi: print more info when a queue is stuck
iwlwifi: don't configure a txq that is being disabled
iwlwifi: remove lock around txq_enable
iwlwifi: comment that setting driver_data overrides info->control
iwlwifi: print even more info when a queue is stuck
iwlwifi: don't modify the timer if we don't Tx
iwlwifi: warn if TFD index and WiFi Seq don't match
iwlwifi: WARN only once when we have trouble in reclaim
Gustavo Padovan (29):
Bluetooth: Fix coding style in mgmt.c
Bluetooth: Fix coding style in sco.c
Bluetooth: Fix coding style in hci_sock.c
Bluetooth: Fix coding style in hci_sysfs.c
Bluetooth: Fix coding style in hci_event.c
Bluetooth: Fix coding style in hci_conn.c
Bluetooth: Fix coding style in hci_core.c
Bluetooth: Do not purge queue in Basic Mode
Bluetooth: Remove double check for BT_CONNECTED
Bluetooth: Remove dead int returns
Bluetooth: Fix trailing whitespaces in license text
Bluetooth: Remove most of the inline usage
Bluetooth: Remove 'register' usage from the subsystem
Bluetooth: Fix coding style in include/net/bluetooth
Bluetooth: Fix coding style in the subsystem
Bluetooth: Remove unnecessary headers include
Bluetooth: Remove unneeded EXPORT_SYMBOL
Bluetooth: Use lmp_ssp_capable() macro
Bluetooth: Get a more accurate L2CAP PDU len
Bluetooth: Remove extra l2cap_state_change(BT_CONNECTED)
Bluetooth: Use l2cap_chan_ready() in LE path
Bluetooth: Use chan as parameters for l2cap chan ops
Bluetooth: Use chan->state instead of sk->sk_state
Bluetooth: Move check for backlog size to l2cap_sock.c
Bluetooth: check for already existent channel before create new one
Bluetooth: Create function to return the ERTM header size
Bluetooth: Remove unused err var from l2cap_segment_sdu()
Bluetooth: Create empty l2cap ops function
Bluetooth: Fix style in hidp code
Ilan Peer (2):
iwlwifi: refactor testmode
iwlwifi: decouple testmode and iwl-test
Johan Hedberg (4):
Bluetooth: Fix SMP pairing method selection
Bluetooth: Fix deadlock and crash when SMP pairing times out
Bluetooth: Fix SMP security elevation from medium to high
Bluetooth: Add support for encryption key refresh
Johannes Berg (5):
mac80211: add some missing kernel-doc
iwlwifi: fix dynamic loading
Merge remote-tracking branch 'wireless-next/master' into iwlwifi-next
iwlwifi: fix 6035 device parameters
iwlwifi: use request_module instead of _nowait
John W. Linville (6):
Merge branch 'for-upstream' of git://git.kernel.org/.../bluetooth/bluetooth
Merge branch 'master' of git://git.kernel.org/.../linville/wireless
Merge branch 'for-john' of git://git.kernel.org/.../jberg/mac80211
Merge branch 'for-upstream' of git://git.kernel.org/.../bluetooth/bluetooth-next
Merge branch 'master' of git://git.kernel.org/.../linville/wireless
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-next into for-davem
Jussi Kivilinna (1):
rndis_wlan: fix matching bssid check in rndis_check_bssid_list()
Mat Martineau (28):
Bluetooth: Free allocated ERTM SREJ list if init fails
Bluetooth: Fix early return from l2cap_chan_del
Bluetooth: Change default state of ERTM disable flag
Bluetooth: Add a new L2CAP ERTM transmit state machine.
Bluetooth: Refactor l2cap_streaming_send
Bluetooth: Refactor l2cap_ertm_send
Bluetooth: Refactor l2cap_send_sframe
Bluetooth: Consolidate common receive code for ERTM and streaming mode
Bluetooth: Add streaming mode receive and incoming packet classifier
Bluetooth: Remove receive code that has been superceded
Bluetooth: Refactor l2cap_send_ack
Bluetooth: Use the transmit state machine for busy state changes
Bluetooth: Update l2cap_send_i_or_rr_or_rnr to fit the spec better
Bluetooth: Add the ERTM receive state machine
Bluetooth: Add implementation for retransmitting all unacked frames
Bluetooth: Send SREJ frames when packets go missing
Bluetooth: Reassemble all available data when retransmissions succeed.
Bluetooth: Handle SREJ requests to resend unacked frames
Bluetooth: Handle incoming REJ frames
Bluetooth: Use new header structures in l2cap_send_rr_or_rnr
Bluetooth: Check rules when setting retransmit or monitor timers
Bluetooth: Use the ERTM transmit state machine from timeout handlers
Bluetooth: Simplify the ERTM ack timeout
Bluetooth: Remove unneccesary inline
Bluetooth: Set txwin values for streaming mode
Bluetooth: Remove unused ERTM control field macros
Bluetooth: Enable ERTM by default
Bluetooth: Send a configuration request after security confirmation
Michal Kazior (1):
cfg80211: check iface combinations only when iface is running
Mohammed Shafi Shajakhan (4):
ath9k: Fix a WARNING on suspend/resume with IBSS
ath9k: remove incompatible IBSS interface check in change_iface
ath9k: Fix softlockup in AR9485
ath9k: Fix softlockup in AR9485
Rajkumar Manoharan (19):
ath9k: choose legacy rate as last rate of MRR series
ath9k: restore power state on set channel failure
ath9k_hw: Fix AR9462 power consumption on idle associated
ath9k_hw: check GPM HW write pointer before chip reset
ath9k_hw: fix incorrect LNA register settings
ath9k_hw: program OBS register only when MCI is disabled
ath9k_hw: process MCI interrupts only when btcoex is enabled
ath9k: simplify btcoex profile management
ath9k: keep btcoex period in milliseconds
ath9k: defer btcoex scheme update
ath9k: fix btcoex duty cycle
ath9k_hw: cleanup MCI gpm offset state
ath9k_hw: add utility function to set BT version
ath9k_hw: remove MCI_STATE_SEND_WLAN_CHANNELS
ath9k_hw: remove MCI_STATE_NEED_FLUSH_BT_INFO
ath9k_hw: remove p_data argument from ar9003_mci_state
ath9k_hw: remove MCI_STATE_BT
ath9k_hw: remove MCI_STATE_CONT_* state
ath9k_hw: remove MCI_STATE_SET_BT_SLEEP
Sasha Levin (1):
Bluetooth: Really fix registering hci with duplicate name
Sujith Manoharan (1):
ath9k_hw: Update initvals for AR9462
Szymon Janc (2):
Bluetooth: Rename HCI_QUIRK_NO_RESET to HCI_QUIRK_RESET_ON_CLOSE
Bluetooth: Remove unused HCI timeouts definitions
Vinicius Costa Gomes (1):
Bluetooth: Fix checking the wrong flag when accepting a socket
Vishal Agarwal (1):
Bluetooth: Fix LE pairing completion on connection failure
drivers/bluetooth/bluecard_cs.c | 10 +-
drivers/bluetooth/bpa10x.c | 2 +-
drivers/bluetooth/bt3c_cs.c | 4 +-
drivers/bluetooth/btmrvl_sdio.c | 3 +
drivers/bluetooth/btuart_cs.c | 4 +-
drivers/bluetooth/btusb.c | 14 +-
drivers/bluetooth/dtl1_cs.c | 4 +-
drivers/bluetooth/hci_bcsp.c | 2 +-
drivers/bluetooth/hci_h4.c | 2 +-
drivers/bluetooth/hci_ldisc.c | 2 +-
drivers/bluetooth/hci_ll.c | 6 +-
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 7 +-
drivers/net/wireless/ath/ath9k/ar9003_mci.c | 330 ++--
drivers/net/wireless/ath/ath9k/ar9003_mci.h | 32 +-
.../net/wireless/ath/ath9k/ar9462_2p0_initvals.h | 2 +-
drivers/net/wireless/ath/ath9k/ath9k.h | 1 +
drivers/net/wireless/ath/ath9k/gpio.c | 10 +-
drivers/net/wireless/ath/ath9k/hw.c | 11 +-
drivers/net/wireless/ath/ath9k/link.c | 8 +
drivers/net/wireless/ath/ath9k/main.c | 22 +-
drivers/net/wireless/ath/ath9k/mci.c | 162 +-
drivers/net/wireless/ath/ath9k/rc.c | 17 +-
drivers/net/wireless/ath/ath9k/reg.h | 4 +-
drivers/net/wireless/brcm80211/brcmfmac/Makefile | 2 +
drivers/net/wireless/brcm80211/brcmfmac/dhd.h | 3 +
drivers/net/wireless/brcm80211/brcmfmac/dhd_dbg.c | 126 ++
drivers/net/wireless/brcm80211/brcmfmac/dhd_dbg.h | 59 +
.../net/wireless/brcm80211/brcmfmac/dhd_linux.c | 7 +
drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c | 169 +-
drivers/net/wireless/brcm80211/brcmsmac/ampdu.c | 5 +-
.../net/wireless/brcm80211/brcmsmac/mac80211_if.c | 14 +-
drivers/net/wireless/iwlwifi/Makefile | 10 +-
drivers/net/wireless/iwlwifi/dvm/agn.h | 17 +-
drivers/net/wireless/iwlwifi/dvm/dev.h | 26 +-
drivers/net/wireless/iwlwifi/dvm/lib.c | 2 +-
drivers/net/wireless/iwlwifi/dvm/mac80211.c | 2 +-
drivers/net/wireless/iwlwifi/dvm/main.c | 6 +-
drivers/net/wireless/iwlwifi/dvm/rx.c | 24 +-
drivers/net/wireless/iwlwifi/dvm/testmode.c | 778 +-------
drivers/net/wireless/iwlwifi/dvm/tx.c | 4 +-
drivers/net/wireless/iwlwifi/iwl-drv.c | 38 +-
drivers/net/wireless/iwlwifi/iwl-fh.h | 2 +
drivers/net/wireless/iwlwifi/iwl-io.c | 20 +-
drivers/net/wireless/iwlwifi/iwl-io.h | 14 +-
drivers/net/wireless/iwlwifi/iwl-test.c | 856 ++++++++
drivers/net/wireless/iwlwifi/iwl-test.h | 161 ++
.../iwlwifi/{dvm/testmode.h => iwl-testmode.h} | 0
drivers/net/wireless/iwlwifi/pcie/6000.c | 1 +
drivers/net/wireless/iwlwifi/pcie/internal.h | 9 +-
drivers/net/wireless/iwlwifi/pcie/trans.c | 71 +-
drivers/net/wireless/iwlwifi/pcie/tx.c | 95 +-
drivers/net/wireless/mwifiex/uap_cmd.c | 11 +
drivers/net/wireless/rndis_wlan.c | 2 +-
include/net/bluetooth/a2mp.h | 126 ++
include/net/bluetooth/bluetooth.h | 39 +-
include/net/bluetooth/hci.h | 105 +-
include/net/bluetooth/hci_core.h | 29 +-
include/net/bluetooth/l2cap.h | 205 +--
include/net/mac80211.h | 6 +
net/bluetooth/Makefile | 3 +-
net/bluetooth/a2mp.c | 568 ++++++
net/bluetooth/af_bluetooth.c | 14 +-
net/bluetooth/bnep/core.c | 21 +-
net/bluetooth/bnep/netdev.c | 16 +-
net/bluetooth/bnep/sock.c | 18 +-
net/bluetooth/hci_conn.c | 98 +-
net/bluetooth/hci_core.c | 214 +-
net/bluetooth/hci_event.c | 357 ++--
net/bluetooth/hci_sock.c | 59 +-
net/bluetooth/hci_sysfs.c | 99 +-
net/bluetooth/hidp/core.c | 26 +-
net/bluetooth/hidp/sock.c | 16 +-
net/bluetooth/l2cap_core.c | 2132 ++++++++++++--------
net/bluetooth/l2cap_sock.c | 130 ++-
net/bluetooth/lib.c | 7 +-
net/bluetooth/mgmt.c | 89 +-
net/bluetooth/rfcomm/core.c | 32 +-
net/bluetooth/rfcomm/sock.c | 21 +-
net/bluetooth/rfcomm/tty.c | 9 +-
net/bluetooth/sco.c | 43 +-
net/bluetooth/smp.c | 18 +-
net/mac80211/cfg.c | 3 +
net/mac80211/mlme.c | 4 +-
net/mac80211/sta_info.h | 5 +
net/wireless/reg.c | 2 +-
net/wireless/util.c | 2 +-
86 files changed, 4743 insertions(+), 2966 deletions(-)
create mode 100644 drivers/net/wireless/brcm80211/brcmfmac/dhd_dbg.c
create mode 100644 drivers/net/wireless/iwlwifi/iwl-test.c
create mode 100644 drivers/net/wireless/iwlwifi/iwl-test.h
rename drivers/net/wireless/iwlwifi/{dvm/testmode.h => iwl-testmode.h} (100%)
create mode 100644 include/net/bluetooth/a2mp.h
create mode 100644 net/bluetooth/a2mp.c
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* pull-request: can-next 2012-06-19
From: Marc Kleine-Budde @ 2012-06-19 20:01 UTC (permalink / raw)
To: davem; +Cc: Linux Netdev List, linux-can@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 2556 bytes --]
Hello David,
here is our second pull request for net-next. In this series Federico
Vaga adds a pci driver for c_can/d_can hardware using the existing
generic c_can driver. The remaining 6 patches are by Oliver Hartkopp.
He adds CANFD support to the CAN stack while keeping binary
compatibility for existing applications. CANFD is an extension to the
existing CAN standard, it allows longer CAN frames and/or higher data
rates. There's no real hardware available yet, but this series adds
CANFD support to the vcan driver.
regards,
Marc
---
The following changes since commit b31525d16b50fe0eb33545afbc0be1a03f2896e3:
net: lpc_eth: Driver cleanup (2012-06-19 00:27:03 -0700)
are available in the git repository at:
git://gitorious.org/linux-can/linux-can-next.git master
for you to fetch changes up to ea53fe0c667ad3cae61d4d71d2be41908ac5c0a4:
canfd: update documentation according to CAN FD extensions (2012-06-19 21:40:26 +0200)
----------------------------------------------------------------
Federico Vaga (1):
c_can_pci: generic module for C_CAN/D_CAN on PCI
Oliver Hartkopp (6):
canfd: add new data structures and constants
canfd: add support for CAN FD in PF_CAN core
canfd: add support for CAN FD in CAN_RAW sockets
candev: add/update helpers for CAN FD
vcan: add CAN FD support
canfd: update documentation according to CAN FD extensions
Documentation/networking/can.txt | 154 ++++++++++++++++++++++++++++--
drivers/net/can/c_can/Kconfig | 7 ++
drivers/net/can/c_can/Makefile | 1 +
drivers/net/can/c_can/c_can_pci.c | 236 ++++++++++++++++++++++++++++++++++++++++++++++
drivers/net/can/dev.c | 35 ++++++-
drivers/net/can/vcan.c | 27 ++++--
include/linux/can.h | 59 +++++++++++-
include/linux/can/core.h | 4 +-
include/linux/can/dev.h | 33 +++++--
include/linux/can/raw.h | 3 +-
include/linux/if_ether.h | 3 +-
net/can/af_can.c | 116 +++++++++++++++++------
net/can/raw.c | 50 +++++++++-
13 files changed, 664 insertions(+), 64 deletions(-)
create mode 100644 drivers/net/can/c_can/c_can_pci.c
--
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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* 10GBE performance drop with net.ipv4.tcp_timestamps=0
From: Stefan Priebe @ 2012-06-19 21:08 UTC (permalink / raw)
To: Linux Netdev List
Hello List,
i'm testing 10GBE speed with tweo servers. One with 3.5-rc3 nd thoe
other one whith RHEL 6 (2.6.32 kernel).
I noticed that setting
net.ipv4.tcp_timestamps=0
descreased the performance from 9,7 Full Duplex to 3-4Gb/s.
Is this bahviour fine? What should / could i tet?
Greets
Stefan
^ permalink raw reply
* Re: [PATCH] ipv6: Prevent access to uninitialized fib_table_hash via /proc/net/ipv6_route
From: David Miller @ 2012-06-19 21:13 UTC (permalink / raw)
To: tgraf; +Cc: nhorman, netdev
In-Reply-To: <20120619113602.GG27921@canuck.infradead.org>
From: Thomas Graf <tgraf@suug.ch>
Date: Tue, 19 Jun 2012 07:36:02 -0400
> On Fri, Jun 15, 2012 at 03:32:40PM -0700, David Miller wrote:
>> Since you're snooping around in here, you might notice that on network
>> namespace shutdown, we leak all user configured ipv6 FIB rules.
>
> I looked into this. fib_rules_unregister() will free all rules
> belonging to the address family in that namespace.
>
> Or were you referring to other rules?
Sorry, the leak I saw was for the fib6 tables, not the rules
themselves.
IPV4 has ip_fib_net_exit() which walks the FIB4 table hash
and releases everything.
I couldn't find the IPV6 counterpart. All I could find was code which
explicitly liberates the ipv6 main and local tables.
There is no ipv6 code I can find which traverses fib_table_hash and
liberates the dynamically generated tables.
^ permalink raw reply
* Re: [RFC] TCP: Support configurable delayed-ack parameters.
From: David Miller @ 2012-06-19 21:21 UTC (permalink / raw)
To: greearb; +Cc: eric.dumazet, netdev, dbaluta
In-Reply-To: <4FE0A4CF.6000906@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
Date: Tue, 19 Jun 2012 09:11:59 -0700
> Dave..any opinion on this? I'll be happy to get rid of the
> multiply caching if it's agreed that it should not be there.
I disagree fundamentally with the feature.
I can't believe for one minute that we can't do ACK stretching
dynamically using reasonable heuristics.
And, as Stephen said, we already have too many damn knobs.
^ permalink raw reply
* Re: [RFC net-next 01/14] Add Default
From: David Miller @ 2012-06-19 21:22 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: yuvalmin, netdev, eilong
In-Reply-To: <4FE0AABE.4070100@intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Tue, 19 Jun 2012 09:37:18 -0700
> I'm not a big fan of just having this as a fixed define in the code. It
> seems like it would make much more sense to have this in the Kconfig
> somewhere as a range value if you plan on making this changeable in the
> future.
Please not Kconfig :-/
^ permalink raw reply
* Re: [RFC net-next 01/14] Add Default
From: David Miller @ 2012-06-19 21:26 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: eilong, yuvalmin, netdev
In-Reply-To: <4FE0CCA2.304@intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Tue, 19 Jun 2012 12:01:54 -0700
> There is a huge difference between a kernel parameter an a kconfig
> value. The main idea behind the kconfig value is that you are going to
> have different preferences depending on architectures and such so it
> would make much more sense to have the default as a config option.
I don't think the issue of how many queues to use in a network driver
when you have 1024 cpus is architecture specific.
Please drop this idea, thanks.
^ permalink raw reply
* Re: [RFC] TCP: Support configurable delayed-ack parameters.
From: Ben Greear @ 2012-06-19 21:27 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev, dbaluta
In-Reply-To: <20120619.142158.2026176205742396086.davem@davemloft.net>
On 06/19/2012 02:21 PM, David Miller wrote:
> From: Ben Greear<greearb@candelatech.com>
> Date: Tue, 19 Jun 2012 09:11:59 -0700
>
>> Dave..any opinion on this? I'll be happy to get rid of the
>> multiply caching if it's agreed that it should not be there.
>
> I disagree fundamentally with the feature.
>
> I can't believe for one minute that we can't do ACK stretching
> dynamically using reasonable heuristics.
>
> And, as Stephen said, we already have too many damn knobs.
Ok...I'll let someone else take a stab at that.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH net] batman-adv: fix skb->data assignment
From: David Miller @ 2012-06-19 21:28 UTC (permalink / raw)
To: ordex; +Cc: netdev, b.a.t.m.a.n, stable
In-Reply-To: <1340133999-26838-1-git-send-email-ordex@autistici.org>
From: Antonio Quartulli <ordex@autistici.org>
Date: Tue, 19 Jun 2012 21:26:39 +0200
> This patch has already been merged in net-next. I am sorry about that, but we
> were missing some knowledge about sending patches for stable.
You really like making my life miserable.
What is so damn complicated about:
1) BUG FIXES go to 'net'
2) NON BUG FIXES go to 'net-next'
This gets stated repeatedly here.
I do see you guys erroneously submit bug fixes into net-next all
the time but I just assumed you simply didn't give a shit about
bug fixes propagating quickly.
You guys definitely need to get your asses in gear.
^ permalink raw reply
* Re: 10GBE performance drop with net.ipv4.tcp_timestamps=0
From: Eric Dumazet @ 2012-06-19 21:31 UTC (permalink / raw)
To: Stefan Priebe; +Cc: Linux Netdev List
In-Reply-To: <4FE0EA33.1000309@profihost.ag>
On Tue, 2012-06-19 at 23:08 +0200, Stefan Priebe wrote:
> Hello List,
>
> i'm testing 10GBE speed with tweo servers. One with 3.5-rc3 nd thoe
> other one whith RHEL 6 (2.6.32 kernel).
>
> I noticed that setting
> net.ipv4.tcp_timestamps=0
>
> descreased the performance from 9,7 Full Duplex to 3-4Gb/s.
>
> Is this bahviour fine? What should / could i tet?
>
Really, you should provide more input than that, if you really want us
to help.
^ permalink raw reply
* Re: [net-next patch 0/11 v2] bnx2x: ethtool and other enhancements
From: David Miller @ 2012-06-19 21:35 UTC (permalink / raw)
To: meravs; +Cc: netdev, eilong
In-Reply-To: <1340104634-14353-1-git-send-email-meravs@broadcom.com>
From: "Merav Sicron" <meravs@broadcom.com>
Date: Tue, 19 Jun 2012 14:17:03 +0300
> This patch series adds few features to bnx2x:
> Add support for external LB in ethtool self-test
> Enable UDP RSS on 4-tupple, controlled by ethtool
> Support up to 63 RSS queues (rather than 16)
> Add support for setting the desired number of RSS queues via ethtool
> Allow to configure dcbx admin params from all drivers on a single physical port
> Add FCoE capabilities advertisement
All applied, thanks.
^ permalink raw reply
* Re: pull request: wireless-next 2012-06-19
From: David Miller @ 2012-06-19 21:38 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20120619195757.GA7466@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 19 Jun 2012 15:57:57 -0400
> This is a sizeable batch of updates intended for 3.6...
>
> The bulk of the changes here are Bluetooth. Gustavo says:
>
> Here goes the first Bluetooth pull request for 3.6, we have
> queued quite a lot of work. Andrei Emeltchenko added the AMP
> Manager code, a lot of work is needed, but the first bit are
> already there. This code is disabled by default. Mat Martineau
> changed the whole L2CAP ERTM state machine code, replacing
> the old one with a new implementation. Besides that we had
> lot of coding style fixes (to follow net rules), more l2cap
> core separation from socket and many clean ups and fixed all
> over the tree.
>
> Along with the above, there is a healthy dose of ath9k, iwlwifi,
> and other driver updates. There is also another pull from the
> wireless tree to resolve some merge issues. I also fixed-up some
> merge discrepencies between net-next and wireless-next.
>
> Please let me know if there are problems!
Pulled, thanks JOhn.
^ permalink raw reply
* Re: pull-request: can-next 2012-06-19
From: David Miller @ 2012-06-19 21:48 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can
In-Reply-To: <4FE0DAB4.6080400@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Tue, 19 Jun 2012 22:01:56 +0200
> here is our second pull request for net-next. In this series Federico
> Vaga adds a pci driver for c_can/d_can hardware using the existing
> generic c_can driver. The remaining 6 patches are by Oliver Hartkopp.
> He adds CANFD support to the CAN stack while keeping binary
> compatibility for existing applications. CANFD is an extension to the
> existing CAN standard, it allows longer CAN frames and/or higher data
> rates. There's no real hardware available yet, but this series adds
> CANFD support to the vcan driver.
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH net] batman-adv: fix skb->data assignment
From: David Miller @ 2012-06-19 21:49 UTC (permalink / raw)
To: ordex; +Cc: netdev, b.a.t.m.a.n, stable
In-Reply-To: <1340133999-26838-1-git-send-email-ordex@autistici.org>
From: Antonio Quartulli <ordex@autistici.org>
Date: Tue, 19 Jun 2012 21:26:39 +0200
> skb_linearize(skb) possibly rearranges the skb internal data and then changes
> the skb->data pointer value. For this reason any other pointer in the code that
> was assigned skb->data before invoking skb_linearise(skb) must be re-assigned.
>
> In the current tt_query message handling code this is not done and therefore, in
> case of skb linearization, the pointer used to handle the packet header ends up
> in pointing to free'd memory.
>
> This bug was introduced by a73105b8d4c765d9ebfb664d0a66802127d8e4c7
> (batman-adv: improved client announcement mechanism)
>
> Signed-off-by: Antonio Quartulli <ordex@autistici.org>
> Cc: <stable@vger.kernel.org>
Applied.
Submit things properly in the future so you don't give me unnecessary
merge hassles like this again.
^ 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