* [net-next-2.6] net/bridge: fix trivial sparse errors
From: Tomas Winkler @ 2011-01-03 21:08 UTC (permalink / raw)
To: davem; +Cc: netdev, Tomas Winkler
net/bridge//br_stp_if.c:148:66: warning: conversion of
net/bridge//br_stp_if.c:148:66: int to
net/bridge//br_stp_if.c:148:66: int enum umh_wait
net/bridge//netfilter/ebtables.c:1150:30: warning: Using plain integer as NULL pointer
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
net/bridge/br_stp_if.c | 2 +-
net/bridge/netfilter/ebtables.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/bridge/br_stp_if.c b/net/bridge/br_stp_if.c
index 1d88269..79372d4 100644
--- a/net/bridge/br_stp_if.c
+++ b/net/bridge/br_stp_if.c
@@ -145,7 +145,7 @@ static void br_stp_stop(struct net_bridge *br)
char *envp[] = { NULL };
if (br->stp_enabled == BR_USER_STP) {
- r = call_usermodehelper(BR_STP_PROG, argv, envp, 1);
+ r = call_usermodehelper(BR_STP_PROG, argv, envp, UMH_WAIT_PROC);
br_info(br, "userspace STP stopped, return code %d\n", r);
/* To start timers on any ports left in blocking */
diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c
index cbc9f39..16df053 100644
--- a/net/bridge/netfilter/ebtables.c
+++ b/net/bridge/netfilter/ebtables.c
@@ -1147,7 +1147,7 @@ ebt_register_table(struct net *net, const struct ebt_table *input_table)
void *p;
if (input_table == NULL || (repl = input_table->table) == NULL ||
- repl->entries == 0 || repl->entries_size == 0 ||
+ repl->entries == NULL || repl->entries_size == 0 ||
repl->counters != NULL || input_table->private != NULL) {
BUGPRINT("Bad table data for ebt_register_table!!!\n");
return ERR_PTR(-EINVAL);
--
1.7.3.4
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply related
* Re: [PATCH] ksz884x: Fix section mismatch derived from pci_device_driver variable
From: Sedat Dilek @ 2011-01-03 21:07 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel
In-Reply-To: <20110103.115248.179942629.davem@davemloft.net>
On Mon, Jan 3, 2011 at 8:52 PM, David Miller <davem@davemloft.net> wrote:
> From: Sedat Dilek <sedat.dilek@googlemail.com>
> Date: Mon, 3 Jan 2011 03:01:44 +0100
>
>> WARNING: drivers/net/ksz884x.o(.data+0x18): Section mismatch in reference from the variable pci_device_driver to the function .init.text:pcidev_init()
>> The variable pci_device_driver references
>> the function __init pcidev_init()
>> If the reference is valid then annotate the
>> variable with __init* or __refdata (see linux/init.h) or name the variable:
>> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
>>
>> This patch fixes the warning.
>>
>> Tested with linux-next (next-20101231)
>>
>> Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com>
>
> pcidev_init() should be marked __devinit instead of __init to fix this
> bug.
>
I have sent a new fixed version.
- Sedat -
^ permalink raw reply
* [PATCH] ksz884x: Fix section mismatch derived from pcidev_init()
From: Sedat Dilek @ 2011-01-03 21:06 UTC (permalink / raw)
To: netdev, linux-kernel, davem; +Cc: Sedat Dilek
This fixes the following warning:
WARNING: drivers/net/ksz884x.o(.data+0x18): Section mismatch in reference from the variable pci_device_driver to the function .init.text:pcidev_init()
The variable pci_device_driver references
the function __init pcidev_init()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
Tested with linux-next (next-20101231)
Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com>
---
drivers/net/ksz884x.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ksz884x.c b/drivers/net/ksz884x.c
index 49ea870..540a8dc 100644
--- a/drivers/net/ksz884x.c
+++ b/drivers/net/ksz884x.c
@@ -6953,7 +6953,7 @@ static void read_other_addr(struct ksz_hw *hw)
#define PCI_VENDOR_ID_MICREL_KS 0x16c6
#endif
-static int __init pcidev_init(struct pci_dev *pdev,
+static int __devinit pcidev_init(struct pci_dev *pdev,
const struct pci_device_id *id)
{
struct net_device *dev;
--
1.7.4.rc0
^ permalink raw reply related
* Re: [PATCH v2 00/12] make rpc_pipefs be mountable multiple time
From: Rob Landley @ 2011-01-03 20:48 UTC (permalink / raw)
To: Trond Myklebust
Cc: Kirill A. Shutemov, Rob Landley, J. Bruce Fields, Neil Brown,
Pavel Emelyanov, linux-nfs, David S. Miller, netdev, linux-kernel
In-Reply-To: <1293814441.2980.4.camel@heimdal.trondhjem.org>
On 12/31/2010 10:54 AM, Trond Myklebust wrote:
>> I'm kind of surprised that the kernel cares about a specific path under
>> /var/lib. (Seems like policy in the kernel somehow.) Can't it just
>> check the current process's mount list to see if an instance of
>> rpc_pipefs is mounted in the current namespace the way lxc looks for
>> cgroups? Or are there potential performance/scalability issues with that?
>
> The kernel doesn't give a damn about the /var/lib/nfs/rpc_pipefs bit.
> That's all for the benefit of the userland utilities.
Are you saying that if you go into a container and that mount point
doesn't exist, the kernel will still be able to find and use rpc_pipefs?
Without userspace creating a specific magic path and mounting a
filesystem on it?
If so, I misread the patch...
Rob
^ permalink raw reply
* Re: [PATCH v2 net-next-2.6] ifb: add performance flags
From: David Miller @ 2011-01-03 20:40 UTC (permalink / raw)
To: eric.dumazet; +Cc: jarkao2, xiaosuo, pstaszewski, netdev
In-Reply-To: <1294086922.2711.18.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 03 Jan 2011 21:35:22 +0100
> Le lundi 03 janvier 2011 à 11:40 -0800, David Miller a écrit :
>> I think at least TSO6 would very much be appropriate here.
>
> Yes, why not, I am only wondering why loopback / dummy (and others ?)
> only set NETIF_F_TSO :)
TSO6 probably didn't exist when the current set were added,
at least in the loopback case that's almost certainly the
reason.
> Since I want to play with ECN, I might also add NETIF_F_TSO_ECN ;)
>
> For other flags, I really doubt it can matter on ifb ?
>
> [PATCH v3 net-next-2.6] ifb: add performance flags
>
> IFB can use the full set of features flags (NETIF_F_SG |
> NETIF_F_FRAGLIST | NETIF_F_TSO | NETIF_F_NO_CSUM | NETIF_F_HIGHDMA) to
> avoid unnecessary split of some packets (GRO for example)
>
> Changli suggested to also set vlan_features, NETIF_F_TSO6,
> NETIF_F_TSO_ECN.
>
> Jarek suggested to add NETIF_F_HW_VLAN_TX as well.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
I'll apply this, thanks Eric.
^ permalink raw reply
* Re: [PATCH v2 00/12] make rpc_pipefs be mountable multiple time
From: Rob Landley @ 2011-01-03 20:38 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Rob Landley, Trond Myklebust, J. Bruce Fields, Neil Brown,
Pavel Emelyanov, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
David S. Miller, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20101231130329.GA3610-oKw7cIdHH8eLwutG50LtGA@public.gmane.org>
On 12/31/2010 07:03 AM, Kirill A. Shutemov wrote:
> EXPORT_SYMBOL_GPL(get_rpc_pipefs);
>
> Something like this? Patch to replace patch #10 attached.
Looks good to me. Thanks.
acked-by: Rob Landley <rlandley-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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: [net-next-2.6 PATCH v2 3/3] net_sched: implement a root container qdisc sch_mclass
From: John Fastabend @ 2011-01-03 20:37 UTC (permalink / raw)
To: Jarek Poplawski
Cc: davem@davemloft.net, netdev@vger.kernel.org, hadi@cyberus.ca,
shemminger@vyatta.com, tgraf@infradead.org,
eric.dumazet@gmail.com, bhutchings@solarflare.com,
nhorman@tuxdriver.com
In-Reply-To: <20110103170244.GA1843@del.dom.local>
On 1/3/2011 9:02 AM, Jarek Poplawski wrote:
> On Sun, Jan 02, 2011 at 09:43:27PM -0800, John Fastabend wrote:
>> On 12/30/2010 3:37 PM, Jarek Poplawski wrote:
>>> John Fastabend wrote:
>>>> This implements a mclass 'multi-class' queueing discipline that by
>>>> default creates multiple mq qdisc's one for each traffic class. Each
>>>> mq qdisc then owns a range of queues per the netdev_tc_txq mappings.
>>>
>>> Is it really necessary to add one more abstraction layer for this,
>>> probably not most often used (or even asked by users), functionality?
>>> Why mclass can't simply do these few things more instead of attaching
>>> (and changing) mq?
>>>
>>
>> The statistics work nicely when the mq qdisc is used.
>
> Well, I sometimes add leaf qdiscs only to get class stats with less
> typing, too ;-)
>
>>
>> qdisc mclass 8002: root tc 4 map 0 1 2 3 0 1 2 3 1 1 1 1 1 1 1 1
>> queues:(0:1) (2:3) (4:5) (6:15)
>> Sent 140 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> qdisc mq 8003: parent 8002:1
>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> qdisc mq 8004: parent 8002:2
>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> qdisc mq 8005: parent 8002:3
>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> qdisc mq 8006: parent 8002:4
>> Sent 140 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> qdisc sfq 8007: parent 8005:1 limit 127p quantum 1514b
>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> qdisc sfq 8008: parent 8005:2 limit 127p quantum 1514b
>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>>
>> The mclass gives the statistics for the interface and then statistics on the mq qdisc gives statistics for each traffic class. Also, when using the 'mq qdisc' with this abstraction other qdisc can be grafted onto the queue. For example the sch_sfq is used in the above example.
>
> IMHO, these tc offsets and counts make simply two level hierarchy
> (classes with leaf subclasses) similarly (or simpler) to other
> classful qdisc which manage it all inside one module. Of course,
> we could think of another way of code organization, but it should
> be rather done at the beginning of schedulers design. The mq qdisc
> broke the design a bit adding a fake root, but I doubt we should go
> deeper unless it's necessary. Doing mclass (or something) as a more
> complex alternative to mq should be enough. Why couldn't mclass graft
> sch_sfq the same way as mq?
>
If you also want to graft a scheduler onto a traffic class now your stuck. For now this qdisc doesn't exist, but I would like to have a software implementation of the currently offloaded DCB ETS scheduler. The 802.1Qaz spec allows different scheduling algorithms to be used on each traffic class. In the current implementation mclass could graft these scheduling schemes onto each traffic class independently.
mclass
|
-------------------------------------------------------
| | | | | | | |
mq_tbf mq_tbf mq_ets mq_ets mq mq mq_wrr greedy
| |
--------- ---------
| | | | | |
red red red red red red
Perhaps, being concerned with hypothetical qdiscs is a bit of a stretch but I would like to at least not preclude this work from being done in the future.
>>
>> Although I am not too hung up on this use case it does seem to be a good abstraction to me. Is it strictly necessary though no and looking at the class statistics of mclass could be used to get stats per traffic class.
>
> I am not too hung up on this either, especially if it's OK to others,
> especially to DaveM ;-)
>
>>
>>> ...
>>>> diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
>>>> index 0af57eb..723ee52 100644
>>>> --- a/include/net/sch_generic.h
>>>> +++ b/include/net/sch_generic.h
>>>> @@ -50,6 +50,7 @@ struct Qdisc {
>>>> #define TCQ_F_INGRESS 4
>>>> #define TCQ_F_CAN_BYPASS 8
>>>> #define TCQ_F_MQROOT 16
>>>> +#define TCQ_F_MQSAFE 32
>>>
>>> If every other qdisc added a flag for qdiscs it likes...
>>>
>>
>> then we run out of bits and get unneeded complexity. I think I will drop the MQSAFE bit completely and let user space catch this. The worst that should happen is the noop qdisc is used.
>
> Maybe you're right. On the other hand, usually flags are added for
> more general purpose and the optimal/wrong configs are the matter of
> documentation.
>
So we handle this with documentation.
>>
>>>> @@ -709,7 +709,13 @@ static void attach_default_qdiscs(struct net_device *dev)
>>>> dev->qdisc = txq->qdisc_sleeping;
>>>> atomic_inc(&dev->qdisc->refcnt);
>>>> } else {
>>>> - qdisc = qdisc_create_dflt(txq, &mq_qdisc_ops, TC_H_ROOT);
>>>> + if (dev->num_tc)
>>>
>>> Actually, where this num_tc is expected to be set? I can see it inside
>>> mclass only, with unsetting on destruction, but probably I miss something.
>>
>> Either through mclass as you noted or a driver could set the num_tc. One of the RFC's I sent out has ixgbe setting the num_tc when DCB was enabled.
>
> OK, I probably missed this second possibility in the last version.
>
> ...
>>>> + /* Unwind attributes on failure */
>>>> + u8 unwnd_tc = dev->num_tc;
>>>> + u8 unwnd_map[16];
>>>
>>> [TC_MAX_QUEUE] ?
>>
>> Actually TC_BITMASK+1 is probably more accurate. This array maps the skb priority to a traffic class after the priority is masked with TC_BITMASK.
>>
>>>
>>>> + struct netdev_tc_txq unwnd_txq[16];
>>>> +
>>
>> Although unwnd_txq should be TC_MAX_QUEUE.
> ...
>>>> + /* Always use supplied priority mappings */
>>>> + for (i = 0; i < 16; i++) {
>>>
>>> i < qopt->num_tc ?
>>
>> Nope, TC_BITMASK+1 here. If we only have 4 tcs for example we still need to map all 16 priority values to a tc.
>
> OK, anyway, all these '16' should be 'upgraded'.
Yes. I'll do this in the next version.
Thanks,
John.
>
> Thanks,
> Jarek P.
^ permalink raw reply
* Re: [PATCH v2 net-next-2.6] ifb: add performance flags
From: Eric Dumazet @ 2011-01-03 20:35 UTC (permalink / raw)
To: David Miller; +Cc: jarkao2, xiaosuo, pstaszewski, netdev
In-Reply-To: <20110103.114033.28807428.davem@davemloft.net>
Le lundi 03 janvier 2011 à 11:40 -0800, David Miller a écrit :
> From: Jarek Poplawski <jarkao2@gmail.com>
> Date: Mon, 3 Jan 2011 20:37:03 +0100
>
> > On Sun, Jan 02, 2011 at 09:24:36PM +0100, Eric Dumazet wrote:
> >> Le mercredi 29 décembre 2010 ?? 00:07 +0100, Jarek Poplawski a écrit :
> >>
> >> > Ingress is before vlans handler so these features and the
> >> > NETIF_F_HW_VLAN_TX flag seem useful for ifb considering
> >> > dev_hard_start_xmit() checks.
> >>
> >> OK, here is v2 of the patch then, thanks everybody.
> >>
> >>
> >> [PATCH v2 net-next-2.6] ifb: add performance flags
> >>
> >> IFB can use the full set of features flags (NETIF_F_SG |
> >> NETIF_F_FRAGLIST | NETIF_F_TSO | NETIF_F_NO_CSUM | NETIF_F_HIGHDMA) to
> >> avoid unnecessary split of some packets (GRO for example)
> >>
> >> Changli suggested to also set vlan_features,
> >
> > He also suggested more GSO flags of which especially NETIF_F_TSO6
> > seems interesting (wrt GRO)?
>
> I think at least TSO6 would very much be appropriate here.
Yes, why not, I am only wondering why loopback / dummy (and others ?)
only set NETIF_F_TSO :)
Since I want to play with ECN, I might also add NETIF_F_TSO_ECN ;)
For other flags, I really doubt it can matter on ifb ?
[PATCH v3 net-next-2.6] ifb: add performance flags
IFB can use the full set of features flags (NETIF_F_SG |
NETIF_F_FRAGLIST | NETIF_F_TSO | NETIF_F_NO_CSUM | NETIF_F_HIGHDMA) to
avoid unnecessary split of some packets (GRO for example)
Changli suggested to also set vlan_features, NETIF_F_TSO6,
NETIF_F_TSO_ECN.
Jarek suggested to add NETIF_F_HW_VLAN_TX as well.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Changli Gao <xiaosuo@gmail.com>
Cc: Jarek Poplawski <jarkao2@gmail.com>
Cc: Pawel Staszewski <pstaszewski@itcare.pl>
---
drivers/net/ifb.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ifb.c b/drivers/net/ifb.c
index 124dac4..e07d487 100644
--- a/drivers/net/ifb.c
+++ b/drivers/net/ifb.c
@@ -126,6 +126,10 @@ static const struct net_device_ops ifb_netdev_ops = {
.ndo_validate_addr = eth_validate_addr,
};
+#define IFB_FEATURES (NETIF_F_NO_CSUM | NETIF_F_SG | NETIF_F_FRAGLIST | \
+ NETIF_F_TSO_ECN | NETIF_F_TSO | NETIF_F_TSO6 | \
+ NETIF_F_HIGHDMA | NETIF_F_HW_VLAN_TX)
+
static void ifb_setup(struct net_device *dev)
{
/* Initialize the device structure. */
@@ -136,6 +140,9 @@ static void ifb_setup(struct net_device *dev)
ether_setup(dev);
dev->tx_queue_len = TX_Q_LIMIT;
+ dev->features |= IFB_FEATURES;
+ dev->vlan_features |= IFB_FEATURES;
+
dev->flags |= IFF_NOARP;
dev->flags &= ~IFF_MULTICAST;
dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
^ permalink raw reply related
* Re: [RFC PATCH 0/3] Simplified 16 bit Toeplitz hash algorithm
From: Ben Hutchings @ 2011-01-03 20:15 UTC (permalink / raw)
To: Alexander Duyck; +Cc: David Miller, therbert@google.com, netdev@vger.kernel.org
In-Reply-To: <4D2228E0.9030908@intel.com>
On Mon, 2011-01-03 at 11:52 -0800, Alexander Duyck wrote:
> On 1/3/2011 11:30 AM, Ben Hutchings wrote:
> > On Mon, 2011-01-03 at 11:02 -0800, David Miller wrote:
> >> From: Tom Herbert<therbert@google.com>
> >> Date: Mon, 3 Jan 2011 10:47:20 -0800
> >>
> >>> I'm not sure why this would be needed. What is the a advantage in
> >>> making the TX and RX queues match?
> >>
> >> That's how their hardware based RFS essentially works.
> >>
> >> Instead of watching for "I/O system calls" like we do in software, the
> >> chip watches for which TX queue a flow ends up on and matches things
> >> up on the receive side with the same numbered RX queue to match.
> >
> > ixgbe also implements IRQ affinity setting (or rather hinting) and TX
> > queue selection by CPU, the inverse of IRQ affinity setting. Together
> > with the hardware/firmware Flow Director feature, this should indeed
> > result in hardware RFS. (However, irqbalanced does not yet follow the
> > affinity hints AFAIK, so this requires some manual intervention. Maybe
> > the OOT driver is different?)
> >
> > The proposed change to make TX queue selection hash-based seems to be a
> > step backwards.
> >
> > Ben.
> >
>
> Actually this code would only be applied in the case where Flow Director
> didn't apply such as non-TCP frames. It would essentially guarantee
> that we end up with TX/RX on the same CPU for all cases instead of just
> when Flow Director matches a given flow.
The code you posted doesn't seem to implement that, though.
> The general idea is to at least keep the traffic local to one TX/RX
> queue pair so that if we cannot match the queue pair to the application,
> perhaps the application can be affinitized to match up with the queue
> pair. Otherwise we end up with traffic getting routed to one TX queue
> on one CPU, and the RX being routed to another queue on perhaps a
> different CPU and it becomes quite difficult to match up the queues and
> the applications.
Right. That certainly seems like a Good Thing, though I believe it can
be implemented generically by recording the RX queue number on the
socket:
http://article.gmane.org/gmane.linux.network/158477
> Since the approach is based on Toeplitz it can be applied to all
> hardware capable of generating a Toeplitz based hash and as a result it
> would likely also work in a much more vendor neutral kind of way than
> Flow Director currently does.
Which I appreciate, but I'm not convinced that weakening Toeplitz is a
good way to do it.
I understand that Robert Watson (FreeBSD hacker) has been doing some
research on the security and performance implications of flow hashing
algorithms, though I haven't seen any results of that yet.
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] sch_red: report backlog information
From: David Miller @ 2011-01-03 20:13 UTC (permalink / raw)
To: eric.dumazet; +Cc: hadi, jarkao2, hawk, kaber, netdev
In-Reply-To: <1294078298.2892.1111.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 03 Jan 2011 19:11:38 +0100
> Provide child qdisc backlog (byte count) information so that "tc -s
> qdisc" can report it to user.
>
> packet count is already correctly provided.
>
> qdisc red 11: parent 1:11 limit 60Kb min 15Kb max 45Kb ecn
> Sent 3116427684 bytes 1415782 pkt (dropped 8, overlimits 7866 requeues 0)
> rate 242385Kbit 13630pps backlog 13560b 8p requeues 0
> marked 7865 early 1 pdrop 7 other 0
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] net: bridge: check the length of skb after nf_bridge_maybe_copy_header()
From: David Miller @ 2011-01-03 20:13 UTC (permalink / raw)
To: shemminger; +Cc: xiaosuo, bridge, netdev
In-Reply-To: <20110103101533.3f98b311@nehalam>
From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Mon, 3 Jan 2011 10:15:33 -0800
> On Mon, 03 Jan 2011 09:22:14 -0800 (PST)
> David Miller <davem@davemloft.net> wrote:
>
>> From: Changli Gao <xiaosuo@gmail.com>
>> Date: Mon, 3 Jan 2011 18:44:59 +0800
>>
>> > On Sat, Jan 1, 2011 at 3:10 AM, David Miller <davem@davemloft.net> wrote:
>> >> From: Changli Gao <xiaosuo@gmail.com>
>> >> Date: Sat, 25 Dec 2010 21:41:30 +0800
>> >>
>> >>> Since nf_bridge_maybe_copy_header() may change the length of skb,
>> >>> we should check the length of skb after it to handle the ppoe skbs.
>> >>>
>> >>> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
>> >>
>> >> This is really strange.
>> >>
>> >> packet_length() subtracts VLAN_HLEN from the value it returns, so the
>> >> correct fix seems to be to make this function handle the PPPOE case
>> >> too.
>> >>
>> >
>> > It is correct. The actual MTU of 802.1q frame is 4 bytes larger. For
>> > example, the MTU of ethernet is normally 1500, however the actual MTU
>> > of the 802.1Q is 1504.
>>
>> Yes, I understand this, but I don't see why packet_length() cannot
>> simply account for PPPOE's encapsulation overhead just as it does for
>> VLAN's special MTU considerations.
>
> Because PPPOE happens afterwards and is not part the calculation.
> The check should be moved until after skb has reached final form.
That works for me.
^ permalink raw reply
* Re: [PATCH, second try] Typo in comments in include/linux/igmp.h
From: David Miller @ 2011-01-03 20:11 UTC (permalink / raw)
To: fx.lebail; +Cc: netdev
In-Reply-To: <542376.97776.qm@web62505.mail.re1.yahoo.com>
From: François-Xavier Le Bail <fx.lebail@yahoo.com>
Date: Mon, 3 Jan 2011 08:03:36 -0800 (PST)
> [Second try, patch invalid, sorry]
You need to provide a proper "Signed-off-by: " tag in your commit
message.
Please read Documentation/SubmittingPatches and resubmit your patch.
^ permalink raw reply
* Re: [PATCH 1/1] bridge: stp: ensure mac header is set
From: David Miller @ 2011-01-03 20:10 UTC (permalink / raw)
To: fw; +Cc: netdev, acme
In-Reply-To: <1294064188-17722-1-git-send-email-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Mon, 3 Jan 2011 15:16:28 +0100
> commit bf9ae5386bca8836c16e69ab8fdbe46767d7452a
> (llc: use dev_hard_header) removed the
> skb_reset_mac_header call from llc_mac_hdr_init.
>
> This seems fine itself, but br_send_bpdu() invokes ebtables LOCAL_OUT.
>
> We oops in ebt_basic_match() because it assumes eth_hdr(skb) returns
> a meaningful result.
>
> Cc: acme@ghostprotocols.net
> References: https://bugzilla.kernel.org/show_bug.cgi?id=24532
> Signed-off-by: Florian Westphal <fw@strlen.de>
Applied and queued up for -stable, thanks Florian.
^ permalink raw reply
* Re: [PATCH] ll_temac: Fix section mismatch from the temac_of_probe
From: David Miller @ 2011-01-03 20:07 UTC (permalink / raw)
To: grant.likely; +Cc: monstr, netdev, linux-kernel, devicetree-discuss
In-Reply-To: <20110103170332.GB2522@angua.secretlab.ca>
From: Grant Likely <grant.likely@secretlab.ca>
Date: Mon, 3 Jan 2011 10:03:32 -0700
> On Mon, Jan 03, 2011 at 11:32:36AM +0100, Michal Simek wrote:
>> Replace __init by __devinit.
>>
>> Warning message:
>> WARNING: vmlinux.o(.data+0xbc14): Section mismatch in reference from the variable
>> temac_of_driver to the function .init.text:temac_of_probe()
>> The variable temac_of_driver references
>> the function __init temac_of_probe()
>> If the reference is valid then annotate the
>> variable with __init* or __refdata (see linux/init.h) or name the variable:
>> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
>>
>> Signed-off-by: Michal Simek <monstr@monstr.eu>
>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH] trivial: Fix typo fault in netdevice.h
From: David Miller @ 2011-01-03 20:06 UTC (permalink / raw)
To: monstr; +Cc: linux-kernel, netdev
In-Reply-To: <1294044849-10601-1-git-send-email-monstr@monstr.eu>
From: Michal Simek <monstr@monstr.eu>
Date: Mon, 3 Jan 2011 09:54:09 +0100
> Signed-off-by: Michal Simek <monstr@monstr.eu>
Applied.
^ permalink raw reply
* Re: [Bonding-devel] [PATCH net-next-2.6] bonding: remove meaningless /sys/module/bonding/parameters entries.
From: Nicolas de Pesloüan @ 2011-01-03 19:59 UTC (permalink / raw)
To: David Miller; +Cc: netdev, fubar, bonding-devel
In-Reply-To: <20110103.113212.260088613.davem@davemloft.net>
Le 03/01/2011 20:32, David Miller a écrit :
> From: Nicolas de Pesloüan<nicolas.2p.debian@free.fr>
> Date: Sun, 2 Jan 2011 15:35:15 +0100
>
>> Only two bonding parameters are exposed in /sys/module/bonding:
>>
>> num_grat_arp
>> num_unsol_na
>>
>> Those values are not module global, but per device.
>>
>> The per device values are available in /sys/class/net/<device>/bonding.
>>
>> The values exposed in /sys/module/bonding are those given at module load time
>> and only used as default values when creating a device. They are read-only and
>> cannot change in any way.
>>
>> As such, they are mostly meaningless.
>
> First, you forgot to provide a proper "Signed-off-by: " line in your
> patch submission, please read Documentation/SubmittingPatches
Oups, you are right. I forgot it.
> Secondly, you can't remove these, people might be using them. It
> could be useful, for example, to debug problems with passing module
> parameters in. This is the one way to find out what actually got
> passed to the module when it loaded.
I perfectly understand this.
The bonding module supports 19 different parameters, but only two are exposed into
/sys/modules/bonding. Also, only one of those parameters is global to the module (max_bonds). All
other parameters are in fact per device and exposed (read and write if appropriate) in
/sys/class/net/<device>/bonding.
As there is no good reason to have only those two parameters exposed into /sys/modules/bonding, we
should remove them or add all the other one. Due to the lack of real global meaning for those two, I
thought removing them was the right option.
> Therefore I'm not applying this patch, sorry.
Anyway, thanks.
Nicolas.
^ permalink raw reply
* Re: [PATCHv2 0/2]netxen: updates
From: David Miller @ 2011-01-03 19:57 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman, anirban.chakraborty
In-Reply-To: <1294041525-15553-1-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Sun, 2 Jan 2011 23:58:43 -0800
>
> Hi,
> Series v2 of 2 patches to fix LRO in netxen nic driver. Apply these on
> net-next branch.
Both applied, thanks.
^ permalink raw reply
* Re: [RFC PATCH 0/3] Simplified 16 bit Toeplitz hash algorithm
From: David Miller @ 2011-01-03 19:54 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: bhutchings, therbert, netdev
In-Reply-To: <4D2228E0.9030908@intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Mon, 03 Jan 2011 11:52:00 -0800
> Since the approach is based on Toeplitz it can be applied to all
> hardware capable of generating a Toeplitz based hash and as a result
> it would likely also work in a much more vendor neutral kind of way
> than Flow Director currently does.
Immediately this excludes NIU, for one, since it does not use Topelitz.
^ permalink raw reply
* Re: [PATCH] smsc-ircc2: Fix section mismatch derived from smsc_ircc_pnp_driver variable
From: David Miller @ 2011-01-03 19:53 UTC (permalink / raw)
To: sedat.dilek; +Cc: samuel, netdev, linux-kernel, sedat.dilek
In-Reply-To: <1294021724-30337-1-git-send-email-sedat.dilek@gmail.com>
From: Sedat Dilek <sedat.dilek@googlemail.com>
Date: Mon, 3 Jan 2011 03:28:44 +0100
>>From my build.log:
>
> drivers/net/irda/smsc-ircc2.o(.data+0x18): Section mismatch in reference from the variable smsc_ircc_pnp_driver to the function .init.text:smsc_ircc_pnp_probe()
> The variable smsc_ircc_pnp_driver references
> the function __init smsc_ircc_pnp_probe()
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
>
> This patch fixes the warning.
>
> Tested with linux-next (next-20101231)
>
> Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com>
Just like your other patch, this fix is not correct.
Mark smsc_ircc_pbp_probe() as __devinit instead of __init to fix
this bug.
^ permalink raw reply
* Re: [PATCH] depca: Fix section mismatch derived from depca_isa_driver variable
From: David Miller @ 2011-01-03 19:53 UTC (permalink / raw)
To: sedat.dilek; +Cc: netdev, linux-kernel, sedat.dilek
In-Reply-To: <1294021987-30385-1-git-send-email-sedat.dilek@gmail.com>
From: Sedat Dilek <sedat.dilek@googlemail.com>
Date: Mon, 3 Jan 2011 03:33:07 +0100
>>From my build.log:
>
> WARNING: drivers/net/depca.o(.data+0x0): Section mismatch in reference from the variable depca_isa_driver to the function .init.text:depca_isa_probe()
> The variable depca_isa_driver references
> the function __init depca_isa_probe()
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
>
> This patch fixes the warning.
>
> Tested with linux-next (next-20101231)
>
> Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com>
Again, mark depca_isa_probe() as __devinit to fix this bug.
^ permalink raw reply
* Re: [PATCH] ksz884x: Fix section mismatch derived from pci_device_driver variable
From: David Miller @ 2011-01-03 19:52 UTC (permalink / raw)
To: sedat.dilek; +Cc: netdev, linux-kernel, sedat.dilek
In-Reply-To: <1294020104-17124-1-git-send-email-sedat.dilek@gmail.com>
From: Sedat Dilek <sedat.dilek@googlemail.com>
Date: Mon, 3 Jan 2011 03:01:44 +0100
> WARNING: drivers/net/ksz884x.o(.data+0x18): Section mismatch in reference from the variable pci_device_driver to the function .init.text:pcidev_init()
> The variable pci_device_driver references
> the function __init pcidev_init()
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
>
> This patch fixes the warning.
>
> Tested with linux-next (next-20101231)
>
> Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com>
pcidev_init() should be marked __devinit instead of __init to fix this
bug.
^ permalink raw reply
* Re: [RFC PATCH 0/3] Simplified 16 bit Toeplitz hash algorithm
From: Alexander Duyck @ 2011-01-03 19:52 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, therbert@google.com, netdev@vger.kernel.org
In-Reply-To: <1294083039.3167.184.camel@localhost>
On 1/3/2011 11:30 AM, Ben Hutchings wrote:
> On Mon, 2011-01-03 at 11:02 -0800, David Miller wrote:
>> From: Tom Herbert<therbert@google.com>
>> Date: Mon, 3 Jan 2011 10:47:20 -0800
>>
>>> I'm not sure why this would be needed. What is the a advantage in
>>> making the TX and RX queues match?
>>
>> That's how their hardware based RFS essentially works.
>>
>> Instead of watching for "I/O system calls" like we do in software, the
>> chip watches for which TX queue a flow ends up on and matches things
>> up on the receive side with the same numbered RX queue to match.
>
> ixgbe also implements IRQ affinity setting (or rather hinting) and TX
> queue selection by CPU, the inverse of IRQ affinity setting. Together
> with the hardware/firmware Flow Director feature, this should indeed
> result in hardware RFS. (However, irqbalanced does not yet follow the
> affinity hints AFAIK, so this requires some manual intervention. Maybe
> the OOT driver is different?)
>
> The proposed change to make TX queue selection hash-based seems to be a
> step backwards.
>
> Ben.
>
Actually this code would only be applied in the case where Flow Director
didn't apply such as non-TCP frames. It would essentially guarantee
that we end up with TX/RX on the same CPU for all cases instead of just
when Flow Director matches a given flow.
The general idea is to at least keep the traffic local to one TX/RX
queue pair so that if we cannot match the queue pair to the application,
perhaps the application can be affinitized to match up with the queue
pair. Otherwise we end up with traffic getting routed to one TX queue
on one CPU, and the RX being routed to another queue on perhaps a
different CPU and it becomes quite difficult to match up the queues and
the applications.
Since the approach is based on Toeplitz it can be applied to all
hardware capable of generating a Toeplitz based hash and as a result it
would likely also work in a much more vendor neutral kind of way than
Flow Director currently does.
Thanks,
Alex
^ permalink raw reply
* Re: [PATCH v2 net-next-2.6] ifb: add performance flags
From: David Miller @ 2011-01-03 19:40 UTC (permalink / raw)
To: jarkao2; +Cc: eric.dumazet, xiaosuo, pstaszewski, netdev
In-Reply-To: <20110103193703.GA1977@del.dom.local>
From: Jarek Poplawski <jarkao2@gmail.com>
Date: Mon, 3 Jan 2011 20:37:03 +0100
> On Sun, Jan 02, 2011 at 09:24:36PM +0100, Eric Dumazet wrote:
>> Le mercredi 29 décembre 2010 ?? 00:07 +0100, Jarek Poplawski a écrit :
>>
>> > Ingress is before vlans handler so these features and the
>> > NETIF_F_HW_VLAN_TX flag seem useful for ifb considering
>> > dev_hard_start_xmit() checks.
>>
>> OK, here is v2 of the patch then, thanks everybody.
>>
>>
>> [PATCH v2 net-next-2.6] ifb: add performance flags
>>
>> IFB can use the full set of features flags (NETIF_F_SG |
>> NETIF_F_FRAGLIST | NETIF_F_TSO | NETIF_F_NO_CSUM | NETIF_F_HIGHDMA) to
>> avoid unnecessary split of some packets (GRO for example)
>>
>> Changli suggested to also set vlan_features,
>
> He also suggested more GSO flags of which especially NETIF_F_TSO6
> seems interesting (wrt GRO)?
I think at least TSO6 would very much be appropriate here.
^ permalink raw reply
* Re: [PATCH] net: eepro testing positive EBUSY return by request_irq()?
From: David Miller @ 2011-01-03 19:37 UTC (permalink / raw)
To: roel.kluin; +Cc: ben, netdev, akpm, linux-kernel
In-Reply-To: <4D209127.5080505@gmail.com>
From: roel kluin <roel.kluin@gmail.com>
Date: Sun, 02 Jan 2011 15:52:23 +0100
> + for (i = 0; i < ARRAY_SIZE(irqlist); i++) {
> + retval = request_irq (irqlist[i], NULL, 0, "bogus", NULL);
> + if (retval != -EBUSY)
> + continue;
> + if (retval < 0)
> + goto out;
> + dev->irq = irqlist[i];
> + break;
This series of tests don't make much sense.
If we get to the "retval < 0" check, retval must be -EBUSY. So at
best it's superfluous, at worst it's confusing.
^ permalink raw reply
* Re: [PATCH v2 net-next-2.6] ifb: add performance flags
From: Jarek Poplawski @ 2011-01-03 19:37 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, xiaosuo, pstaszewski, netdev
In-Reply-To: <1293999876.2535.211.camel@edumazet-laptop>
On Sun, Jan 02, 2011 at 09:24:36PM +0100, Eric Dumazet wrote:
> Le mercredi 29 décembre 2010 ?? 00:07 +0100, Jarek Poplawski a écrit :
>
> > Ingress is before vlans handler so these features and the
> > NETIF_F_HW_VLAN_TX flag seem useful for ifb considering
> > dev_hard_start_xmit() checks.
>
> OK, here is v2 of the patch then, thanks everybody.
>
>
> [PATCH v2 net-next-2.6] ifb: add performance flags
>
> IFB can use the full set of features flags (NETIF_F_SG |
> NETIF_F_FRAGLIST | NETIF_F_TSO | NETIF_F_NO_CSUM | NETIF_F_HIGHDMA) to
> avoid unnecessary split of some packets (GRO for example)
>
> Changli suggested to also set vlan_features,
He also suggested more GSO flags of which especially NETIF_F_TSO6
seems interesting (wrt GRO)?
Jarek P.
> Jarek suggested to add NETIF_F_HW_VLAN_TX as well.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Changli Gao <xiaosuo@gmail.com>
> Cc: Jarek Poplawski <jarkao2@gmail.com>
> Cc: Pawel Staszewski <pstaszewski@itcare.pl>
> ---
> drivers/net/ifb.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/net/ifb.c b/drivers/net/ifb.c
> index 124dac4..66ca7bf 100644
> --- a/drivers/net/ifb.c
> +++ b/drivers/net/ifb.c
> @@ -126,6 +126,9 @@ static const struct net_device_ops ifb_netdev_ops = {
> .ndo_validate_addr = eth_validate_addr,
> };
>
> +#define IFB_FEATURES (NETIF_F_NO_CSUM | NETIF_F_SG | NETIF_F_FRAGLIST | \
> + NETIF_F_HIGHDMA | NETIF_F_TSO | NETIF_F_HW_VLAN_TX)
> +
> static void ifb_setup(struct net_device *dev)
> {
> /* Initialize the device structure. */
> @@ -136,6 +139,9 @@ static void ifb_setup(struct net_device *dev)
> ether_setup(dev);
> dev->tx_queue_len = TX_Q_LIMIT;
>
> + dev->features |= IFB_FEATURES;
> + dev->vlan_features |= IFB_FEATURES;
> +
> dev->flags |= IFF_NOARP;
> dev->flags &= ~IFF_MULTICAST;
> dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
>
>
^ 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