* Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver
From: Urs Thuermann @ 2007-09-25 14:00 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / È£ÑÀ
Cc: netdev, davem, kaber, joe, tglx, oliver, oliver.hartkopp
In-Reply-To: <20070925.222631.116063075.yoshfuji@linux-ipv6.org>
YOSHIFUJI Hideaki / È£ÑÀ <yoshfuji@linux-ipv6.org> writes:
> I'm not a lawyer, but the following lines:
>
> | + * Alternatively, provided that this notice is retained in full, this
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> | + * software may be distributed under the terms of the GNU General
> | + * Public License ("GPL") version 2 as distributed in the 'COPYING'
> | + * file from the main directory of the linux kernel source.
>
> make this whole licence imcompatible with GPL.
I'm no lawyer at all, either. And also Oliver is not, but he has
carried out the fights with our company lawyers. Maybe he can say
something about whether we can change this.
> I do think you need to allow people to select GPLv2 only.
The sentence you cite *does* allow distribution under GPLv2 only. And
I think I have often read the restriction to retain such licences in
full in GPLv2 code. Is that really incompatible?
urs
^ permalink raw reply
* Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver
From: Patrick McHardy @ 2007-09-25 14:47 UTC (permalink / raw)
To: Urs Thuermann
Cc: YOSHIFUJI Hideaki / È£ÑÀ, netdev, davem, joe,
tglx, oliver, oliver.hartkopp
In-Reply-To: <ygfir5yetfp.fsf@janus.isnogud.escape.de>
Urs Thuermann wrote:
> YOSHIFUJI Hideaki / È£ÑÀ <yoshfuji@linux-ipv6.org> writes:
>
>
>>I'm not a lawyer, but the following lines:
>>
>>| + * Alternatively, provided that this notice is retained in full, this
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>| + * software may be distributed under the terms of the GNU General
>>| + * Public License ("GPL") version 2 as distributed in the 'COPYING'
>>| + * file from the main directory of the linux kernel source.
>>
>>make this whole licence imcompatible with GPL.
>
>
> I'm no lawyer at all, either. And also Oliver is not, but he has
> carried out the fights with our company lawyers. Maybe he can say
> something about whether we can change this.
>
>
>>I do think you need to allow people to select GPLv2 only.
>
>
> The sentence you cite *does* allow distribution under GPLv2 only. And
> I think I have often read the restriction to retain such licences in
> full in GPLv2 code. Is that really incompatible?
Not that it necessarily means its valid, but there are multiple
files in the kernel that carry the exact same term:
arch/x86_64/crypto/aes.c
arch/i386/crypto/aes.c
crypto/gf128mul.c
crypto/aes.c
drivers/net/ppp_mppe.c
drivers/crypto/padlock-aes.c
include/crypto/b128ops.h
include/crypto/gf128mul.h
OTOH I tend to agree with Yoshifuji that once someone has
selected the GPL and has made enough changes that no parts
"can be reasonably considered independent and separate works",
it seems like an additional and confusing restriction to be
forced to retain ineffective licensing terms.
But since I'm not a lawyer either I'm going to refrain from
further speculation :)
^ permalink raw reply
* Re: [PATCH V6 0/9] net/bonding: ADD IPoIB support for the bonding driver
From: Jay Vosburgh @ 2007-09-25 15:24 UTC (permalink / raw)
To: Moni Shoua; +Cc: Roland Dreier, netdev, OpenFabrics General, Jeff Garzik
In-Reply-To: <46F7D770.4090500@voltaire.com>
ACK patches 3 - 9.
Roland, are you comfortable with the IB changes in patches 1 and 2?
Jeff, when Roland acks patches 1 and 2, please apply all 9.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
Moni Shoua <monis@voltaire.com> wrote:
>This patch series is the sixth version (see below link to V5) of the
>suggested changes to the bonding driver so it would be able to support
>non ARPHRD_ETHER netdevices for its High-Availability (active-backup) mode.
>
>Patches 1-8 were originally submitted in V5 and patch 9 is an addition by Jay.
>
>
>Major changes from the previous version:
>----------------------------------------
>
>1. Remove the patches to net/core. Bonding will use the NETDEV_GOING_DOWN notification
> instead of NETDEV_CHANGE+IFF_SLAVE_DETACH. This reduces the amount of patches from 11
> to 9.
>
>Links to earlier discussion:
>----------------------------
>
>1. A discussion in netdev about bonding support for IPoIB.
>http://lists.openwall.net/netdev/2006/11/30/46
>
>2. V5 series
>http://lists.openfabrics.org/pipermail/general/2007-September/040996.html
>
>-
>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
* [ofa-general] Re: [PATCH 1/4] [NET_SCHED] explict hold dev tx lock
From: Stephen Hemminger @ 2007-09-25 15:24 UTC (permalink / raw)
To: hadi
Cc: johnpol, kumarkr, herbert, gaagaan, Robert.Olsson, netdev,
rdreier, Waskiewicz Jr, Peter P, mcarlson, kaber, randy.dunlap,
jagana, general, mchan, tgraf, jeff, sri, David Miller
In-Reply-To: <1190726138.4264.105.camel@localhost>
On Tue, 25 Sep 2007 09:15:38 -0400
jamal <hadi@cyberus.ca> wrote:
> On Mon, 2007-24-09 at 17:14 -0700, Stephen Hemminger wrote:
>
> > Since we are redoing this,
> > is there any way to make the whole TX path
> > more lockless? The existing model seems to be more of a monitor than
> > a real locking model.
>
http://en.wikipedia.org/wiki/Monitor_(synchronization)
> What do you mean it is "more of a monitor"?
The transmit code path is locked as a code region, rather than just object locking
on the transmit queue or other fine grained object. This leads to moderately long
lock hold times when multiple qdisc's and classification is being done.
>
> On the challenge of making it lockless:
> About every NAPI driver combines the tx prunning with rx polling. If you
> are dealing with tx resources on receive thread as well as tx thread,
> _you need_ locking. The only other way we can do avoid it is to separate
> the rx path interupts from ones on tx related resources; the last NAPI
> driver that did that was tulip; i think the e1000 for a short period in
> its life did the same as well. But that has been frowned on and people
> have evolved away from it.
If we went to finer grain locking it would also mean changes to all network
devices using the new locking model. My assumption is that we would use
something like the features flag to do the transition for backward compatibility.
Take this as a purely "what if" or "it would be nice if" kind of suggestion
not a requirement or some grand plan.
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: [PATCH 2/7] CAN: Add PF_CAN core module
From: Stephen Hemminger @ 2007-09-25 15:33 UTC (permalink / raw)
To: Urs Thuermann
Cc: Arnaldo Carvalho de Melo, netdev, David Miller, Patrick McHardy,
Joe Perches, Thomas Gleixner, Oliver Hartkopp, Oliver Hartkopp
In-Reply-To: <ygfr6kmev3i.fsf@janus.isnogud.escape.de>
On 25 Sep 2007 15:24:33 +0200
Urs Thuermann <urs@isnogud.escape.de> wrote:
> Arnaldo Carvalho de Melo <acme@ghostprotocols.net> writes:
>
> > > + skb_queue_purge(&sk->sk_receive_queue);
> > > + if (sk->sk_protinfo)
> > > + kfree(sk->sk_protinfo);
> > > +}
> >
> > Is it really needed to do this sk_protinfo check?
>
> Thanks for finding this. This is from 2.6.12 times or so. We have
> other CAN protocol (which we are not allowed to put under GPL)
> implemenatations which still use the protinfo field. But we should
> change those and I will delete this check.
>
> urs
Then please make all exported symbols marked EXPORT_SYMBOL_GPL to make
sure that the other CAN protocol can not reuse your infrastructure.
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: [PATCH: 2.6.13-15-SMP 3/3] network: concurrently runsoftirqnetwork code on SMP
From: john ye @ 2007-09-25 15:36 UTC (permalink / raw)
To: hadi
Cc: David Miller, netdev, kuznet, pekkas, jmorris, kaber, iceburgue,
John Ye
In-Reply-To: <1190551422.4256.36.camel@localhost>
Jamal,
You pointed out a key point: it's NOT acceptable if massive packet re-ordering couldn¡¯t be avoided.
I debugged function tcp_ofo_queue in net/ipv4/tcp_input.c & monitored out_of_order_queue, found that re-ordering
becomes unacceptable with the softirq load grows.
It's simple to avoid out-of-order packets by changing random dispatch into dispatch based on source ip address.
e.g. cpu = iph->saddr % nr_cpus. while cpu is like a hash entry.
Considering that BS patch is mainly used on server with many incoming connections,
dispatch by IP should balance CPU load well.
The test is under way, it's not bad so far.
The queue spin_lock seems not cost much.
Below is the bcpp beautified module code. Last time code mess is caused by outlook express which killed tabs.
Thanks.
John Ye
/*
* BOTTOM_SOFTIRQ_NET
* An implementation of bottom softirq concurrent execution on SMP
* This is implemented by splitting current net softirq into top half
* and bottom half, dispatch the bottom half to each cpu's workqueue.
* Hopefully, it can raise the throughput of NIC when running iptalbes
* on SMP machine.
*
* Version: $Id: bs_smp.c, v 2.6.13-15 for kernel 2.6.13-15-smp
*
* Authors: John Ye & QianYu Ye, 2007.08.27
*/
#include <asm/debugreg.h>
#include <asm/desc.h>
#include <asm/i387.h>
#include <asm/ldt.h>
#include <asm/pgtable.h>
#include <asm/processor.h>
#include <asm/system.h>
#include <asm/uaccess.h>
#include <asm/unaligned.h>
#include <linux/aio.h>
#include <linux/backing-dev.h>
#include <linux/bio.h>
#include <linux/buffer_head.h>
#include <linux/config.h>
#include <linux/delay.h>
#include <linux/devfs_fs_kernel.h>
#include <linux/device.h>
#include <linux/errno.h>
#include <linux/etherdevice.h>
#include <linux/fs.h>
#include <linux/highmem.h>
#include <linux/in.h>
#include <linux/inet.h>
#include <linux/inetdevice.h>
#include <linux/init.h>
#include <linux/input.h>
#include <linux/interrupt.h>
#include <linux/ipsec.h>
#include <linux/kernel.h>
#include <linux/kmod.h>
#include <linux/list.h>
#include <linux/major.h>
#include <linux/mm.h>
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/mroute.h>
#include <linux/net.h>
#include <linux/netdevice.h>
#include <linux/netfilter_ipv4.h>
#include <linux/netlink.h>
#include <linux/pagemap.h>
#include <linux/pm.h>
#include <linux/poll.h>
#include <linux/proc_fs.h>
#include <linux/ptrace.h>
#include <linux/random.h>
#include <linux/romfs_fs.h>
#include <linux/sched.h>
#include <linux/security.h>
#include <linux/skbuff.h>
#include <linux/slab.h>
#include <linux/smp.h>
#include <linux/smp_lock.h>
#include <linux/socket.h>
#include <linux/sockios.h>
#include <linux/string.h>
#include <linux/swap.h>
#include <linux/sysctl.h>
#include <linux/types.h>
#include <linux/user.h>
#include <linux/vfs.h>
#include <linux/workqueue.h>
#include <net/arp.h>
#include <net/checksum.h>
#include <net/icmp.h>
#include <net/inet_common.h>
#include <net/ip.h>
#include <net/protocol.h>
#include <net/raw.h>
#include <net/route.h>
#include <net/snmp.h>
#include <net/sock.h>
#include <net/tcp.h>
#include <net/xfrm.h>
static spinlock_t *p_ptype_lock;
static struct list_head *p_ptype_base; /* 16 way hashed list */
int (*Pip_options_rcv_srr)(struct sk_buff *skb);
int (*Pnf_rcv_postxfrm_nonlocal)(struct sk_buff *skb);
struct ip_rt_acct *ip_rt_acct;
struct ipv4_devconf *Pipv4_devconf;
#define ipv4_devconf (*Pipv4_devconf)
//#define ip_rt_acct Pip_rt_acct
#define ip_options_rcv_srr Pip_options_rcv_srr
#define nf_rcv_postxfrm_nonlocal Pnf_rcv_postxfrm_nonlocal
//extern int nf_rcv_postxfrm_local(struct sk_buff *skb);
//extern int ip_options_rcv_srr(struct sk_buff *skb);
static struct workqueue_struct **Pkeventd_wq;
#define keventd_wq (*Pkeventd_wq)
#define INSERT_CODE_HERE
static inline int ip_rcv_finish(struct sk_buff *skb)
{
struct net_device *dev = skb->dev;
struct iphdr *iph = skb->nh.iph;
int err;
/*
* Initialise the virtual path cache for the packet. It describes
* how the packet travels inside Linux networking.
*/
if (skb->dst == NULL)
{
if ((err = ip_route_input(skb, iph->daddr, iph->saddr, iph->tos, dev)))
{
if (err == -EHOSTUNREACH)
IP_INC_STATS_BH(IPSTATS_MIB_INADDRERRORS);
goto drop;
}
}
if (nf_xfrm_nonlocal_done(skb))
return nf_rcv_postxfrm_nonlocal(skb);
#ifdef CONFIG_NET_CLS_ROUTE
if (skb->dst->tclassid)
{
struct ip_rt_acct *st = ip_rt_acct + 256*smp_processor_id();
u32 idx = skb->dst->tclassid;
st[idx&0xFF].o_packets++;
st[idx&0xFF].o_bytes+=skb->len;
st[(idx>>16)&0xFF].i_packets++;
st[(idx>>16)&0xFF].i_bytes+=skb->len;
}
#endif
if (iph->ihl > 5)
{
struct ip_options *opt;
/* It looks as overkill, because not all
IP options require packet mangling.
But it is the easiest for now, especially taking
into account that combination of IP options
and running sniffer is extremely rare condition.
--ANK (980813)
*/
if (skb_cow(skb, skb_headroom(skb)))
{
IP_INC_STATS_BH(IPSTATS_MIB_INDISCARDS);
goto drop;
}
iph = skb->nh.iph;
if (ip_options_compile(NULL, skb))
goto inhdr_error;
opt = &(IPCB(skb)->opt);
if (opt->srr)
{
struct in_device *in_dev = in_dev_get(dev);
if (in_dev)
{
if (!IN_DEV_SOURCE_ROUTE(in_dev))
{
if (IN_DEV_LOG_MARTIANS(in_dev) && net_ratelimit())
printk(KERN_INFO "source route option %u.%u.%u.%u -> %u.%u.%u.%u\n",
NIPQUAD(iph->saddr), NIPQUAD(iph->daddr));
in_dev_put(in_dev);
goto drop;
}
in_dev_put(in_dev);
}
if (ip_options_rcv_srr(skb))
goto drop;
}
}
return dst_input(skb);
inhdr_error:
IP_INC_STATS_BH(IPSTATS_MIB_INHDRERRORS);
drop:
kfree_skb(skb);
return NET_RX_DROP;
}
#define CONFIG_BOTTOM_SOFTIRQ_SMP
#define CONFIG_BOTTOM_SOFTIRQ_SMP_SYSCTL
#ifdef CONFIG_BOTTOM_SOFTIRQ_SMP
#ifdef COMMENT____________
/*
[PATCH: 2.6.13-15-SMP 1/2] network: concurrently run softirq network code on SMP
Bottom Softirq Implementation. John Ye, 2007.08.27
Why this patch:
Make kernel be able to concurrently execute softirq's net code on SMP system.
Take full advantages of SMP to handle more packets and greatly raises NIC throughput.
The current kernel's net packet processing logic is:
1) The CPU which handles a hardirq must be executing its related softirq.
2) One softirq instance(irqs handled by 1 CPU) can't be executed on more than 2 CPUs
at the same time.
The limitation make kernel network be hard to take the advantages of SMP.
How this patch:
It splits the current softirq code into 2 parts: the cpu-sensitive top half,
and the cpu-insensitive bottom half, then make bottom half(calld BS) be
executed on SMP concurrently.
The two parts are not equal in terms of size and load. Top part has constant code
size(mainly, in net/core/dev.c and NIC drivers), while bottom part involves
netfilter(iptables) whose load varies very much. An iptalbes with 1000 rules to match
will make the bottom part's load be very high. So, if the bottom part softirq
can be distributed to processors and run concurrently on them, the network will
gain much more packet handling capacity, network throughput will be be increased
remarkably.
Where useful:
It's useful on SMP machines that meet the following 2 conditions:
1) have high kernel network load, for example, running iptables with thousands of rules, etc).
2) have more CPUs than active NICs, e.g. a 4 CPUs machine with 2 NICs).
On these system, with the increase of softirq load, some CPUs will be idle
while others(number is equal to # of NIC) keeps busy.
IRQBALANCE will help, but it only shifts IRQ among CPUS, makes no softirq concurrency.
Balancing the load of each cpus will not remarkably increase network speed.
Where NOT useful:
If the bottom half of softirq is too small(without running iptables), or the network
is too idle, BS patch will not be seen to have visible effect. But It has no
negative affect either.
User can turn on/off BS functionality by /proc/sys/net/bs_enable switch.
How to test:
On a linux box, run iptables, add 2000 rules to table filter & table nat to simulate huge
softirq load. Then, open 20 ftp sessions to download big file. On another machine(who
use this test machine as gateway), open 20 more ftp download sessions. Compare the speed,
without BS enabled, and with BS enabled.
cat /proc/sys/net/bs_enable. this is a switch to turn on/off BS
cat /proc/sys/net/bs_status. this shows the usage of each CPUs
Test shown that when bottom softirq load is high, the network throughput can be nearly
doubled on 2 CPUs machine. hopefully it may be quadrupled on a 4 cpus linux box.
Bugs:
It will NOT allow hotplug CPU.
It only allows incremental CPUs ids, starting from 0 to num_online_cpus().
for example, 0,1,2,3 is OK. 0,1,8,9 is KO.
Some considerations in the future:
1) With BS patch, the irq balance code on arch/i386/kernel/io_apic.c seems no need any more,
at least not for network irq.
2) Softirq load will become very small. It only run the top half of old softirq, which
is much less expensive than bottom half---the netfilter program.
To let top softirq process more packets, can these 3 network parameters be given a larger value?
extern int netdev_max_backlog = 1000;
extern int netdev_budget = 300;
extern int weight_p = 64;
3) Now, BS are running on built-in keventd thread, we can create new workqueues to let it run on?
Signed-off-by: John Ye (Seeker) <johny@asimco.com.cn>
*/
#endif
#define BS_USE_PERCPU_DATA
struct cpu_stat
{
unsigned long irqs; //total irqs
unsigned long dids; //I did,
unsigned long others;
unsigned long works;
};
#define BS_CPU_STAT_DEFINED
static int nr_cpus = 0;
static int bs_enable = 1;
#define BS_POL_SRCIP 1
#define BS_POL_RANDOM 2
static int bs_policy = BS_POL_SRCIP;
// cacheline_aligned_in_smp;
static DEFINE_PER_CPU(struct sk_buff_head, bs_cpu_queues);
static DEFINE_PER_CPU(struct work_struct, bs_works);
//static DEFINE_PER_CPU(struct cpu_stat, bs_cpu_status);
struct cpu_stat bs_cpu_status[NR_CPUS];
static int ip_rcv1(struct sk_buff *skb, struct net_device *dev)
{
return NF_HOOK_COND(PF_INET, NF_IP_PRE_ROUTING, skb, dev, NULL, ip_rcv_finish, nf_hook_input_cond(skb));
}
static void bs_func(void *data)
{
int flags, num, cpu;
struct sk_buff *skb;
struct work_struct *bs_works;
struct sk_buff_head *q;
cpu = smp_processor_id();
bs_works = &per_cpu(bs_works, cpu);
q = &per_cpu(bs_cpu_queues, cpu);
local_bh_disable();
restart:
num = 0;
while(1)
{
spin_lock_irqsave(&q->lock, flags);
skb = __skb_dequeue(q);
spin_unlock_irqrestore(&q->lock, flags);
if(!skb) break;
num++;
/* local_bh_disable(); */
ip_rcv1(skb, skb->dev);
/* __local_bh_enable(); */ // sub_preempt_count(SOFTIRQ_OFFSET - 1);
}
bs_cpu_status[cpu].others += num;
// if(num > 2) printk("%d %d\n", num, cpu);
if(num > 0)
goto restart;
__local_bh_enable();
bs_works->func = 0;
return;
}
/* COPY_IN_START_FROM kernel/workqueue.c */
struct cpu_workqueue_struct
{
spinlock_t lock;
long remove_sequence; /* Least-recently added (next to run) */
long insert_sequence; /* Next to add */
struct list_head worklist;
wait_queue_head_t more_work;
wait_queue_head_t work_done;
struct workqueue_struct *wq;
task_t *thread;
int run_depth; /* Detect run_workqueue() recursion depth */
} ____cacheline_aligned;
struct workqueue_struct
{
struct cpu_workqueue_struct cpu_wq[NR_CPUS];
const char *name;
struct list_head list; /* Empty if single thread */
};
/* COPY_IN_END_FROM kernel/worqueue.c */
extern struct workqueue_struct *keventd_wq;
/* Preempt must be disabled. */
static void __queue_work(struct cpu_workqueue_struct *cwq,
struct work_struct *work)
{
unsigned long flags;
spin_lock_irqsave(&cwq->lock, flags);
work->wq_data = cwq;
list_add_tail(&work->entry, &cwq->worklist);
cwq->insert_sequence++;
wake_up(&cwq->more_work);
spin_unlock_irqrestore(&cwq->lock, flags);
}
#endif //CONFIG_BOTTOM_SOFTIRQ_SMP
/*
* Main IP Receive routine.
*/
/* hard irq are in CPU1, why this get called from CPU0?, __do_IRQ() did so?
*
*/
int REP_ip_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt)
{
struct iphdr *iph;
/* When the interface is in promisc. mode, drop all the crap
* that it receives, do not try to analyse it.
*/
if (skb->pkt_type == PACKET_OTHERHOST)
goto drop;
IP_INC_STATS_BH(IPSTATS_MIB_INRECEIVES);
if ((skb = skb_share_check(skb, GFP_ATOMIC)) == NULL)
{
IP_INC_STATS_BH(IPSTATS_MIB_INDISCARDS);
goto out;
}
if (!pskb_may_pull(skb, sizeof(struct iphdr)))
goto inhdr_error;
iph = skb->nh.iph;
/*
* RFC1122: 3.1.2.2 MUST silently discard any IP frame that fails the checksum.
*
* Is the datagram acceptable?
*
* 1. Length at least the size of an ip header
* 2. Version of 4
* 3. Checksums correctly. [Speed optimisation for later, skip loopback checksums]
* 4. Doesn't have a bogus length
*/
if (iph->ihl < 5 || iph->version != 4)
goto inhdr_error;
if (!pskb_may_pull(skb, iph->ihl*4))
goto inhdr_error;
iph = skb->nh.iph;
if (ip_fast_csum((u8 *)iph, iph->ihl) != 0)
goto inhdr_error;
{
__u32 len = ntohs(iph->tot_len);
if (skb->len < len || len < (iph->ihl<<2))
goto inhdr_error;
/* Our transport medium may have padded the buffer out. Now we know it
* is IP we can trim to the true length of the frame.
* Note this now means skb->len holds ntohs(iph->tot_len).
*/
if (pskb_trim_rcsum(skb, len))
{
IP_INC_STATS_BH(IPSTATS_MIB_INDISCARDS);
goto drop;
}
}
#ifdef CONFIG_BOTTOM_SOFTIRQ_SMP
if(!nr_cpus)
nr_cpus = num_online_cpus();
if(bs_enable && nr_cpus > 1 && iph->protocol != IPPROTO_ICMP)
{
unsigned int flags, cur, cpu;
struct work_struct *bs_works;
struct sk_buff_head *q;
cur = smp_processor_id();
bs_cpu_status[cur].irqs++;
/*
* good point from Jamal. thanks no reordering
*/
if(bs_policy == BS_POL_SRCIP)
cpu = iph->saddr % nr_cpus;
/* random distribute. for speed test */
else if(bs_policy == BS_POL_RANDOM)
cpu = (bs_cpu_status[cur].irqs % nr_cpus);
if(cpu == cur)
{
bs_cpu_status[cpu].dids++;
return ip_rcv1(skb, dev);
}
q = &per_cpu(bs_cpu_queues, cpu);
if(!q->next)
skb_queue_head_init(q);
bs_works = &per_cpu(bs_works, cpu);
spin_lock_irqsave(&q->lock, flags);
__skb_queue_tail(q, skb);
spin_unlock_irqrestore(&q->lock, flags);
if (!bs_works->func)
{
INIT_WORK(bs_works, bs_func, q);
bs_cpu_status[cpu].works++;
preempt_disable();
__queue_work(keventd_wq->cpu_wq + cpu, bs_works);
preempt_enable();
}
}
else
{
int cpu = smp_processor_id();
bs_cpu_status[cpu].irqs++;
bs_cpu_status[cpu].dids++;
return ip_rcv1(skb, dev);
}
return 0;
#else
return NF_HOOK_COND(PF_INET, NF_IP_PRE_ROUTING, skb, dev, NULL, ip_rcv_finish, nf_hook_input_cond(skb));
#endif /* CONFIG_BOTTOM_SOFTIRQ_SMP */
inhdr_error:
IP_INC_STATS_BH(IPSTATS_MIB_INHDRERRORS);
drop:
kfree_skb(skb);
out:
return NET_RX_DROP;
}
/*
* for standard patch, those lines should be moved into ../../net/sysctl_net.c
*/
/* COPY_OUT_START_TO net/sysctl_net.c */
#ifdef CONFIG_BOTTOM_SOFTIRQ_SMP_SYSCTL
#if !defined(BS_CPU_STAT_DEFINED)
struct cpu_stat
{
unsigned long irqs; /* total irqs on me */
unsigned long dids; /* I did, */
unsigned long others; /* other did, */
unsigned long works; /* q works */
};
#endif
extern struct cpu_stat bs_cpu_status[NR_CPUS];
extern int bs_enable;
/* COPY_OUT_END_TO net/sysctl_net.c */
static ctl_table bs_ctl_table[] =
{
/* COPY_OUT_START_TO net/sysctl_net.c */
{
.ctl_name = 99,
.procname = "bs_status",
.data = &bs_cpu_status,
.maxlen = sizeof(bs_cpu_status),
.mode = 0644,
.proc_handler = &proc_dointvec,
},
{
.ctl_name = 99,
.procname = "bs_policy",
.data = &bs_policy,
.maxlen = sizeof(int),
.mode = 0644,
.proc_handler = &proc_dointvec,
},
{
.ctl_name = 99,
.procname = "bs_enable",
.data = &bs_enable,
.maxlen = sizeof(int),
.mode = 0644,
.proc_handler = &proc_dointvec,
},
/* COPY_OUT_END_TO net/net_sysctl.c */
{ 0, },
};
static ctl_table bs_sysctl_root[] =
{
{
.ctl_name = CTL_NET,
.procname = "net",
.mode = 0555,
.child = bs_ctl_table,
},
{ 0, },
};
struct ctl_table_header *bs_sysctl_hdr;
register_bs_sysctl(void)
{
bs_sysctl_hdr = register_sysctl_table(bs_sysctl_root, 0);
return 0;
}
unregister_bs_sysctl(void)
{
unregister_sysctl_table(bs_sysctl_hdr);
}
#endif //CONFIG_BOTTOM_SOFTIRQ_SMP_SYSCTL
seeker_init()
{
int i;
if(nr_cpus == 0)
nr_cpus = num_online_cpus();
register_bs_sysctl();
}
seeker_exit()
{
unsigned long now;
unregister_bs_sysctl();
bs_enable = 0;
msleep(1000);
flush_scheduled_work();
now = jiffies;
msleep(1000);
printk("%u exited.\n", jiffies - now);
}
/*--------------------------------------------------------------------------
*/
struct packet_type *dev_find_pack(int type)
{
struct list_head *head;
struct packet_type *pt1;
spin_lock_bh(p_ptype_lock);
head = &p_ptype_base[type & 15];
list_for_each_entry(pt1, head, list)
{
if (pt1->type == htons(type))
{
goto out;
}
}
pt1 = 0;
printk( "ERROR: dev_remove_pack: %p not found. type %x %x %x\n", pt1, type, ETH_P_IP, htons(ETH_P_IP));
out:
spin_unlock_bh(p_ptype_lock);
return pt1;
}
static char system_map[128] = "/boot/System.map-";
static unsigned long sysmap_size;
static char *sysmap_buf;
unsigned long sysmap_name2addr(char *name)
{
char *cp, *dp;
unsigned long addr;
int len, n;
if(!sysmap_buf) return 0;
if(!name || !name[0]) return 0;
n = strlen(name);
for(cp = sysmap_buf; ;)
{
cp = strstr(cp, name);
if(!cp) return 0;
for(dp = cp; *dp && *dp != '\n' && *dp != ' ' && *dp != '\t'; dp++);
len = dp - cp;
if(len < n) goto cont;
if(cp > sysmap_buf && cp[-1] != ' ' && cp[-1] != '\t')
{
goto cont;
}
if(len > n)
{
goto cont;
}
break;
cont:
if(*dp == 0) break;
cp += (len+1);
}
cp -= 11;
if(cp > sysmap_buf && cp[-1] != '\n')
{
printk("_ERROR_ in name2addr cp = %p base %p\n", cp, sysmap_buf);
return 0;
}
sscanf(cp, "%x", &addr);
return addr;
}
static int kas_init()
{
struct file *fp;
int i;
long addr;
struct kstat st;
mm_segment_t old_fs;
strcat(system_map, system_utsname.release);
old_fs = get_fs();
set_fs(get_ds()); /* systemp_map is __user variable */
i = vfs_stat(system_map, &st);
set_fs(old_fs);
if(i) return 1;
sysmap_size = st.size + 32;
fp = filp_open(system_map, O_RDONLY, FMODE_READ);
if(!fp) return 1;
sysmap_buf = vmalloc(sysmap_size);
if(!sysmap_buf) return 2;
i = kernel_read(fp, 0, sysmap_buf, sysmap_size);
if(i <= 0)
{
filp_close(fp, 0);
vfree(sysmap_buf);
sysmap_buf = 0;
return 3;
}
sysmap_size = i;
*(int*)&sysmap_buf[i] = 0;
filp_close(fp, 0);
p_ptype_lock = sysmap_name2addr("ptype_lock");
p_ptype_base = sysmap_name2addr("ptype_base");
Pkeventd_wq = sysmap_name2addr("keventd_wq");
Pip_options_rcv_srr = sysmap_name2addr("ip_options_rcv_srr");
Pnf_rcv_postxfrm_nonlocal = sysmap_name2addr("nf_rcv_postxfrm_nonlocal");
ip_rt_acct = sysmap_name2addr("ip_rt_acct");
Pipv4_devconf = sysmap_name2addr("ipv4_devconf");
vfree(sysmap_buf);
return 0;
}
struct packet_type *ip_handler;
static int __init init()
{
struct packet_type *pt;
if(kas_init())
return -1;
pt = dev_find_pack(ETH_P_IP);
if(!pt)
return -1;
/*printk("pt %p func ip_rcv %p should be %p\n", pt, pt->func, ip_rcv);
*/
lock_kernel();
if(pt->func == ip_rcv)
{
pt->func = REP_ip_rcv;
ip_handler = pt;
}
else
{
printk("error: can't find handler.\n");
ip_handler = pt;
unlock_kernel();
return -1;
}
unlock_kernel();
seeker_init();
return 0;
}
static void __exit exit(void)
{
seeker_exit();
lock_kernel();
if(ip_handler->func == REP_ip_rcv)
ip_handler->func = ip_rcv;
else
printk("error...\n");
unlock_kernel();
}
module_init(init)
module_exit(exit)
MODULE_LICENSE("GPL");
^ permalink raw reply
* [ofa-general] Re: [PATCH V6 0/9] net/bonding: ADD IPoIB support for the bonding driver
From: Roland Dreier @ 2007-09-25 15:39 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: Jeff Garzik, OpenFabrics General, netdev
In-Reply-To: <10376.1190733869@death>
> Roland, are you comfortable with the IB changes in patches 1 and 2?
Yes, they look fine to me. Feel free to apply, with
Acked-by: Roland Dreier <rolandd@cisco.com>
- R.
^ permalink raw reply
* Re: [PATCH: 2.6.13-15-SMP 3/3] network: concurrently runsoftirqnetwork code on SMP
From: Stephen Hemminger @ 2007-09-25 16:03 UTC (permalink / raw)
To: john ye
Cc: hadi, David Miller, netdev, kuznet, pekkas, jmorris, kaber,
iceburgue, John Ye
In-Reply-To: <007201c7ff89$d5db4cf0$d6ddfea9@JOHNYE1>
On Tue, 25 Sep 2007 23:36:25 +0800
"john ye" <johny@asimco.com.cn> wrote:
> Jamal,
>
> You pointed out a key point: it's NOT acceptable if massive packet re-ordering couldn¡¯t be avoided.
> I debugged function tcp_ofo_queue in net/ipv4/tcp_input.c & monitored out_of_order_queue, found that re-ordering
> becomes unacceptable with the softirq load grows.
>
> It's simple to avoid out-of-order packets by changing random dispatch into dispatch based on source ip address.
> e.g. cpu = iph->saddr % nr_cpus. while cpu is like a hash entry.
> Considering that BS patch is mainly used on server with many incoming connections,
> dispatch by IP should balance CPU load well.
>
> The test is under way, it's not bad so far.
> The queue spin_lock seems not cost much.
>
> Below is the bcpp beautified module code. Last time code mess is caused by outlook express which killed tabs.
>
> Thanks.
>
> John Ye
There is a standard hash called RSS, that many drivers support because it is
used by other operating systems.
^ permalink raw reply
* Re: [PATCH] Remove broken netfilter binary sysctls from bridging code
From: Stephen Hemminger @ 2007-09-25 16:12 UTC (permalink / raw)
To: Patrick McHardy; +Cc: linux-kernel, Linux Netdev List
In-Reply-To: <46F8897C.5010504@trash.net>
On Tue, 25 Sep 2007 06:07:24 +0200
Patrick McHardy <kaber@trash.net> wrote:
> Stephen Hemminger wrote:
> > On Mon, 24 Sep 2007 18:55:38 +0200
> > Patrick McHardy <kaber@trash.net> wrote:
> >
> >>Eric W. Biederman wrote:
> >>
> >>>A really good fix would be to remove the binary side and then to
> >>>modify brnf_sysctl_call_tables to allocate a temporary ctl_table
> >>>and integer on the stack and only set ctl->data after we have
> >>>normalized the written value. But since in practice nothing cares
> >>>about the race a better fix probably isn't worth it.
> >>
> >>
> >>I seem to be missing something, the entire brnf_sysctl_call_tables
> >>thing looks purely cosmetic to me, wouldn't it be better to simply
> >>remove it?
> >
> >
> > I agree, removing seems like a better option. But probably need to
> > go through a 3-6mo warning period, since sysctl's are technically
> > an API.
>
>
> I meant removing brnf_sysctl_call_tables function, not the sysctls
> themselves, all it does is change values != 0 to 1. Or did you
> actually mean that something in userspace might depend on reading
> back the value 1 after writing a value != 0?
I was going farther, because don't really see the value of having
a sysctl for this. It seems better to just not load filters if
they aren't going to be used. Having another enable/disable hook
just adds needless complexity.
^ permalink raw reply
* Re: 2.6.23-rc8-mm1 - drivers/net/ibm_newemac/mal - broken
From: Andrew Morton @ 2007-09-25 16:16 UTC (permalink / raw)
To: Kamalesh Babulal; +Cc: linux-kernel, eugene.surovegin, netdev
In-Reply-To: <46F904E6.40601@linux.vnet.ibm.com>
On Tue, 25 Sep 2007 18:23:58 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> Hi Andrew,
>
> The drivers/net/ibm_newemac/mal seems to be broken, which stop with
> build error
(please cc netdev@vger.kernel.org on networking things)
> CC drivers/net/ibm_newemac/mal.o
> drivers/net/ibm_newemac/mal.c: In function ‘mal_schedule_poll’:
> drivers/net/ibm_newemac/mal.c:238: error: too few arguments to function ‘netif_rx_schedule_prep’
> drivers/net/ibm_newemac/mal.c:238: error: too few arguments to function ‘netif_rx_schedule_prep’
> drivers/net/ibm_newemac/mal.c:238: error: too few arguments to function ‘netif_rx_schedule_prep’
> drivers/net/ibm_newemac/mal.c:241: error: too few arguments to function ‘__netif_rx_schedule’
> drivers/net/ibm_newemac/mal.c: In function ‘mal_poll_disable’:
> drivers/net/ibm_newemac/mal.c:321: error: ‘__LINK_STATE_RX_SCHED’ undeclared (first use in this function)
> drivers/net/ibm_newemac/mal.c:321: error: (Each undeclared identifier is reported only once
> drivers/net/ibm_newemac/mal.c:321: error: for each function it appears in.)
> drivers/net/ibm_newemac/mal.c: In function ‘mal_poll’:
> drivers/net/ibm_newemac/mal.c:337: error: ‘struct net_device’ has no member named ‘quota’
> drivers/net/ibm_newemac/mal.c:337: warning: type defaults to ‘int’ in declaration of ‘_x’
> drivers/net/ibm_newemac/mal.c:337: error: ‘struct net_device’ has no member named ‘quota’
> drivers/net/ibm_newemac/mal.c:375: error: too few arguments to function ‘__netif_rx_complete’
> drivers/net/ibm_newemac/mal.c:390: warning: passing argument 2 of ‘netif_rx_reschedule’ makes pointer from integer without a cast
> drivers/net/ibm_newemac/mal.c:404: error: ‘struct net_device’ has no member named ‘quota’
> drivers/net/ibm_newemac/mal.c: In function ‘mal_probe’:
> drivers/net/ibm_newemac/mal.c:542: error: ‘struct net_device’ has no member named ‘weight’
> drivers/net/ibm_newemac/mal.c:543: error: ‘struct net_device’ has no member named ‘poll’
> drivers/net/ibm_newemac/mal.c: In function ‘mal_remove’:
> drivers/net/ibm_newemac/mal.c:660: error: implicit declaration of function ‘netif_poll_disable’
> make[3]: *** [drivers/net/ibm_newemac/mal.o] Error 1
> make[2]: *** [drivers/net/ibm_newemac] Error 2
> make[1]: *** [drivers/net] Error 2
> make: *** [drivers] Error 2
Yes, there's been a lot of breakage in netdev land:
git-net-fix-macec.patch
git-net-sky2-fixups.patch
git-net-fix-wireless-kconfig.patch
git-net-fix-spidernet-build.patch
git-net-sctp-build-fix.patch
spider_net_ethtool-keep-up-with-recent-netdev-stats-changes.patch
pasemi_mac-build-fix-after-recent-netdev-stats.patch
git-net-fix-pasemi_mac.patch
make-mv643xx_ethc-build-again.patch
but we're getting there. It looks like ibmn_newemac is more busted than
most...
^ permalink raw reply
* Re: [PATCH] sb1250-mac: Driver model & phylib update
From: Andrew Morton @ 2007-09-25 16:18 UTC (permalink / raw)
To: Ralf Baechle
Cc: Maciej W. Rozycki, Jeff Garzik, netdev, linux-mips, linux-kernel
In-Reply-To: <20070925131817.GA28402@linux-mips.org>
On Tue, 25 Sep 2007 14:18:17 +0100 Ralf Baechle <ralf@linux-mips.org> wrote:
> On Fri, Sep 21, 2007 at 12:44:09PM -0700, Andrew Morton wrote:
>
> > > A driver model and phylib update.
> >
> > akpm:/usr/src/25> diffstat patches/git-net.patch | tail -n 1
> > 1013 files changed, 187667 insertions(+), 23587 deletions(-)
> >
> > Sorry, but raising networking patches against Linus's crufty
> > old mainline tree just isn't viable at present.
>
> Out of curiosity:
>
> [ralf@denk linux-queue]$ git diff $(git merge-base master v2.6.23-rc8-mm1)..v2.6.23-rc8-mm1 | wc -cl
> 1046669 31900996
> [ralf@denk linux-queue]$ git diff $(git merge-base master v2.6.23-rc8-mm1)..v2.6.23-rc8-mm1 | diffstat | tail -1
> 6049 files changed, 573635 insertions(+), 207630 deletions(-)
A few years ago I thought it might slow down soon.
> [ralf@denk linux-queue]$
>
> We're all a little too productive ;-)
s/prod/destr/
^ permalink raw reply
* Re: [PATCH] Remove broken netfilter binary sysctls from bridging code
From: Patrick McHardy @ 2007-09-25 16:22 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: linux-kernel, Linux Netdev List
In-Reply-To: <20070925091203.371879e2@fujitsu-loaner>
Stephen Hemminger wrote:
> On Tue, 25 Sep 2007 06:07:24 +0200
> Patrick McHardy <kaber@trash.net> wrote:
>
>
>> I meant removing brnf_sysctl_call_tables function, not the sysctls
>> themselves, all it does is change values != 0 to 1. Or did you
>> actually mean that something in userspace might depend on reading
>> back the value 1 after writing a value != 0?
>>
>
> I was going farther, because don't really see the value of having
> a sysctl for this. It seems better to just not load filters if
> they aren't going to be used. Having another enable/disable hook
> just adds needless complexity.
>
These sysctls control whether bridged packets will be handled
by iptables and friends. The bridge netfilter code always
handles bridged packets, and iptables might be loaded for
different reasons. So I don't see how that would work.
I think it should be specified in the ebtables ruleset, but
the current netfilter infrastructure doesn't allow to do that
cleanly.
^ permalink raw reply
* Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver
From: Oliver Hartkopp @ 2007-09-25 17:55 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / È£ÑÀ
Cc: Patrick McHardy, Urs Thuermann, netdev, davem, joe, tglx,
oliver.hartkopp
In-Reply-To: <46F91F64.2050008@trash.net>
Patrick McHardy wrote:
> Urs Thuermann wrote:
>
>> YOSHIFUJI Hideaki / È£ÑÀ <yoshfuji@linux-ipv6.org> writes:
>>
>>
>>
>>> I'm not a lawyer, but the following lines:
>>>
>>> | + * Alternatively, provided that this notice is retained in full, this
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> | + * software may be distributed under the terms of the GNU General
>>> | + * Public License ("GPL") version 2 as distributed in the 'COPYING'
>>> | + * file from the main directory of the linux kernel source.
>>>
>>> make this whole licence imcompatible with GPL.
>>>
>>
The module license is "Dual BSD/GPL" as many other code in the Linux
Kernel. So this should not be any problem.
>>> I do think you need to allow people to select GPLv2 only.
>>>
>>
The Linux Kernel is currently under GPLv2 and we just wanted to follow
Linus' mind and so we referenced the COPYING file which many other
source does as well. Indeed it was a hard thing to make our code
available under GPL (as creating and publishing open source software is
really no a usual thing for the Volkswagen rights department). So i
discussed with the rights department about several disclaimers inside
the current Kernel (especially the stuff that has been signed off by
companies like IBM, Motorola, etc.). In this process it turned out to be
the best to license the code under "Dual BSD/GPL" as it grants more
rights to the programmer (including ourselves) than a GPL only license.
I assume this was the intention from IBM, Motorola and all the others
also. Btw. inside the Kernel context it behaves exactly like GPL code
(like all the other dual license code).
So i really can't see any problem here. If so there would have been a
big discussion about the other "Dual BSD/GPL" code.
Best regards,
Oliver
ps. I hope, i found the right words right now, as i'm not very familiar
with English :)
^ permalink raw reply
* Userspace network stack and netchannels.
From: Evgeniy Polyakov @ 2007-09-25 18:00 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 1608 bytes --]
Hi.
I've released new version of the extremely small
userspace netowork stack [1] implementation.
Stack supports TCP and UDP over IP.
It works on top of netchannels [2] or packet socket
(returned back in this release).
Supported features:
* TCP/UDP sending and receiving.
* Timestamp, window scaling, MSS TCP options.
* PAWS.
* Slow start and congestion control.
* Socket-like interface.
* Retransmit and fast retransmit support.
* support for TCP listen state (only point-to-point mode,
i.e. no new data channels are created, when new client is
connected, instead state is changed according to protocol
(TCP state is changed to ESTABLISHED).
* support for the netchannels and packet socket interface.
It was proven [3] that unetstack can be *much* faster than vanilla TCP
stack (mainly because of heavily reduced number of syscalls, different
congestion control algorithm and other features).
This release includes number of bugs fixed (thanks to Salvatore Del
Popolo for continuously kicking me), packet socket interface (enabled at
compile time) and small documentation update (including example).
Attached archive for intrested readers.
Thank you.
1. Userspace network stack.
http://tservice.net.ru/~s0mbre/old/?section=projects&item=unetstack
2. Netchannel subsystem.
http://tservice.net.ru/~s0mbre/old/?section=projects&item=netchannel
3. Gigabit send/recv benchmark for netchannels and sockets using small
packets.
http://tservice.net.ru/~s0mbre/blog/devel/networking/2006_10_26.html
http://tservice.net.ru/~s0mbre/blog/devel/networking/2006_12_21.html
--
Evgeniy Polyakov
[-- Attachment #2: unetstack-2007_09_25.tar.gz --]
[-- Type: application/x-tar-gz, Size: 25717 bytes --]
^ permalink raw reply
* Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver
From: Patrick McHardy @ 2007-09-25 17:53 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: YOSHIFUJI Hideaki / È£ÑÀ, Urs Thuermann,
netdev, davem, joe, tglx, oliver.hartkopp
In-Reply-To: <46F94B91.5020209@hartkopp.net>
Oliver Hartkopp wrote:
>>>>I do think you need to allow people to select GPLv2 only.
>>>>
>>>
> The Linux Kernel is currently under GPLv2 and we just wanted to follow
> Linus' mind and so we referenced the COPYING file which many other
> source does as well. Indeed it was a hard thing to make our code
> available under GPL (as creating and publishing open source software is
> really no a usual thing for the Volkswagen rights department). So i
> discussed with the rights department about several disclaimers inside
> the current Kernel (especially the stuff that has been signed off by
> companies like IBM, Motorola, etc.). In this process it turned out to be
> the best to license the code under "Dual BSD/GPL" as it grants more
> rights to the programmer (including ourselves) than a GPL only license.
> I assume this was the intention from IBM, Motorola and all the others
> also. Btw. inside the Kernel context it behaves exactly like GPL code
> (like all the other dual license code).
>
> So i really can't see any problem here. If so there would have been a
> big discussion about the other "Dual BSD/GPL" code.
Yoshifuji's point was that the license seems to contradict itself,
it says you may choose GPL, but have to retain BSD. And that is
not about Dual BSD/GPL but about the specific wording.
/me runs and refrains from the discussion as promised :)
^ permalink raw reply
* Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver
From: Oliver Hartkopp @ 2007-09-25 19:09 UTC (permalink / raw)
To: Patrick McHardy, YOSHIFUJI Hideaki / È£ÑÀ
Cc: Urs Thuermann, netdev, davem, joe, tglx, oliver.hartkopp
In-Reply-To: <46F94B00.3060006@trash.net>
Patrick McHardy wrote:
>
> Yoshifuji's point was that the license seems to contradict itself,
> it says you may choose GPL, but have to retain BSD. And that is
> not about Dual BSD/GPL but about the specific wording.
>
Got it (finally)!
Trying to specify the GPL Version (and the reference to the COPYING
file) i just overlooked the second part
"*/*/in which case the provisions of the GPL apply INSTEAD OF those
given above."/*/* of the original sentence.
Sorry. Was no* malice aforethought :)*
Of course we'll fix this to have the same wording like e.g. in
arch/i386/crypto/aes.c .
Thanks to Yoshfuji for catching this and to Patrick for making it clear
to me!*
Best regards,
Oliver
*
^ permalink raw reply
* Re: Userspace network stack and netchannels.
From: Robert Iakobashvili @ 2007-09-25 19:22 UTC (permalink / raw)
To: netdev
In-Reply-To: <7e63f56c0709251220s12ab10b5pade5b2c90fa4a8b9@mail.gmail.com>
Evgeniy,
On 9/25/07, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> I've released new version of the extremely small
> userspace netowork stack [1] implementation.
>
> 1. Userspace network stack.
> http://tservice.net.ru/~s0mbre/old/?section=projects&item=unetstack
>
> 2. Netchannel subsystem.
> http://tservice.net.ru/~s0mbre/old/?section=projects&item=netchannel
>
> 3. Gigabit send/recv benchmark for netchannels and sockets using small
> packets.
> http://tservice.net.ru/~s0mbre/blog/devel/networking/2006_10_26.html
> http://tservice.net.ru/~s0mbre/blog/devel/networking/2006_12_21.html
>
Very interesting. Are there any details of your benchmarking available,
namely, how it was done?
Have you some comparison profiling data (oprofile) to figure out where
the advantages are coming from?
--
Sincerely,
Robert Iakobashvili,
coroberti %x40 gmail %x2e com
...........................................................
http://curl-loader.sourceforge.net
A web testing and traffic generation tool.
--
Sincerely,
Robert Iakobashvili,
coroberti %x40 gmail %x2e com
...........................................................
http://curl-loader.sourceforge.net
A web testing and traffic generation tool.
^ permalink raw reply
* Re: Userspace network stack and netchannels.
From: Stephen Hemminger @ 2007-09-25 19:34 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: netdev
In-Reply-To: <20070925180043.GA16698@2ka.mipt.ru>
On Tue, 25 Sep 2007 22:00:48 +0400
Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> Hi.
>
> I've released new version of the extremely small
> userspace netowork stack [1] implementation.
> Stack supports TCP and UDP over IP.
> It works on top of netchannels [2] or packet socket
> (returned back in this release).
>
> Supported features:
> * TCP/UDP sending and receiving.
> * Timestamp, window scaling, MSS TCP options.
> * PAWS.
> * Slow start and congestion control.
> * Socket-like interface.
> * Retransmit and fast retransmit support.
> * support for TCP listen state (only point-to-point mode,
> i.e. no new data channels are created, when new client is
> connected, instead state is changed according to protocol
> (TCP state is changed to ESTABLISHED).
> * support for the netchannels and packet socket interface.
>
> It was proven [3] that unetstack can be *much* faster than vanilla TCP
> stack (mainly because of heavily reduced number of syscalls, different
> congestion control algorithm and other features).
I am glad to see a more complete implementation for comparison, but
by changing several variables at once it makes it hard to evaluate whether
the improvement comes from user space TCP or the other changes.
^ permalink raw reply
* [git patches] additional net driver fixes
From: Jeff Garzik @ 2007-09-25 19:51 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds; +Cc: netdev, LKML
These two wireless fixes are IN ADDITION to the previously submitted
fixes. Same linear history. In other words, if you pull
"upstream-linus", you will get both the changes below, _and_ the changes
I submitted yesterday. If you have already pulled yesterday's fixes,
then you will only receive the changesets below.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-linus
to receive the following updates:
fs/compat_ioctl.c | 2 +
net/ieee80211/softmac/ieee80211softmac_assoc.c | 2 -
net/ieee80211/softmac/ieee80211softmac_wx.c | 54 +++++++++---------------
7 files changed, 61 insertions(+), 52 deletions(-)
Jean Tourrilhes (1):
WE : Add missing auth compat-ioctl
Larry Finger (1):
softmac: Fix inability to associate with WEP networks
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index 5a5b711..37310b0 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -3190,6 +3190,8 @@ COMPATIBLE_IOCTL(SIOCSIWRETRY)
COMPATIBLE_IOCTL(SIOCGIWRETRY)
COMPATIBLE_IOCTL(SIOCSIWPOWER)
COMPATIBLE_IOCTL(SIOCGIWPOWER)
+COMPATIBLE_IOCTL(SIOCSIWAUTH)
+COMPATIBLE_IOCTL(SIOCGIWAUTH)
/* hiddev */
COMPATIBLE_IOCTL(HIDIOCGVERSION)
COMPATIBLE_IOCTL(HIDIOCAPPLICATION)
diff --git a/net/ieee80211/softmac/ieee80211softmac_assoc.c b/net/ieee80211/softmac/ieee80211softmac_assoc.c
index afb6c66..e475f2e 100644
--- a/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ b/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -273,8 +273,6 @@ ieee80211softmac_assoc_work(struct work_struct *work)
ieee80211softmac_notify(mac->dev, IEEE80211SOFTMAC_EVENT_SCAN_FINISHED, ieee80211softmac_assoc_notify_scan, NULL);
if (ieee80211softmac_start_scan(mac)) {
dprintk(KERN_INFO PFX "Associate: failed to initiate scan. Is device up?\n");
- mac->associnfo.associating = 0;
- mac->associnfo.associated = 0;
}
goto out;
} else {
diff --git a/net/ieee80211/softmac/ieee80211softmac_wx.c b/net/ieee80211/softmac/ieee80211softmac_wx.c
index d054e92..442b987 100644
--- a/net/ieee80211/softmac/ieee80211softmac_wx.c
+++ b/net/ieee80211/softmac/ieee80211softmac_wx.c
@@ -70,44 +70,30 @@ ieee80211softmac_wx_set_essid(struct net_device *net_dev,
char *extra)
{
struct ieee80211softmac_device *sm = ieee80211_priv(net_dev);
- struct ieee80211softmac_network *n;
struct ieee80211softmac_auth_queue_item *authptr;
int length = 0;
check_assoc_again:
mutex_lock(&sm->associnfo.mutex);
- /* Check if we're already associating to this or another network
- * If it's another network, cancel and start over with our new network
- * If it's our network, ignore the change, we're already doing it!
- */
if((sm->associnfo.associating || sm->associnfo.associated) &&
(data->essid.flags && data->essid.length)) {
- /* Get the associating network */
- n = ieee80211softmac_get_network_by_bssid(sm, sm->associnfo.bssid);
- if(n && n->essid.len == data->essid.length &&
- !memcmp(n->essid.data, extra, n->essid.len)) {
- dprintk(KERN_INFO PFX "Already associating or associated to "MAC_FMT"\n",
- MAC_ARG(sm->associnfo.bssid));
- goto out;
- } else {
- dprintk(KERN_INFO PFX "Canceling existing associate request!\n");
- /* Cancel assoc work */
- cancel_delayed_work(&sm->associnfo.work);
- /* We don't have to do this, but it's a little cleaner */
- list_for_each_entry(authptr, &sm->auth_queue, list)
- cancel_delayed_work(&authptr->work);
- sm->associnfo.bssvalid = 0;
- sm->associnfo.bssfixed = 0;
- sm->associnfo.associating = 0;
- sm->associnfo.associated = 0;
- /* We must unlock to avoid deadlocks with the assoc workqueue
- * on the associnfo.mutex */
- mutex_unlock(&sm->associnfo.mutex);
- flush_scheduled_work();
- /* Avoid race! Check assoc status again. Maybe someone started an
- * association while we flushed. */
- goto check_assoc_again;
- }
+ dprintk(KERN_INFO PFX "Canceling existing associate request!\n");
+ /* Cancel assoc work */
+ cancel_delayed_work(&sm->associnfo.work);
+ /* We don't have to do this, but it's a little cleaner */
+ list_for_each_entry(authptr, &sm->auth_queue, list)
+ cancel_delayed_work(&authptr->work);
+ sm->associnfo.bssvalid = 0;
+ sm->associnfo.bssfixed = 0;
+ sm->associnfo.associating = 0;
+ sm->associnfo.associated = 0;
+ /* We must unlock to avoid deadlocks with the assoc workqueue
+ * on the associnfo.mutex */
+ mutex_unlock(&sm->associnfo.mutex);
+ flush_scheduled_work();
+ /* Avoid race! Check assoc status again. Maybe someone started an
+ * association while we flushed. */
+ goto check_assoc_again;
}
sm->associnfo.static_essid = 0;
@@ -153,13 +139,13 @@ ieee80211softmac_wx_get_essid(struct net_device *net_dev,
data->essid.length = sm->associnfo.req_essid.len;
data->essid.flags = 1; /* active */
memcpy(extra, sm->associnfo.req_essid.data, sm->associnfo.req_essid.len);
- }
-
+ dprintk(KERN_INFO PFX "Getting essid from req_essid\n");
+ } else if (sm->associnfo.associated || sm->associnfo.associating) {
/* If we're associating/associated, return that */
- if (sm->associnfo.associated || sm->associnfo.associating) {
data->essid.length = sm->associnfo.associate_essid.len;
data->essid.flags = 1; /* active */
memcpy(extra, sm->associnfo.associate_essid.data, sm->associnfo.associate_essid.len);
+ dprintk(KERN_INFO PFX "Getting essid from associate_essid\n");
}
mutex_unlock(&sm->associnfo.mutex);
^ permalink raw reply related
* [ofa-general] Re: [DOC] Net batching driver howto
From: Randy Dunlap @ 2007-09-25 20:16 UTC (permalink / raw)
To: hadi
Cc: johnpol, peter.p.waskiewicz.jr, kumarkr, herbert, Jeff Garzik,
Robert.Olsson, netdev, rdreier, mcarlson, David Miller, gaagaan,
jagana, general, mchan, tgraf, sri, shemminger, kaber
In-Reply-To: <1190674459.4264.28.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 536 bytes --]
On Mon, 24 Sep 2007 18:54:19 -0400 jamal wrote:
> I have updated the driver howto to match the patches i posted yesterday.
> attached.
Thanks for sending this.
This is an early draft, right?
I'll fix some typos etc. in it (patch attached) and add some whitespace.
Please see RD: in the patch for more questions/comments.
IMO it needs some changes to eliminate words like "we", "you",
and "your" (words that personify code). Those words are OK
when talking about yourself.
---
~Randy
Phaedrus says that Quality is about caring.
[-- Attachment #2: batch-howto.patch --]
[-- Type: text/x-patch, Size: 11579 bytes --]
batch-driver-howto.txt | 116 +++++++++++++++++++++------------------
1 file changed, 63 insertions(+), 53 deletions(-)
diff -Naurp tmp/batch-driver-howto.txt~fix1 tmp/batch-driver-howto.txt
--- tmp/batch-driver-howto.txt~fix1 2007-09-25 12:44:10.000000000 -0700
+++ tmp/batch-driver-howto.txt 2007-09-25 13:14:27.000000000 -0700
@@ -1,13 +1,13 @@
-Heres the begining of a howto for driver authors.
+Here's the beginning of a howto for driver authors.
The intended audience for this howto is people already
familiar with netdevices.
-1.0 Netdevice Pre-requisites
+1.0 Netdevice Prerequisites
------------------------------
-For hardware based netdevices, you must have at least hardware that
-is capable of doing DMA with many descriptors; i.e having hardware
+For hardware-based netdevices, you must have at least hardware that
+is capable of doing DMA with many descriptors; i.e., having hardware
with a queue length of 3 (as in some fscked ethernet hardware) is
not very useful in this case.
@@ -15,33 +15,36 @@ not very useful in this case.
-----------------------------------
There are 3 new methods and one new variable introduced. These are:
-1)dev->hard_prep_xmit()
-2)dev->hard_end_xmit()
-3)dev->hard_batch_xmit()
-4)dev->xmit_win
+1) dev->hard_prep_xmit()
+2) dev->hard_end_xmit()
+3) dev->hard_batch_xmit()
+4) dev->xmit_win
2.1 Using Core driver changes
-----------------------------
-To provide context, lets look at a typical driver abstraction
+To provide context, let's look at a typical driver abstraction
for dev->hard_start_xmit(). It has 4 parts:
-a) packet formating (example vlan, mss, descriptor counting etc)
-b) chip specific formatting
+a) packet formatting (example: vlan, mss, descriptor counting, etc.)
+b) chip-specific formatting
c) enqueueing the packet on a DMA ring
d) IO operations to complete packet transmit, tell DMA engine to chew
-on, tx completion interupts etc
+on, tx completion interrupts, etc.
[For code cleanliness/readability sake, regardless of this work,
one should break the dev->hard_start_xmit() into those 4 functions
anyways].
+
A driver which has all 4 parts and needing to support batching is
advised to split its dev->hard_start_xmit() in the following manner:
-1)use its dev->hard_prep_xmit() method to achieve #a
-2)use its dev->hard_end_xmit() method to achieve #d
-3)#b and #c can stay in ->hard_start_xmit() (or whichever way you
+
+1) use its dev->hard_prep_xmit() method to achieve #a
+2) use its dev->hard_end_xmit() method to achieve #d
+3) #b and #c can stay in ->hard_start_xmit() (or whichever way you
want to do this)
+
Note: There are drivers which may need not support any of the two
-methods (example the tun driver i patched) so the two methods are
+methods (for example, the tun driver I patched), so the two methods are
essentially optional.
2.1.1 Theory of operation
@@ -49,7 +52,7 @@ essentially optional.
The core will first do the packet formatting by invoking your
supplied dev->hard_prep_xmit() method. It will then pass you the packet
-via your dev->hard_start_xmit() method for as many as packets you
+via your dev->hard_start_xmit() method for as many packets as you
have advertised (via dev->xmit_win) you can consume. Lastly it will
invoke your dev->hard_end_xmit() when it completes passing you all the
packets queued for you.
@@ -58,16 +61,16 @@ packets queued for you.
2.1.1.1 Locking rules
---------------------
-dev->hard_prep_xmit() is invoked without holding any
-tx lock but the rest are under TX_LOCK(). So you have to ensure that
-whatever you put it dev->hard_prep_xmit() doesnt require locking.
+dev->hard_prep_xmit() is invoked without holding any tx lock
+but the rest are under TX_LOCK(). So you have to ensure that
+whatever you put it dev->hard_prep_xmit() doesn't require locking.
2.1.1.2 The slippery LLTX
-------------------------
LLTX drivers present a challenge in that we have to introduce a deviation
from the norm and require the ->hard_batch_xmit() method. An LLTX
-driver presents us with ->hard_batch_xmit() to which we pass it a list
+driver presents us with ->hard_batch_xmit() to which we pass in a list
of packets in a dev->blist skb queue. It is then the responsibility
of the ->hard_batch_xmit() to exercise steps #b and #c for all packets
passed in the dev->blist.
@@ -80,11 +83,14 @@ dev->hard_prep_xmit() and dev->hard_end_
dev->xmit_win variable is set by the driver to tell us how
much space it has in its rings/queues. dev->xmit_win is introduced to
ensure that when we pass the driver a list of packets it will swallow
-all of them - which is useful because we dont requeue to the qdisc (and
-avoids burning unnecessary cpu cycles or introducing any strange
+all of them -- which is useful because we don't requeue to the qdisc (and
+avoids burning unnecessary CPU cycles or introducing any strange
re-ordering). The driver tells us, whenever it invokes netif_wake_queue,
how much space it has for descriptors by setting this variable.
+RD: so xmit_win is not total queue size, it's the available queue size
+when calling netif_wake_queue(), right? I guess that's explained below.
+
3.0 Driver Essentials
---------------------
@@ -104,18 +110,18 @@ The typical driver tx state machine is:
-1-> +Cycle repeats and core sends more packets (step 1).
----
-3.1 Driver pre-requisite
+3.1 Driver prerequisite
--------------------------
This is _a very important_ requirement in making batching useful.
-The pre-requisite for batching changes is that the driver should
+The prerequisite for batching changes is that the driver should
provide a low threshold to open up the tx path.
Drivers such as tg3 and e1000 already do this.
Before you invoke netif_wake_queue(dev) you check if there is a
threshold of space reached to insert new packets.
-Heres an example of how i added it to tun driver. Observe the
-setting of dev->xmit_win
+Here's an example of how I added it to tun driver. Observe the
+setting of dev->xmit_win.
---
+#define NETDEV_LTT 4 /* the low threshold to open up the tx path */
@@ -153,14 +159,14 @@ in tg3 code (with no batching changes) l
-----------------
a) On initialization (before netdev registration)
- i) set NETIF_F_BTX in dev->features
- i.e dev->features |= NETIF_F_BTX
+ 1) set NETIF_F_BTX in dev->features
+ i.e., dev->features |= NETIF_F_BTX
This makes the core do proper initialization.
-ii) set dev->xmit_win to something reasonable like
+ 2) set dev->xmit_win to something reasonable like
maybe half the tx DMA ring size etc.
-b) create proper pointer to the new methods desribed above if
+b) create proper pointer to the new methods described above if
you need them.
3.3 Annotation on the different methods
@@ -171,27 +177,30 @@ methods and variable could be used.
3.3.1 The dev->hard_prep_xmit() method
---------------------------------------
-Use this method to only do pre-processing of the skb passed.
-If in the current dev->hard_start_xmit() you are pre-processing
-packets before holding any locks (eg formating them to be put in
-any descriptor etc).
+Use this method only to do preprocessing of the skb passed.
+If in the current dev->hard_start_xmit() you are preprocessing
+packets before holding any locks (e.g., formatting them to be put in
+any descriptor etc.).
+RD: incomplete sentence above.
Look at e1000_prep_queue_frame() for an example.
You may use the skb->cb to store any state that you need to know
-of later when batching.
-PS: I have found when discussing with Michael Chan and Matt Carlson
-that skb->cb[0] (8bytes of it) is used by the VLAN code to pass VLAN
+later when batching.
+
+NOTE: I have found when discussing with Michael Chan and Matt Carlson
+that skb->cb[0] (8 bytes of it) is used by the VLAN code to pass VLAN
info to the driver.
I think this is a violation of the usage of the cb scratch pad.
To work around this, you could use skb->cb[8] or do what the broadcom
-tg3 bacthing driver does which is to glean the vlan info first then
-re-use the skb->cb.
+tg3 batching driver does which is to glean the vlan info first then
+reuse the skb->cb.
3.3.2 dev->hard_start_xmit()
----------------------------
-Heres an example of tx routine that is similar to the one i added
+Here's an example of tx routine that is similar to the one I added
to the current tun driver. bxmit suffix is kept so that you can turn
off batching if needed via and call already existing interface.
+RD: off batching via ethtool if needed ??
----
static int xxx_net_bxmit(struct net_device *dev)
@@ -211,14 +220,14 @@ off batching if needed via and call alre
}
------
-All return codes like NETDEV_TX_OK etc still apply.
+All return codes like NETDEV_TX_OK etc. still apply.
3.3.3 The LLTX batching method, dev->batch_xmit()
-------------------------------------------------
-Heres an example of a batch tx routine that is similar
-to the one i added to the older tun driver. Essentially
-this is what youd do if you wanted to support LLTX.
+Here's an example of a batch tx routine that is similar
+to the one I added to the older tun driver. Essentially
+this is what you would do if you wanted to support LLTX.
----
static int xxx_net_bxmit(struct net_device *dev)
@@ -228,7 +237,7 @@ this is what youd do if you wanted to su
while (skb_queue_len(dev->blist)) {
dequeue from dev->blist
enqueue onto hardware ring
- if hardware ring full break
+ if hardware ring full, break
}
if (hardware ring full) {
@@ -242,34 +251,35 @@ this is what youd do if you wanted to su
}
------
-All return codes like NETDEV_TX_OK etc still apply.
+All return codes like NETDEV_TX_OK etc. still apply.
3.3.4 The tx complete, dev->hard_end_xmit()
-------------------------------------------------
In this method, if there are any IO operations that apply to a
-set of packets such as kicking DMA, setting of interupt thresholds etc,
+set of packets such as kicking DMA, setting of interrupt thresholds etc.,
leave them to the end and apply them once if you have successfully enqueued.
-This provides a mechanism for saving a lot of cpu cycles since IO
+This provides a mechanism for saving a lot of CPU cycles since IO
is cycle expensive.
-For an example of this look e1000 driver e1000_kick_DMA() function.
+For an example of this look at the e1000 driver e1000_kick_DMA() function.
3.3.5 setting the dev->xmit_win
-----------------------------
As mentioned earlier this variable provides hints on how much
data to send from the core to the driver. Here are the obvious ways:
-a)on doing a netif_stop, set it to 1. By default all drivers have
+
+a) on doing a netif_stop, set it to 1. By default all drivers have
this value set to 1 to emulate old behavior where a driver only
receives one packet at a time.
-b)on netif_wake_queue set it to the max available space. You have
+b) on netif_wake_queue set it to the max available space. You have
to be careful if your hardware does scatter-gather since the core
will pass you scatter-gatherable skbs and so you want to at least
leave enough space for the maximum allowed. Look at the tg3 and
e1000 to see how this is implemented.
The variable is important because it avoids the core sending
-any more than what the driver can handle therefore avoiding
+any more than what the driver can handle, therefore avoiding
any need to muck with packet scheduling mechanisms.
Appendix 1: History
[-- Attachment #3: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH 2/7] CAN: Add PF_CAN core module
From: Urs Thuermann @ 2007-09-25 21:00 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, David Miller, Patrick McHardy, Joe Perches,
Thomas Gleixner, Oliver Hartkopp, Oliver Hartkopp
In-Reply-To: <20070925083303.6c1f7701@freepuppy.rosehill>
Stephen Hemminger <shemminger@linux-foundation.org> writes:
> Then please make all exported symbols marked EXPORT_SYMBOL_GPL to make
> sure that the other CAN protocol can not reuse your infrastructure.
We don't want to force other CAN protocol implementations to be GPL
also. AFAIR from discussions on LKML, it was mostly agreed upon that
this decision is up to the authors of code.
urs
^ permalink raw reply
* Re: [PATCH 2/7] CAN: Add PF_CAN core module
From: Stephen Hemminger @ 2007-09-25 21:07 UTC (permalink / raw)
To: Urs Thuermann
Cc: netdev, David Miller, Patrick McHardy, Joe Perches,
Thomas Gleixner, Oliver Hartkopp, Oliver Hartkopp
In-Reply-To: <ygfejgmea00.fsf@janus.isnogud.escape.de>
On 25 Sep 2007 23:00:15 +0200
Urs Thuermann <urs@isnogud.escape.de> wrote:
> Stephen Hemminger <shemminger@linux-foundation.org> writes:
>
> > Then please make all exported symbols marked EXPORT_SYMBOL_GPL to
> > make sure that the other CAN protocol can not reuse your
> > infrastructure.
>
> We don't want to force other CAN protocol implementations to be GPL
> also. AFAIR from discussions on LKML, it was mostly agreed upon that
> this decision is up to the authors of code.
>
> urs
I just don't want proprietary drivers extensions in linux kernel.
EXPORT_SYMBOL has no meaning in other OS environments.
^ permalink raw reply
* my plans...
From: David Miller @ 2007-09-25 21:19 UTC (permalink / raw)
To: netdev
I just got back from some travelling this past weekend, so
what I'm going to do today is:
1) Rebase net-2.6.24, that's what I'm doing right now.
I'll be combining bug fixes for feature patches as
much as possible, so this might take most if not all
of this afternoon.
2) After the rebase is done I'll go through the patches
in my backlog for net-2.6.24 which have accumulated.
Thanks.
^ permalink raw reply
* Re: [PATCH 2/7] CAN: Add PF_CAN core module
From: David Miller @ 2007-09-25 21:09 UTC (permalink / raw)
To: urs; +Cc: shemminger, netdev, kaber, joe, tglx, oliver, oliver.hartkopp
In-Reply-To: <ygfejgmea00.fsf@janus.isnogud.escape.de>
From: Urs Thuermann <urs@isnogud.escape.de>
Date: 25 Sep 2007 23:00:15 +0200
> Stephen Hemminger <shemminger@linux-foundation.org> writes:
>
> > Then please make all exported symbols marked EXPORT_SYMBOL_GPL to make
> > sure that the other CAN protocol can not reuse your infrastructure.
>
> We don't want to force other CAN protocol implementations to be GPL
> also. AFAIR from discussions on LKML, it was mostly agreed upon that
> this decision is up to the authors of code.
To a certain extent, yes.
However, the core issue is whether anyone who uses the symbol
is creating a derivative work. If it is pretty clear that this
is the case, you really should mark the exported symbols GPL.
In my opinion, in this case it is pretty clear that any use of
these new symbols would be a derivative work and therefore they
all should be marked GPL.
^ permalink raw reply
* [ofa-general] Re: [PATCH 1/4] [NET_SCHED] explict hold dev tx lock
From: jamal @ 2007-09-25 22:14 UTC (permalink / raw)
To: Stephen Hemminger
Cc: johnpol, kumarkr, herbert, gaagaan, Robert.Olsson, netdev,
rdreier, Waskiewicz Jr, Peter P, mcarlson, kaber, randy.dunlap,
jagana, general, mchan, tgraf, jeff, sri, David Miller
In-Reply-To: <20070925082457.6fec30d6@freepuppy.rosehill>
On Tue, 2007-25-09 at 08:24 -0700, Stephen Hemminger wrote:
> The transmit code path is locked as a code region, rather than just object locking
> on the transmit queue or other fine grained object. This leads to moderately long
> lock hold times when multiple qdisc's and classification is being done.
It will be pretty tricky to optimize that path given the dependencies
between the queues, classifiers, and actions in enqueues; schedulers in
dequeues as well as their config/queries from user space which could
happen concurently on all "N" CPUs.
The txlock optimization i added in patch1 intends to let go of the queue
lock when we enter the dequeue region sooner to reduce the contention.
A further optimization i made was to reduce the time it takes to hold
the tx lock at the driver by moving gunk that doesnt need lock-holding
into the new method dev->hard_end_xmit() (refer to patch #2)
> If we went to finer grain locking it would also mean changes to all network
> devices using the new locking model. My assumption is that we would use
> something like the features flag to do the transition for backward compatibility.
> Take this as a purely "what if" or "it would be nice if" kind of suggestion
> not a requirement or some grand plan.
Ok, hopefully someone would demonstrate how to achieve it; seems a hard
thing to achieve.
cheers,
jamal
^ 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