* Destroying alive neighbour
From: Sergey Senozhatsky @ 2011-04-29 19:44 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1969 bytes --]
Hello,
.39-rc5-git2
Not sure whether I can reproduce this easily:
[ 845.225899] Destroying alive neighbour ffff88015736b400
[ 845.225910] Pid: 0, comm: kworker/0:1 Not tainted 2.6.39-rc5-dbg-git2-00495-g48c9216-dirty #543
[ 845.225917] Call Trace:
[ 845.225922] <IRQ> [<ffffffff813dee2f>] neigh_destroy+0x3c/0x115
[ 845.225950] [<ffffffff81400326>] ipv4_dst_check+0xae/0x158
[ 845.225963] [<ffffffff813c6f67>] __sk_dst_check+0xa5/0xd4
[ 845.225975] [<ffffffff8142e772>] inet_sk_rebuild_header+0x15/0x2b7
[ 845.225989] [<ffffffff8141c762>] ? tcp_write_timer+0x19/0x1a4
[ 845.225999] [<ffffffff8141ac3b>] tcp_retransmit_skb+0x8f/0x522
[ 845.226010] [<ffffffff81241579>] ? do_raw_spin_lock+0x6b/0x122
[ 845.226020] [<ffffffff8141c598>] tcp_retransmit_timer+0x4d5/0x686
[ 845.226030] [<ffffffff8141c7e7>] tcp_write_timer+0x9e/0x1a4
[ 845.226043] [<ffffffff8104c1f6>] run_timer_softirq+0x319/0x4f5
[ 845.226053] [<ffffffff8104c0c4>] ? run_timer_softirq+0x1e7/0x4f5
[ 845.226065] [<ffffffff8105fcf2>] ? __run_hrtimer+0x2ac/0x357
[ 845.226076] [<ffffffff8141c749>] ? tcp_retransmit_timer+0x686/0x686
[ 845.226091] [<ffffffff81044e73>] __do_softirq+0x170/0x301
[ 845.226104] [<ffffffff8106a257>] ? tick_dev_program_event+0x37/0xf6
[ 845.226115] [<ffffffff8106a330>] ? tick_program_event+0x1a/0x1c
[ 845.226127] [<ffffffff814791dc>] call_softirq+0x1c/0x30
[ 845.226140] [<ffffffff810031d7>] do_softirq+0x46/0x9f
[ 845.226151] [<ffffffff8104525a>] irq_exit+0x4e/0xa0
[ 845.226166] [<ffffffff8101954c>] smp_apic_timer_interrupt+0x87/0x95
[ 845.226212] [<ffffffff81478d13>] apic_timer_interrupt+0x13/0x20
[ 845.226216] <EOI> [<ffffffff8126d3b7>] ? intel_idle+0xe0/0x105
[ 845.226232] [<ffffffff8126d3b0>] ? intel_idle+0xd9/0x105
[ 845.226242] [<ffffffff813b93d4>] cpuidle_idle_call+0x157/0x288
[ 845.226250] [<ffffffff810007aa>] cpu_idle+0xa2/0xf3
[ 845.226259] [<ffffffff8146244b>] start_secondary+0x1ee/0x1f7
Sergey
[-- Attachment #2: Type: application/pgp-signature, Size: 316 bytes --]
^ permalink raw reply
* Re: [PATCH v2] net: ftmac100: fix scheduling while atomic during PHY link status change
From: David Miller @ 2011-04-29 19:42 UTC (permalink / raw)
To: adam.jaremko; +Cc: ratbert.chuang, ratbert, netdev, eric.dumazet
In-Reply-To: <1304012478.3715.5.camel@localhost.localdomain>
From: Adam Jaremko <adam.jaremko@gmail.com>
Date: Thu, 28 Apr 2011 13:41:18 -0400
> I think I've sorted my mail client preferences and all should be well now.
>
> Signed-off-by: Adam Jaremko <adam.jaremko@gmail.com>
> Acked-by: Po-Yu Chuang <ratbert@faraday-tech.com>
This is better, yes, applied.
^ permalink raw reply
* Re: [PATCH] usbnet: Transfer of maintainership
From: David Miller @ 2011-04-29 19:40 UTC (permalink / raw)
To: oneukum; +Cc: netdev, linux-usb
In-Reply-To: <201104291419.04498.oneukum@suse.de>
From: Oliver Neukum <oneukum@suse.de>
Date: Fri, 29 Apr 2011 14:19:04 +0200
> From 8786db859938a1be111b5b3a86161d38da5ac8db Mon Sep 17 00:00:00 2001
> From: Oliver Neukum <oliver@neukum.org>
> Date: Fri, 29 Apr 2011 14:15:53 +0200
> Subject: [PATCH] usbnet: Transfer of maintainership
>
> Somebody has to do it, however unfortunate be the cause.
>
> Signed-off-by: Oliver Neukum <oneukum@suse.de>
Applied, thanks Oliver.
^ permalink raw reply
* Re: [PATCH] usbnet: add support for some Huawei modems with cdc-ether ports
From: David Miller @ 2011-04-29 19:40 UTC (permalink / raw)
To: oneukum; +Cc: dcbw, netdev, linux-usb
In-Reply-To: <201104281046.47224.oneukum@suse.de>
From: Oliver Neukum <oneukum@suse.de>
Date: Thu, 28 Apr 2011 10:46:46 +0200
> Am Mittwoch, 27. April 2011, 21:54:28 schrieb Dan Williams:
>> Some newer Huawei devices (T-Mobile Rocket, others) have cdc-ether
>> compatible ports, so recognize and expose them.
>>
>> Signed-off-by: Dan Williams <dcbw@redhat.com>
>
> Acked-by: Oliver Neukum <oneukum@suse.de>
Applied.
^ permalink raw reply
* RE: [RFC PATCH] netlink: Increase netlink dump skb message size
From: Rose, Gregory V @ 2011-04-29 19:37 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, bhutchings@solarflare.com
In-Reply-To: <20110429.122940.179938280.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Friday, April 29, 2011 12:30 PM
> To: Rose, Gregory V
> Cc: netdev@vger.kernel.org; bhutchings@solarflare.com
> Subject: Re: [RFC PATCH] netlink: Increase netlink dump skb message size
>
> From: Greg Rose <gregory.v.rose@intel.com>
> Date: Mon, 25 Apr 2011 15:01:57 -0700
>
> > The message size allocated for rtnl info dumps was limited to a single
> page.
> > This is not enough for additional interface info available with devices
> > that support SR-IOV. Check that the amount of data allocated is
> sufficient
> > for the amount of data requested.
> >
> > Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
>
> Actually, thinking about this problem some more I think your approach
> is close to what we should actually do.
>
> The only problem is that you've specialized netlink_dump() too much,
> hide the issue in the rtnetlink device dumping code and provide
> the necessary information via the control block.
>
> 1) Add some information to struct netlink_callback.
>
> "u16 min_dump_alloc;"
>
> I think you can change "int family;" there to "u16 family;"
> so that there is no new space required to add this functionality.
>
> 2) In netlink_dump().
>
> int alloc_size;
>
> mutex_lock(nlk->cb_mutex);
> cb = nlk->cb;
> if (cb == NULL) {
> ...
> }
> alloc_size = max_t(int, cb->min_dump_alloc, NLMSG_GOODSIZE);
> skb = sock_rmalloc(sk, alloc_size, 0, GFP_KERNEL);
> if (!skb) {
> ...
>
> 3) In net/core/rtnetlink.c add a new method pointer to struct rtnl_link,
> "u16 (*calc_min_dump_alloc)(struct sk_buff *);"
> Add an implementation for the RTM_GETLINK slot.
>
> This function does the logic to compute the maximum space needed
> for the devices currently configured, as you hacked directly into
> the netlink_dump() logic in your match.
>
> 4) Make netlink_dump_start() take a new argument, this is where you
> pass the new min_dump_alloc value that will get stored in the
> newly allocated callback object.
>
> calcit = rtnl_get_calcit(family, type);
>
> min_dump_alloc = 0;
> if (calcit)
> min_dump_alloc = calcit(skb);
> err = netlink_dump_start(rtnl, skb, nlh, dumpit, min_dump_alloc,
> NULL);
>
> Anyways, something like that.
[Greg Rose]
I'll look into this and try to get a revised patch done by early next week.
The feedback and suggestions are much appreciated.
- Greg
^ permalink raw reply
* Re: [PATCH] bnx2: cancel timer on device removal
From: David Miller @ 2011-04-29 19:33 UTC (permalink / raw)
To: mchan; +Cc: nhorman, netdev
In-Reply-To: <1304104851.12355.125.camel@nseg_linux_HP1.broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Fri, 29 Apr 2011 12:20:51 -0700
>
> On Tue, 2011-04-26 at 13:30 -0700, Neil Horman wrote:
>> Fix the problem by ensuring that the timer is stopped when
>> pci_device_unregister
>> is called.
>>
>> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
>> Reported-by: Hushan Jia <hjia@redhat.com>
>> CC: Michael Chan <mchan@broadcom.com>
>> CC: "David S. Miller" <davem@davemloft.net>
>
> Thanks Neil.
>
> Acked-by: Michael Chan <mchan@broadcom.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH] net: ftmac100: fix scheduling while atomic during PHY link status change
From: David Miller @ 2011-04-29 19:31 UTC (permalink / raw)
To: adam.jaremko; +Cc: ratbert, ratbert.chuang, netdev
In-Reply-To: <BANLkTi=gcFB4mbmWKu4neep77Jp8R4HWGQ@mail.gmail.com>
From: Adam Jaremko <adam.jaremko@gmail.com>
Date: Tue, 26 Apr 2011 12:32:56 -0400
> @@ -801,7 +801,7 @@ static void ftmac100_mdio_write(struct net_device
> *netdev, int phy_id, int reg,
Your email client corrupted the patch, adding line breaks etc.
Please fix this problem, send a test email to yourself, try to apply
the patch you receive in that test email, and then when that is
working (and only then) resubmit this patch here so I can apply it.
Thanks.
^ permalink raw reply
* Re: [RFC PATCH] netlink: Increase netlink dump skb message size
From: David Miller @ 2011-04-29 19:29 UTC (permalink / raw)
To: gregory.v.rose; +Cc: netdev, bhutchings
In-Reply-To: <20110425220157.2012.96707.stgit@gitlad.jf.intel.com>
From: Greg Rose <gregory.v.rose@intel.com>
Date: Mon, 25 Apr 2011 15:01:57 -0700
> The message size allocated for rtnl info dumps was limited to a single page.
> This is not enough for additional interface info available with devices
> that support SR-IOV. Check that the amount of data allocated is sufficient
> for the amount of data requested.
>
> Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Actually, thinking about this problem some more I think your approach
is close to what we should actually do.
The only problem is that you've specialized netlink_dump() too much,
hide the issue in the rtnetlink device dumping code and provide
the necessary information via the control block.
1) Add some information to struct netlink_callback.
"u16 min_dump_alloc;"
I think you can change "int family;" there to "u16 family;"
so that there is no new space required to add this functionality.
2) In netlink_dump().
int alloc_size;
mutex_lock(nlk->cb_mutex);
cb = nlk->cb;
if (cb == NULL) {
...
}
alloc_size = max_t(int, cb->min_dump_alloc, NLMSG_GOODSIZE);
skb = sock_rmalloc(sk, alloc_size, 0, GFP_KERNEL);
if (!skb) {
...
3) In net/core/rtnetlink.c add a new method pointer to struct rtnl_link,
"u16 (*calc_min_dump_alloc)(struct sk_buff *);"
Add an implementation for the RTM_GETLINK slot.
This function does the logic to compute the maximum space needed
for the devices currently configured, as you hacked directly into
the netlink_dump() logic in your match.
4) Make netlink_dump_start() take a new argument, this is where you
pass the new min_dump_alloc value that will get stored in the
newly allocated callback object.
calcit = rtnl_get_calcit(family, type);
min_dump_alloc = 0;
if (calcit)
min_dump_alloc = calcit(skb);
err = netlink_dump_start(rtnl, skb, nlh, dumpit, min_dump_alloc, NULL);
Anyways, something like that.
^ permalink raw reply
* Re: [PATCH] bnx2: cancel timer on device removal
From: Michael Chan @ 2011-04-29 19:20 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev@vger.kernel.org, David S. Miller
In-Reply-To: <1303849811-29025-1-git-send-email-nhorman@tuxdriver.com>
On Tue, 2011-04-26 at 13:30 -0700, Neil Horman wrote:
> Fix the problem by ensuring that the timer is stopped when
> pci_device_unregister
> is called.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> Reported-by: Hushan Jia <hjia@redhat.com>
> CC: Michael Chan <mchan@broadcom.com>
> CC: "David S. Miller" <davem@davemloft.net>
Thanks Neil.
Acked-by: Michael Chan <mchan@broadcom.com>
> ---
> drivers/net/bnx2.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
> index bf729ee..7f76d4c 100644
> --- a/drivers/net/bnx2.c
> +++ b/drivers/net/bnx2.c
> @@ -8358,6 +8358,8 @@ bnx2_remove_one(struct pci_dev *pdev)
>
> unregister_netdev(dev);
>
> + del_timer_sync(&bp->timer);
> +
> if (bp->mips_firmware)
> release_firmware(bp->mips_firmware);
> if (bp->rv2p_firmware)
^ permalink raw reply
* Re: [PATCH] bnx2: cancel timer on device removal
From: Neil Horman @ 2011-04-29 19:09 UTC (permalink / raw)
To: netdev; +Cc: Michael Chan, David S. Miller
In-Reply-To: <1303849811-29025-1-git-send-email-nhorman@tuxdriver.com>
On Tue, Apr 26, 2011 at 04:30:11PM -0400, Neil Horman wrote:
> This oops was recently reported to me:
>
> invalid opcode: 0000 [#1] SMP
> last sysfs file:
> /sys/devices/pci0000:00/0000:00:01.0/0000:01:0d.0/0000:02:05.0/device
> CPU 1
> Modules linked in: bnx2(+) sunrpc ipv6 dm_mirror dm_region_hash dm_log sg
> microcode serio_raw amd64_edac_mod edac_core edac_mce_amd k8temp i2c_piix4
> shpchp ext4 mbcache jbd2 sd_mod crc_t10dif mptsas mptscsih mptbase
> scsi_transport_sas radeon ttm drm_kms_helper drm hwmon i2c_algo_bit i2c_core
> dm_mod [last unloaded: bnx2]
>
> Modules linked in: bnx2(+) sunrpc ipv6 dm_mirror dm_region_hash dm_log sg
> microcode serio_raw amd64_edac_mod edac_core edac_mce_amd k8temp i2c_piix4
> shpchp ext4 mbcache jbd2 sd_mod crc_t10dif mptsas mptscsih mptbase
> scsi_transport_sas radeon ttm drm_kms_helper drm hwmon i2c_algo_bit i2c_core
> dm_mod [last unloaded: bnx2]
> Pid: 23900, comm: pidof Not tainted 2.6.32-130.el6.x86_64 #1 BladeCenter LS21
> -[797251Z]-
> RIP: 0010:[<ffffffffa058b270>] [<ffffffffa058b270>] 0xffffffffa058b270
> RSP: 0018:ffff880002083e48 EFLAGS: 00010246
> RAX: ffff880002083e90 RBX: ffff88007ccd4000 RCX: 0000000000000000
> RDX: 0000000000000100 RSI: dead000000200200 RDI: ffff8800007b8700
> RBP: ffff880002083ed0 R08: ffff88000208db40 R09: 0000022d191d27c8
> R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800007b9bc8
> R13: ffff880002083e90 R14: ffff8800007b8700 R15: ffffffffa058b270
> FS: 00007fbb3bcf7700(0000) GS:ffff880002080000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000001664a98 CR3: 0000000060395000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process pidof (pid: 23900, threadinfo ffff8800007e8000, task ffff8800091c0040)
> Stack:
> ffffffff81079f77 ffffffff8109e010 ffff88007ccd5c20 ffff88007ccd5820
> <0> ffff88007ccd5420 ffff8800007e9fd8 ffff8800007e9fd8 0000010000000000
> <0> ffff88007ccd5020 ffff880002083e90 ffff880002083e90 ffffffff8102a00d
> Call Trace:
> <IRQ>
> [<ffffffff81079f77>] ? run_timer_softirq+0x197/0x340
> [<ffffffff8109e010>] ? tick_sched_timer+0x0/0xc0
> [<ffffffff8102a00d>] ? lapic_next_event+0x1d/0x30
> [<ffffffff8106f737>] __do_softirq+0xb7/0x1e0
> [<ffffffff81092cc0>] ? hrtimer_interrupt+0x140/0x250
> [<ffffffff81185f90>] ? filldir+0x0/0xe0
> [<ffffffff8100c2cc>] call_softirq+0x1c/0x30
> [<ffffffff8100df05>] do_softirq+0x65/0xa0
> [<ffffffff8106f525>] irq_exit+0x85/0x90
> [<ffffffff814e3340>] smp_apic_timer_interrupt+0x70/0x9b
> [<ffffffff8100bc93>] apic_timer_interrupt+0x13/0x20
> <EOI>
> [<ffffffff81211ba5>] ? selinux_file_permission+0x45/0x150
> [<ffffffff81262a75>] ? _atomic_dec_and_lock+0x55/0x80
> [<ffffffff812050c6>] security_file_permission+0x16/0x20
> [<ffffffff811861c1>] vfs_readdir+0x71/0xe0
> [<ffffffff81186399>] sys_getdents+0x89/0xf0
> [<ffffffff8100b172>] system_call_fastpath+0x16/0x1b
>
> It occured during some stress testing, in which the reporter was repeatedly
> removing and modprobing the bnx2 module while doing various other random
> operations on the bnx2 registered net device. Noting that this error occured on
> a serdes based device, we noted that there were a few ethtool operations (most
> notably self_test and set_phys_id) that have execution paths that lead into
> bnx2_setup_serdes_phy. This function is notable because it executes a mod_timer
> call, which starts the bp->timer running. Currently bnx2 is setup to assume
> that this timer only nees to be stopped when bnx2_close or bnx2_suspend is
> called. Since the above ethtool operations are not gated on the net device
> having been opened however, that assumption is incorrect, and can lead to the
> timer still running after the module has been removed, leading to the oops above
> (as well as other simmilar oopses).
>
> Fix the problem by ensuring that the timer is stopped when pci_device_unregister
> is called.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> Reported-by: Hushan Jia <hjia@redhat.com>
> CC: Michael Chan <mchan@broadcom.com>
> CC: "David S. Miller" <davem@davemloft.net>
> ---
> drivers/net/bnx2.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
> index bf729ee..7f76d4c 100644
> --- a/drivers/net/bnx2.c
> +++ b/drivers/net/bnx2.c
> @@ -8358,6 +8358,8 @@ bnx2_remove_one(struct pci_dev *pdev)
>
> unregister_netdev(dev);
>
> + del_timer_sync(&bp->timer);
> +
> if (bp->mips_firmware)
> release_firmware(bp->mips_firmware);
> if (bp->rv2p_firmware)
> --
> 1.7.4.4
>
> --
> 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
>
Ping, Michael?
Neil
^ permalink raw reply
* Re: Maximum no of bytes Ethernet can transfer at a time ??
From: Neil Horman @ 2011-04-29 19:06 UTC (permalink / raw)
To: Ajit; +Cc: netdev
In-Reply-To: <loom.20110429T103558-283@post.gmane.org>
On Fri, Apr 29, 2011 at 08:39:31AM +0000, Ajit wrote:
> Neil Horman <nhorman <at> tuxdriver.com> writes:
>
>
> > >
> > Can you just post a link to the code?
> > Neil
> >
> > > Thank you.
> > >
> > >
>
> here are the links to the code..
>
> sender code : http://pastebin.com/se17Xn96
>
> The command line arguments are like ./pgm_name eth0 /root/abc
>
> where abc is the file name.
>
> receiver code : http://pastebin.com/AKiUWzwR
>
> just run it.
>
> In the receiver code I have assigned offset to buffer[15], it was just for
> debugging purpose. Actually offset must have 16 bits of buffer[15] and
> buffer[16], but for files of around 100kb-200kb it will easily work..no need to
> modify.
>
> Thank you.
>
Well, just looking at it, I presume you're getting an error on send when you
send over your raw socket. If so, whats the error you're getting? If you're
not getting an error, then you're dropping it somewhere in the stack. After you
loose the data in question, what do youre /proc/net/dev and ethtool stats look
like?
Neil
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 0/3] net: Byte queue limit patch series
From: David Miller @ 2011-04-29 18:54 UTC (permalink / raw)
To: therbert; +Cc: netdev
In-Reply-To: <alpine.DEB.2.00.1104252128001.5889@pokey.mtv.corp.google.com>
From: Tom Herbert <therbert@google.com>
Date: Mon, 25 Apr 2011 21:38:06 -0700 (PDT)
> This patch series implements byte queue limits (bql) for NIC TX queues.
I like the idea, I don't like how much drivers have to be involved
in this.
TX queue handling is already too involved for driver writers, so
having them need to get all of these new hooks right is a non-starter.
I don't even think it's necessary to be honest, I think you can hide
to bulk of it.
alloc_etherdev_mq() can initialize the per-txq bql instances.
Add new interface, netdev_free_tx_skb(txq, skb) which can do the
completion accounting. Actually the 'txq' argument is probably
superfluous as it can be obtained from the skb itself.
dev_hard_start_xmit() can do the "sent" processing.
Then the only thing you're doing is replacing dev_kfree_skb*()
in the TX path of the driver with the new netdev_free_tx_skb()
thing.
Maybe you can add a "netdev_tx_queue_reset()" hook for asynchronous
device resets. Otherwise the bql reset can occur in generic code
right at ->ndo_open().
Finally, you manage the bql limit logic in the existing generic netdev
TX start/stop interfaces. If the user asks for "start" but the bql
is overlimit, simply ignore the request. The driver will just signal
another "start" when the next TX packet completes.
Similarly, when the qdisc is queuing up a packet to
dev_hard_start_xmit() you can, for example, preemptively do a "stop"
on the queue if you find bql is overlimit.
Thanks Tom.
^ permalink raw reply
* Re: [PATCH NEXT 1/1] net: create num frags requested
From: David Miller @ 2011-04-29 18:37 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman
In-Reply-To: <1303525340-29483-1-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Fri, 22 Apr 2011 19:22:20 -0700
> Pktgen doesn't generate number of frags requested.
> Divide packet size by number of frags and fill that in every frags.
>
> Example:
> With packet size 1470, it generate only 11 frags. Initial frags
> get lenght 706, 353, 177....so on. Last frag get divided by 2.
>
> Now with this fix, each frags will get 78 bytes.
>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/2] tg3: Add code to allow ethtool to enable/disable loopback.
From: Mahesh Bandewar @ 2011-04-29 17:45 UTC (permalink / raw)
To: Matt Carlson
Cc: David Miller, netdev, Michael Chan, Ben Hutchings,
Micha? Miros?aw
In-Reply-To: <20110429024652.GB20805@mcarlson.broadcom.com>
On Thu, Apr 28, 2011 at 7:46 PM, Matt Carlson <mcarlson@broadcom.com> wrote:
> On Thu, Apr 28, 2011 at 06:42:02PM -0700, Mahesh Bandewar wrote:
>> >> + ? ? spin_unlock_bh(&tp->lock);
>> >> +
>> >> + ? ? return err;
>> >> +}
>> >> +
>> >> ?static inline void tg3_set_mtu(struct net_device *dev, struct tg3 *tp,
>> >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?int new_mtu)
>> >> ?{
>> >> @@ -15028,6 +15055,7 @@ static const struct net_device_ops tg3_netdev_ops = {
>> >> ? ? ? .ndo_tx_timeout ? ? ? ? = tg3_tx_timeout,
>> >> ? ? ? .ndo_change_mtu ? ? ? ? = tg3_change_mtu,
>> >> ? ? ? .ndo_fix_features ? ? ? = tg3_fix_features,
>> >> + ? ? .ndo_set_features ? ? ? = tg3_set_features,
>> >> ?#ifdef CONFIG_NET_POLL_CONTROLLER
>> >> ? ? ? .ndo_poll_controller ? ?= tg3_poll_controller,
>> >> ?#endif
>> >> @@ -15044,6 +15072,7 @@ static const struct net_device_ops tg3_netdev_ops_dma_bug = {
>> >> ? ? ? .ndo_do_ioctl ? ? ? ? ? = tg3_ioctl,
>> >> ? ? ? .ndo_tx_timeout ? ? ? ? = tg3_tx_timeout,
>> >> ? ? ? .ndo_change_mtu ? ? ? ? = tg3_change_mtu,
>> >> + ? ? .ndo_set_features ? ? ? = tg3_set_features,
>> >> ?#ifdef CONFIG_NET_POLL_CONTROLLER
>> >> ? ? ? .ndo_poll_controller ? ?= tg3_poll_controller,
>> >> ?#endif
>> >> @@ -15241,6 +15270,9 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
>> >> ? ? ? dev->features |= hw_features;
>> >> ? ? ? dev->vlan_features |= hw_features;
>> >>
>> >> + ? ? /* Add the loopback capability */
>> >> + ? ? dev->hw_features |= NETIF_F_LOOPBACK;
>> >
>> > Not all tg3 devices can do MAC loopback. ?I'd suggest qualifying this
>> > with:
>> >
>> > ? ? ? ? ? ? ? ?if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5780 ||
>> > ? ? ? ? ? ? ? ? ? ?(tp->tg3_flags & TG3_FLAG_CPMU_PRESENT))
>> >
>> > But that will exclude a lot of our newer devices. ?Does it matter what
>> > type of loopback is used? ?Newer devices prefer internal phy loopback
>> > over MAC loopback.
>> >
>> As long as device supports some sort of loopback, we should be setting
>> this capability and move this logic (or similar) to set_features() and
>> choose the method that is supported. Since several devices support
>> loopback at various levels, to keep it consistent, we should be
>> setting the loopback closest to the host. So can I simply set the
>> int-phy loopback in the else part of the above 'provided if' or would
>> need other logic? or in other words -
>>
>> if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5780 ||
>> (tp->tg3_flags & TG3_FLAG_CPMU_PRESENT))
>> supported_mode = MAC;
>> else
>> supported_mode = INTPHY;
>>
>> if (supported_mode == MAC)
>> cur_mode = tr32(MAC_MODE);
>> else
>> tg3_readphy(tp, MII_BMCR, &cur_mode);
>>
>> Would something like this work?
>
> That might be where we want to end up, but it'll be some work to get
> there. Maybe it makes sense to just keep MAC loopback mode for now and
> only enable it for a subset of devices. Adding phy loopback mode sounds
> like it will require some surgery.
>
Thanks for your comments Matt, I'll post the updated patch soon.
--mahesh..
>
^ permalink raw reply
* [PATCH 10/10] ipv4: Get route daddr from flow key in l2tp_ip_connect().
From: David Miller @ 2011-04-29 17:27 UTC (permalink / raw)
To: netdev
Now that output route lookups update the flow with
destination address selection, we can fetch it from
fl4->daddr instead of rt->rt_dst
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/l2tp/l2tp_ip.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/l2tp/l2tp_ip.c b/net/l2tp/l2tp_ip.c
index c100fa9..a4d2dfa 100644
--- a/net/l2tp/l2tp_ip.c
+++ b/net/l2tp/l2tp_ip.c
@@ -343,7 +343,7 @@ static int l2tp_ip_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len
inet->inet_saddr = fl4.saddr;
if (!inet->inet_rcv_saddr)
inet->inet_rcv_saddr = fl4.saddr;
- inet->inet_daddr = rt->rt_dst;
+ inet->inet_daddr = fl4.daddr;
sk->sk_state = TCP_ESTABLISHED;
inet->inet_id = jiffies;
--
1.7.4.5
^ permalink raw reply related
* [PATCH 9/10] ipv4: Get route daddr from flow key in tcp_v4_connect().
From: David Miller @ 2011-04-29 17:27 UTC (permalink / raw)
To: netdev
Now that output route lookups update the flow with
destination address selection, we can fetch it from
fl4->daddr instead of rt->rt_dst
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/ipv4/tcp_ipv4.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 3be00af..f3d16d8 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -190,7 +190,7 @@ int tcp_v4_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
}
if (!inet_opt || !inet_opt->opt.srr)
- daddr = rt->rt_dst;
+ daddr = fl4.daddr;
if (!inet->inet_saddr)
inet->inet_saddr = fl4.saddr;
@@ -204,7 +204,7 @@ int tcp_v4_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
}
if (tcp_death_row.sysctl_tw_recycle &&
- !tp->rx_opt.ts_recent_stamp && rt->rt_dst == daddr) {
+ !tp->rx_opt.ts_recent_stamp && fl4.daddr == daddr) {
struct inet_peer *peer = rt_get_peer(rt);
/*
* VJ's idea. We save last timestamp seen from
--
1.7.4.5
^ permalink raw reply related
* [PATCH 8/10] ipv4: Get route daddr from flow key in inet_csk_route_req().
From: David Miller @ 2011-04-29 17:27 UTC (permalink / raw)
To: netdev
Now that output route lookups update the flow with
destination address selection, we can fetch it from
fl4->daddr instead of rt->rt_dst
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/ipv4/inet_connection_sock.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index 3282cb2..54944da 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -367,7 +367,7 @@ struct dst_entry *inet_csk_route_req(struct sock *sk,
rt = ip_route_output_flow(net, &fl4, sk);
if (IS_ERR(rt))
goto no_route;
- if (opt && opt->opt.is_strictroute && rt->rt_dst != rt->rt_gateway)
+ if (opt && opt->opt.is_strictroute && fl4.daddr != rt->rt_gateway)
goto route_err;
return &rt->dst;
--
1.7.4.5
^ permalink raw reply related
* [PATCH 7/10] ipv4: Get route daddr from flow key in ip4_datagram_connect().
From: David Miller @ 2011-04-29 17:27 UTC (permalink / raw)
To: netdev
Now that output route lookups update the flow with
destination address selection, we can fetch it from
fl4->daddr instead of rt->rt_dst
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/ipv4/datagram.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/datagram.c b/net/ipv4/datagram.c
index b7f583c..d5a2e69 100644
--- a/net/ipv4/datagram.c
+++ b/net/ipv4/datagram.c
@@ -69,7 +69,7 @@ int ip4_datagram_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
if (sk->sk_prot->rehash)
sk->sk_prot->rehash(sk);
}
- inet->inet_daddr = rt->rt_dst;
+ inet->inet_daddr = fl4.daddr;
inet->inet_dport = usin->sin_port;
sk->sk_state = TCP_ESTABLISHED;
inet->inet_id = jiffies;
--
1.7.4.5
^ permalink raw reply related
* [PATCH 6/10] ipv4: Get route daddr from flow key in dccp_v4_connect().
From: David Miller @ 2011-04-29 17:27 UTC (permalink / raw)
To: netdev
Now that output route lookups update the flow with
destination address selection, we can fetch it from
fl4->daddr instead of rt->rt_dst
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/dccp/ipv4.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/dccp/ipv4.c b/net/dccp/ipv4.c
index cbbcc6c..f4254bb 100644
--- a/net/dccp/ipv4.c
+++ b/net/dccp/ipv4.c
@@ -83,7 +83,7 @@ int dccp_v4_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
}
if (inet_opt == NULL || !inet_opt->opt.srr)
- daddr = rt->rt_dst;
+ daddr = fl4.daddr;
if (inet->inet_saddr == 0)
inet->inet_saddr = rt->rt_src;
--
1.7.4.5
^ permalink raw reply related
* [PATCH 5/10] ipv4: Fetch route saddr from flow key in l2tp_ip_connect().
From: David Miller @ 2011-04-29 17:27 UTC (permalink / raw)
To: netdev
Now that output route lookups update the flow with
source address selection, we can fetch it from
fl4->saddr instead of rt->rt_src
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/l2tp/l2tp_ip.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/l2tp/l2tp_ip.c b/net/l2tp/l2tp_ip.c
index e13c166..c100fa9 100644
--- a/net/l2tp/l2tp_ip.c
+++ b/net/l2tp/l2tp_ip.c
@@ -340,9 +340,9 @@ static int l2tp_ip_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len
l2tp_ip_sk(sk)->peer_conn_id = lsa->l2tp_conn_id;
if (!inet->inet_saddr)
- inet->inet_saddr = rt->rt_src;
+ inet->inet_saddr = fl4.saddr;
if (!inet->inet_rcv_saddr)
- inet->inet_rcv_saddr = rt->rt_src;
+ inet->inet_rcv_saddr = fl4.saddr;
inet->inet_daddr = rt->rt_dst;
sk->sk_state = TCP_ESTABLISHED;
inet->inet_id = jiffies;
--
1.7.4.5
^ permalink raw reply related
* [PATCH 4/10] ipv4: Fetch route saddr from flow key in tcp_v4_connect().
From: David Miller @ 2011-04-29 17:27 UTC (permalink / raw)
To: netdev
Now that output route lookups update the flow with
source address selection, we can fetch it from
fl4->saddr instead of rt->rt_src
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/ipv4/tcp_ipv4.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index d60732f..3be00af 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -193,7 +193,7 @@ int tcp_v4_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
daddr = rt->rt_dst;
if (!inet->inet_saddr)
- inet->inet_saddr = rt->rt_src;
+ inet->inet_saddr = fl4.saddr;
inet->inet_rcv_saddr = inet->inet_saddr;
if (tp->rx_opt.ts_recent_stamp && inet->inet_daddr != daddr) {
--
1.7.4.5
^ permalink raw reply related
* [PATCH 3/10] ipv4: Fetch route saddr from flow key in ip4_datagram_connect().
From: David Miller @ 2011-04-29 17:27 UTC (permalink / raw)
To: netdev
Now that output route lookups update the flow with
source address selection, we can fetch it from
fl4->saddr instead of rt->rt_src
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/ipv4/datagram.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/datagram.c b/net/ipv4/datagram.c
index 216ba23..b7f583c 100644
--- a/net/ipv4/datagram.c
+++ b/net/ipv4/datagram.c
@@ -63,9 +63,9 @@ int ip4_datagram_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
return -EACCES;
}
if (!inet->inet_saddr)
- inet->inet_saddr = rt->rt_src; /* Update source address */
+ inet->inet_saddr = fl4.saddr; /* Update source address */
if (!inet->inet_rcv_saddr) {
- inet->inet_rcv_saddr = rt->rt_src;
+ inet->inet_rcv_saddr = fl4.saddr;
if (sk->sk_prot->rehash)
sk->sk_prot->rehash(sk);
}
--
1.7.4.5
^ permalink raw reply related
* [PATCH 2/10] ipv4: Fetch route saddr from flow key in inet_sk_reselect_saddr().
From: David Miller @ 2011-04-29 17:26 UTC (permalink / raw)
To: netdev
Now that output route lookups update the flow with
source address selection, we can fetch it from
fl4->saddr instead of rt->rt_src
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/ipv4/af_inet.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 963a621..4e73499 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1122,7 +1122,7 @@ static int inet_sk_reselect_saddr(struct sock *sk)
sk_setup_caps(sk, &rt->dst);
- new_saddr = rt->rt_src;
+ new_saddr = fl4.saddr;
if (new_saddr == old_saddr)
return 0;
--
1.7.4.5
^ permalink raw reply related
* [PATCH 1/10] ipv4: Remove now superfluous code in ip_route_connect().
From: David Miller @ 2011-04-29 17:26 UTC (permalink / raw)
To: netdev
Now that output route lookups update the flow with
source address et al. selections, the fl4->{saddr,daddr}
assignments here are no longer necessary.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/net/route.h | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/include/net/route.h b/include/net/route.h
index 81b6cf2..16eb59c 100644
--- a/include/net/route.h
+++ b/include/net/route.h
@@ -271,8 +271,6 @@ static inline struct rtable *ip_route_connect(struct flowi4 *fl4,
rt = __ip_route_output_key(net, fl4);
if (IS_ERR(rt))
return rt;
- fl4->daddr = rt->rt_dst;
- fl4->saddr = rt->rt_src;
ip_rt_put(rt);
}
security_sk_classify_flow(sk, flowi4_to_flowi(fl4));
--
1.7.4.5
^ permalink raw reply related
* [PATCH 0/10] ipv4: Fetch values from flow key not route.
From: David Miller @ 2011-04-29 17:26 UTC (permalink / raw)
To: netdev
Here is the first set of simplifications that are possible now that
output route lookup will update the flow lookup key the caller passes
in.
Signed-off-by: David S. Miller <davem@davemloft.net>
^ 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