* Re: OOM when adding ipv6 route: How to make available more per-cpu memory?
From: Ben Greear @ 2010-11-05 20:26 UTC (permalink / raw)
To: Eric Dumazet; +Cc: NetDev, linux-kernel, Tejun Heo
In-Reply-To: <1288988403.2665.268.camel@edumazet-laptop>
On 11/05/2010 01:20 PM, Eric Dumazet wrote:
> Your vmalloc space is very fragmented. pcpu_get_vm_areas() want
> hugepages (4MB on your machine, 2MB on mine because I have
> CONFIG_HIGHMEM64G=y)
>
> You could :
>
> 1) Use a 64 bit kernel ( :) )
We mostly use 64-bit, but just not for the remastered live cd image.
> or
>
> 2) boot parameter vmalloc=256M to get more room
> (default is 128 Mbytes)
We'll try that.
>
> and eventually
>
> select a 2G/2G User/Kernel split to get more LOWMEM, because big vmalloc
> windows shrinks the LOWMEM zone. (CONFIG_VMSPLIT_2G=y)
That sounds promising as well.
I was also wondering if it would make sense to allow one to disable
the snmp stats for ipv6? I don't think I have any use for those
stats anyway..
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: ping -I eth1 ....
From: Thomas Graf @ 2010-11-05 20:31 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Eric Dumazet, netdev
In-Reply-To: <OFAA7963DE.C3F04675-ONC12577D2.0056F55C-C12577D2.00575EC2@transmode.se>
On Fri, Nov 05, 2010 at 04:54:18PM +0100, Joakim Tjernlund wrote:
> Eric Dumazet <eric.dumazet@gmail.com> wrote on 2010/11/05 16:06:54:
> >
> > > Hopefully most of that is legacy or just plain wrong? Unless
> > > someone can say why only test IFF_UP one should consider changing them.
> > >
> >
> > Most of the places are hot path.
> >
> > You dont want to replace one test by four tests.
> >
> > _This_ would be wrong :)
>
> Wrong is wrong, even if it is in the hot path :)
> Perhaps it is time define and internal IFF_OPERATIONAL flag
> which is the sum of IFF_UP, IFF_RUNNING etc.? Tht
> way you still get one test in the hot path and can abstract
> what defines an operational link.
You definitely don't want to have your send() call fail simply because
the carrier was off for a few msec or the routing daemon has put a link
down temporarly. Also, the outgoing interface looked up at routing
decision is not necessarly the interface used for sending in the end.
The packet may get mangled and rerouted by netfilter or tc on the way.
Personally I'm even ok with the current behaviour of sendto() while the
socket is bound to an interface but if we choose to return an error
if the interface is down we might as well do so based on the operational
status.
^ permalink raw reply
* Re: OOM when adding ipv6 route: How to make available more per-cpu memory?
From: Eric Dumazet @ 2010-11-05 20:53 UTC (permalink / raw)
To: Ben Greear; +Cc: NetDev, linux-kernel, Tejun Heo
In-Reply-To: <4CD46892.6050408@candelatech.com>
Le vendredi 05 novembre 2010 à 13:26 -0700, Ben Greear a écrit :
>
> I was also wondering if it would make sense to allow one to disable
> the snmp stats for ipv6? I don't think I have any use for those
> stats anyway..
>
I agree. IPV6 have per device SNMP fields, percpu... thats probably not
needed.
We have many SNMP fields that could avoid being percpu, even for ipv4.
^ permalink raw reply
* @see this
From: customerscare_msn> @ 2010-11-05 21:13 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 26 bytes --]
see the file attached
[-- Attachment #2: YOU HAVE WON A PRIZE-1.doc --]
[-- Type: application/msword, Size: 247808 bytes --]
^ permalink raw reply
* radvd and auto-ipv6 address regression from 2.6.31 to 2.6.34+
From: Ben Greear @ 2010-11-05 21:24 UTC (permalink / raw)
To: NetDev
I'm seeing something strange. I'm running radvd on a VETH interface (veth0 for argument)
with a single global IPv6 address (and a link-local address).
On hacked 2.6.31, this works as I expect: The veth0 interface does not gain or lose any
IPv6 addresses and peer VETH port gets an auto-created IPv6 addresses.
On hacked 2.6.34 and 2.6.36 kernels, however, the veth0 gains a new address that appears
to be generated similar to other IPs associated with auto-creation via radvd.
I have not yet tested intervening kernels or physical interfaces between two machines.
So, the question is: Is the new behaviour on purpose, or is it a regression bug?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: OOM when adding ipv6 route: How to make available more per-cpu memory?
From: Eric Dumazet @ 2010-11-05 22:11 UTC (permalink / raw)
To: Ben Greear; +Cc: NetDev, linux-kernel, Tejun Heo
In-Reply-To: <1288988403.2665.268.camel@edumazet-laptop>
Le vendredi 05 novembre 2010 à 21:20 +0100, Eric Dumazet a écrit :
> Your vmalloc space is very fragmented. pcpu_get_vm_areas() want
> hugepages (4MB on your machine, 2MB on mine because I have
> CONFIG_HIGHMEM64G=y)
Well, this is wrong. We use normal (4KB) pages, unfortunately.
I have a NUMA machine, with two nodes, so pcpu_get_vm_areas() allocates
two zones, one for each node, with a 'known' offset between them.
Then, 4KB pages are allocated to populate the zone when needed.
# grep pcpu_get_vm_areas /proc/vmallocinfo
0xffffe8ffa0400000-0xffffe8ffa0600000 2097152 pcpu_get_vm_areas+0x0/0x740 vmalloc
0xffffe8ffffc00000-0xffffe8ffffe00000 2097152 pcpu_get_vm_areas+0x0/0x740 vmalloc
BTW, we dont have the number of pages currently allocated in each
'vmalloc' zone, and/or node information.
Tejun, do you have plans to use hugepages eventually ?
(and fallback to 4KB pages, but most percpu data are allocated right
after boot)
Thanks
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2010-11-05 22:14 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
Here are the bug fixes that have queued up since -rc1,
several "touches netdev queue before device registry"
cases as well as the "net dst" percpu fixup you want
to see merged ASAP.
Please pull, thanks a lot!
The following changes since commit ff8b16d7e15a8ba2a6086645614a483e048e3fbf:
vmstat: fix offset calculation on void* (2010-11-03 14:39:58 -0400)
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
Amerigo Wang (1):
netxen: remove unused firmware exports
André Carvalho de Matos (1):
caif: Bugfix for socket priority, bindtodev and dbg channel.
David S. Miller (2):
ibm_newemac: Remove netif_stop_queue() in emac_probe().
Merge branch 'master' of git://git.kernel.org/.../kaber/nf-2.6
Divy Le Ray (3):
cxgb3: remove call to stop TX queues at load time.
cxgb4: remove call to stop TX queues at load time.
cxgb4vf: remove call to stop TX queues at load time.
Dmitry Artamonow (1):
USB: gadget: fix ethernet gadget crash in gether_setup
Dr. David Alan Gilbert (1):
l2tp: kzalloc with swapped params in l2tp_dfs_seq_open
Eric Dumazet (7):
netfilter: nf_conntrack: allow nf_ct_alloc_hashtable() to get highmem pages
netfilter: fix nf_conntrack_l4proto_register()
jme: fix panic on load
qlcnic: fix panic on load
atl1 : fix panic on load
de2104x: fix panic on load
fib: fib_result_assign() should not change fib refcounts
Herbert Xu (1):
cls_cgroup: Fix crash on module unload
Jan Engelhardt (1):
netfilter: ip6_tables: fix information leak to userspace
John Faith (1):
smsc911x: Set Ethernet EEPROM size to supported device's size
Ming Lei (1):
usbnet: fix usb_autopm_get_interface failure(v1)
Nelson Elhage (2):
netlink: Make nlmsg_find_attr take a const nlmsghdr*.
inet_diag: Make sure we actually run the same bytecode we audited.
Patrick McHardy (1):
netfilter: nf_nat: fix compiler warning with CONFIG_NF_CT_NETLINK=n
Pavel Emelyanov (2):
rds: Lost locking in loop connection freeing
rds: Remove kfreed tcp conn from list
Sjur Brændeland (1):
caif: SPI-driver bugfix - incorrect padding.
Thomas Graf (1):
text ematch: check for NULL pointer before destroying textsearch config
Tom Herbert (1):
net: check queue_index from sock is valid for device
Uwe Kleine-König (1):
trivial: fix typos concerning "function"
Vasiliy Kulikov (2):
ipv4: netfilter: arp_tables: fix information leak to userland
ipv4: netfilter: ip_tables: fix information leak to userland
Xiaotian Feng (1):
net dst: fix percpu_counter list corruption and poison overwritten
Yaniv Rosner (8):
bnx2x: Restore appropriate delay during BMAC reset
bnx2x: Fix waiting for reset complete on BCM848x3 PHYs
bnx2x: Fix port selection in case of E2
bnx2x: Clear latch indication on link reset
bnx2x: Fix resetting BCM8726 PHY during common init
bnx2x: Do not enable CL37 BAM unless it is explicitly enabled
bnx2x: Reset 8073 phy during common init
bnx2x: Update version number
andrew hendry (1):
memory corruption in X.25 facilities parsing
sjur.brandeland@stericsson.com (1):
caif: Remove noisy printout when disconnecting caif socket
drivers/isdn/hisax/isar.c | 4 +-
drivers/net/atlx/atl1.c | 1 -
drivers/net/bnx2x/bnx2x.h | 4 +-
drivers/net/bnx2x/bnx2x_hsi.h | 9 +++++-
drivers/net/bnx2x/bnx2x_link.c | 57 +++++++++++++++++++++++++---------
drivers/net/caif/caif_spi.c | 57 +++++++++++++++++++++++++---------
drivers/net/caif/caif_spi_slave.c | 13 +++++--
drivers/net/cxgb3/cxgb3_main.c | 1 -
drivers/net/cxgb4/cxgb4_main.c | 1 -
drivers/net/cxgb4vf/cxgb4vf_main.c | 1 -
drivers/net/ibm_newemac/core.c | 1 -
drivers/net/jme.c | 4 --
drivers/net/netxen/netxen_nic_main.c | 3 --
drivers/net/qlcnic/qlcnic_main.c | 1 -
drivers/net/smsc911x.h | 2 +-
drivers/net/tulip/de2104x.c | 1 -
drivers/net/usb/usbnet.c | 11 ++++++
drivers/usb/gadget/u_ether.c | 1 -
include/net/caif/caif_dev.h | 4 +-
include/net/caif/caif_spi.h | 2 +
include/net/caif/cfcnfg.h | 8 ++--
include/net/netlink.h | 2 +-
net/caif/caif_config_util.c | 13 ++++++--
net/caif/caif_dev.c | 2 +
net/caif/caif_socket.c | 45 +++++++++------------------
net/caif/cfcnfg.c | 17 ++++------
net/caif/cfctrl.c | 3 +-
net/caif/cfdbgl.c | 14 ++++++++
net/caif/cfrfml.c | 2 +-
net/core/dev.c | 2 +-
net/ipv4/fib_lookup.h | 5 +--
net/ipv4/inet_diag.c | 27 +++++++++------
net/ipv4/netfilter/arp_tables.c | 1 +
net/ipv4/netfilter/ip_tables.c | 1 +
net/ipv4/netfilter/nf_nat_core.c | 40 ++++++++++++------------
net/ipv6/netfilter/ip6_tables.c | 1 +
net/ipv6/route.c | 2 +
net/l2tp/l2tp_debugfs.c | 2 +-
net/netfilter/nf_conntrack_core.c | 3 +-
net/netfilter/nf_conntrack_proto.c | 6 +++
net/rds/loop.c | 4 ++
net/rds/tcp.c | 6 +++
net/sched/cls_cgroup.c | 2 -
net/sched/em_text.c | 3 +-
net/x25/x25_facilities.c | 8 ++--
net/x25/x25_in.c | 2 +
46 files changed, 246 insertions(+), 153 deletions(-)
^ permalink raw reply
* RE: [PATCH 1/2] ixgb: Don't check for vlan group on transmit.
From: Duyck, Alexander H @ 2010-11-05 22:30 UTC (permalink / raw)
To: Kirsher, Jeffrey T, Jesse Gross
Cc: David Miller, netdev@vger.kernel.org, Brandeburg, Jesse
In-Reply-To: <1288987609.3091.16.camel@jtkirshe-MOBL1>
>-----Original Message-----
>From: Kirsher, Jeffrey T
>Sent: Friday, November 05, 2010 1:07 PM
>To: Jesse Gross
>Cc: David Miller; netdev@vger.kernel.org; Brandeburg, Jesse; Duyck,
>Alexander H
>Subject: Re: [PATCH 1/2] ixgb: Don't check for vlan group on transmit.
>
>On Fri, 2010-11-05 at 12:56 -0700, Jesse Gross wrote:
>> On Fri, Nov 5, 2010 at 12:11 PM, Jeff Kirsher
>> <jeffrey.t.kirsher@intel.com> wrote:
>> > On Sat, 2010-10-30 at 11:49 -0700, Jesse Gross wrote:
>> >> On transmit, the ixgb driver will only use vlan acceleration if a
>> >> vlan group is configured. This can lead to tags getting dropped
>> >> when bridging because the networking core assumes that a driver
>> >> that claims vlan acceleration support can do it at all times.
>This
>> >> change should have been part of commit eab6d18d "vlan: Don't
>check for
>> >> vlan group before vlan_tx_tag_present." but was missed.
>> >>
>> >> Signed-off-by: Jesse Gross <jesse@nicira.com>
>> >> CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>> >> CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
>> >> CC: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
>> >> ---
>> >> drivers/net/ixgb/ixgb_main.c | 2 +-
>> >> 1 files changed, 1 insertions(+), 1 deletions(-)
>> >>
>> >> diff --git a/drivers/net/ixgb/ixgb_main.c
>b/drivers/net/ixgb/ixgb_main.c
>> >> index caa8192..d18194e 100644
>> >> --- a/drivers/net/ixgb/ixgb_main.c
>> >> +++ b/drivers/net/ixgb/ixgb_main.c
>> >> @@ -1498,7 +1498,7 @@ ixgb_xmit_frame(struct sk_buff *skb, struct
>net_device *netdev)
>> >> DESC_NEEDED)))
>> >> return NETDEV_TX_BUSY;
>> >>
>> >> - if (adapter->vlgrp && vlan_tx_tag_present(skb)) {
>> >> + if (vlan_tx_tag_present(skb)) {
>> >> tx_flags |= IXGB_TX_FLAGS_VLAN;
>> >> vlan_id = vlan_tx_tag_get(skb);
>> >> }
>> >
>> > After further review, NAK because this will cause a bug. With
>this
>> > patch it would be possible to overrun the buffers, so the correct
>fix is
>> > to increase max_frame_size by VLAN_TAG_SIZE in
>ixgb/igb_change_mtu.
>>
>> Hmm, I didn't see any other place where it made changes to the
>> handling of packets on transmit if a vlan group is configured.
>Maybe
>> the buffer is extended when a group is registered and stripping is
>> enabled?
>>
>> In any case, you might want to check the other Intel drivers for
>> similar problems. I did a pass and made a mass conversion of this
>> type a little while ago. Those changes have already been merged, I
>> just missed this one by accident.
>
>I will get with Alex and review the other Intel drivers, thanks Jesse.
Just to make things clear. The ixgb patch is fine. There isn't anything wrong with it.
The patch with the bug is the other patch, "2/2 igb: Don't depend on VLAN group for receive size". The problem is it was updating the RLPML register, but not updating the buffer sizes as such there were a few cases where we could receive a buffer larger the SKB head room. The bug itself probably won't come up very often since there are only a couple of very specific MTU sizes where it will be an issue.
The quick fix for your patch is to move the addition of VLAN_TAG_SIZE to the max_frame in igb_change_mtu instead of in the set_rlpml call. Otherwise I will see about submitting an updated patch in the next few days.
Thanks,
Alex
^ permalink raw reply
* Sky2 - problems with VLANs - kernel 2.6.36
From: David @ 2010-11-05 23:06 UTC (permalink / raw)
To: netdev, Linux Kernel Mailing List
I've just installed a Lycom dual port gigabit ethernet card, picked up
as follows :-
03:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8062 PCI-E
IPMI Gigabit Ethernet Controller (rev 14)
Subsystem: Marvell Technology Group Ltd. Device 6222
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 41
Region 0: Memory at fe8fc000 (64-bit, non-prefetchable) [size=16K]
Region 2: I/O ports at c800 [size=256]
Expansion ROM at fe8c0000 [disabled] [size=128K]
Capabilities: <access denied>
Kernel driver in use: sky2
Kernel modules: sky2
I'm having a problem with VLANs. Outgoing packets are tagged correctly
and devices on the VLAN are responding. Unfortunately all of the
response packets stay on the raw device and are not allocated to the VLAN.
I've done some investigation (printks etc.), and have found that neither
of the following cases in sky2_status_intr() are being triggered...
case OP_RXVLAN:
printk("RXVLAN, length=%u, status=%u\n", length,
status);
sky2->rx_tag = length;
break;
case OP_RXCHKSVLAN:
printk("RXCHKSVLAN, length=%u, status=%u\n",
length, status);
sky2->rx_tag = length;
/* fall through */
... however the status when calling sky2_skb_rx() does have GMR_FS_VLAN
set, it's just we haven't been able to find out which VLAN the packet
comes from (and sky2->rx_tag is zero). Does anyone have any suggestions
as to how I proceed from here? I'm happy to test patches etc.
Cheers
David
^ permalink raw reply
* [PATCH 0/7] Convert sprintf_symbol uses to %p[Ss]
From: Joe Perches @ 2010-11-05 23:12 UTC (permalink / raw)
To: Jiri Kosina
Cc: linux-arm-kernel, linux-kernel, cluster-devel, linux-mm,
linux-nfs, netdev
Remove unnecessary declarations of temporary buffers.
Use %pS or %ps as appropriate.
Minor reformatting in a couple of places.
Compiled, but otherwise untested.
Joe Perches (7):
arch/arm/kernel/traps.c: Convert sprintf_symbol to %pS
arch/x86/kernel/pci-iommu_table.c: Convert sprintf_symbol to %pS
fs/gfs2/glock.c: Convert sprintf_symbol to %pS
fs/proc/base.c kernel/latencytop.c: Convert sprintf_symbol to %ps
kernel/lockdep_proc.c: Convert sprintf_symbol to %pS
mm: Convert sprintf_symbol to %pS
net/sunrpc/clnt.c: Convert sprintf_symbol to %ps
arch/arm/kernel/traps.c | 5 +----
arch/x86/kernel/pci-iommu_table.c | 18 ++++--------------
fs/gfs2/glock.c | 15 +++++++--------
fs/proc/base.c | 22 ++++++++--------------
kernel/latencytop.c | 23 +++++++++--------------
kernel/lockdep_proc.c | 16 ++++++----------
mm/slub.c | 11 ++++-------
mm/vmalloc.c | 9 ++-------
net/sunrpc/clnt.c | 12 ++----------
9 files changed, 43 insertions(+), 88 deletions(-)
--
1.7.3.2.146.gca209
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH 7/7] net/sunrpc/clnt.c: Convert sprintf_symbol to %ps
From: Joe Perches @ 2010-11-05 23:12 UTC (permalink / raw)
To: Jiri Kosina
Cc: J. Bruce Fields, Neil Brown, Trond Myklebust, David S. Miller,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1288998760-11775-1-git-send-email-joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
Signed-off-by: Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
---
net/sunrpc/clnt.c | 12 ++----------
1 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
index 9dab957..0c3d395 100644
--- a/net/sunrpc/clnt.c
+++ b/net/sunrpc/clnt.c
@@ -1824,23 +1824,15 @@ static void rpc_show_task(const struct rpc_clnt *clnt,
const struct rpc_task *task)
{
const char *rpc_waitq = "none";
- char *p, action[KSYM_SYMBOL_LEN];
if (RPC_IS_QUEUED(task))
rpc_waitq = rpc_qname(task->tk_waitqueue);
- /* map tk_action pointer to a function name; then trim off
- * the "+0x0 [sunrpc]" */
- sprint_symbol(action, (unsigned long)task->tk_action);
- p = strchr(action, '+');
- if (p)
- *p = '\0';
-
- printk(KERN_INFO "%5u %04x %6d %8p %8p %8ld %8p %sv%u %s a:%s q:%s\n",
+ printk(KERN_INFO "%5u %04x %6d %8p %8p %8ld %8p %sv%u %s a:%ps q:%s\n",
task->tk_pid, task->tk_flags, task->tk_status,
clnt, task->tk_rqstp, task->tk_timeout, task->tk_ops,
clnt->cl_protname, clnt->cl_vers, rpc_proc_name(task),
- action, rpc_waitq);
+ task->tk_action, rpc_waitq);
}
void rpc_show_tasks(void)
--
1.7.3.2.146.gca209
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: radvd and auto-ipv6 address regression from 2.6.31 to 2.6.34+
From: Ben Greear @ 2010-11-05 23:13 UTC (permalink / raw)
To: NetDev
In-Reply-To: <4CD47622.5040507@candelatech.com>
On 11/05/2010 02:24 PM, Ben Greear wrote:
>
> I'm seeing something strange. I'm running radvd on a VETH interface
> (veth0 for argument)
> with a single global IPv6 address (and a link-local address).
>
> On hacked 2.6.31, this works as I expect: The veth0 interface does not
> gain or lose any
> IPv6 addresses and peer VETH port gets an auto-created IPv6 addresses.
>
> On hacked 2.6.34 and 2.6.36 kernels, however, the veth0 gains a new
> address that appears
> to be generated similar to other IPs associated with auto-creation via
> radvd.
>
> I have not yet tested intervening kernels or physical interfaces between
> two machines.
>
> So, the question is: Is the new behaviour on purpose, or is it a
> regression bug?
Actually, this doesn't seem to work for 2.6.31 either, so I guess it
isn't a regression.
Is it expected behaviour, however?
Thanks,
Ben
>
> Thanks,
> Ben
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [RFC v2] ipvs: allow transmit of GRO aggregated skbs
From: Simon Horman @ 2010-11-05 23:54 UTC (permalink / raw)
To: lvs-devel, netdev; +Cc: Julian Anastasov
In-Reply-To: <20101105135222.GA8714@verge.net.au>
This is a first attempt at allowing LVS to transmit
skbs of greater than MTU length that have been aggregated by GRO.
I have lightly tested the ip_vs_dr_xmit() portion of this patch and
although it seems to work I am unsure that netif_needs_gso() is the correct
test to use.
Signed-off-by: Simon Horman <horms@verge.net.au>
---
* LRO is still an outstanding issue, but as its deprecated in favour
of GRO perhaps it doesn't need to be solved.
* v1
- Based on 2.6.35
* v2
- Rebase on current nf-next-2.6 tree (~2.6.37-rc1)
Index: lvs-test-2.6/net/netfilter/ipvs/ip_vs_xmit.c
===================================================================
--- lvs-test-2.6.orig/net/netfilter/ipvs/ip_vs_xmit.c 2010-10-30 11:43:37.000000000 +0900
+++ lvs-test-2.6/net/netfilter/ipvs/ip_vs_xmit.c 2010-11-06 08:09:17.000000000 +0900
@@ -408,7 +408,8 @@ ip_vs_bypass_xmit(struct sk_buff *skb, s
/* MTU checking */
mtu = dst_mtu(&rt->dst);
- if ((skb->len > mtu) && (iph->frag_off & htons(IP_DF))) {
+ if ((skb->len > mtu) && (iph->frag_off & htons(IP_DF)) &&
+ !netif_needs_gso(rt->dst.dev, skb)) {
ip_rt_put(rt);
icmp_send(skb, ICMP_DEST_UNREACH,ICMP_FRAG_NEEDED, htonl(mtu));
IP_VS_DBG_RL("%s(): frag needed\n", __func__);
@@ -461,7 +462,7 @@ ip_vs_bypass_xmit_v6(struct sk_buff *skb
/* MTU checking */
mtu = dst_mtu(&rt->dst);
- if (skb->len > mtu) {
+ if (skb->len > mtu && !netif_needs_gso(rt->dst.dev, skb)) {
if (!skb->dev) {
struct net *net = dev_net(skb_dst(skb)->dev);
@@ -560,7 +561,8 @@ ip_vs_nat_xmit(struct sk_buff *skb, stru
/* MTU checking */
mtu = dst_mtu(&rt->dst);
- if ((skb->len > mtu) && (iph->frag_off & htons(IP_DF))) {
+ if ((skb->len > mtu) && (iph->frag_off & htons(IP_DF)) &&
+ !netif_needs_gso(rt->dst.dev, skb)) {
icmp_send(skb, ICMP_DEST_UNREACH,ICMP_FRAG_NEEDED, htonl(mtu));
IP_VS_DBG_RL_PKT(0, AF_INET, pp, skb, 0,
"ip_vs_nat_xmit(): frag needed for");
@@ -675,7 +677,7 @@ ip_vs_nat_xmit_v6(struct sk_buff *skb, s
/* MTU checking */
mtu = dst_mtu(&rt->dst);
- if (skb->len > mtu) {
+ if (skb->len > mtu && !netif_needs_gso(rt->dst.dev, skb)) {
if (!skb->dev) {
struct net *net = dev_net(skb_dst(skb)->dev);
@@ -790,8 +792,9 @@ ip_vs_tunnel_xmit(struct sk_buff *skb, s
df |= (old_iph->frag_off & htons(IP_DF));
- if ((old_iph->frag_off & htons(IP_DF))
- && mtu < ntohs(old_iph->tot_len)) {
+ if ((old_iph->frag_off & htons(IP_DF) &&
+ mtu < ntohs(old_iph->tot_len) &&
+ !netif_needs_gso(rt->dst.dev, skb))) {
icmp_send(skb, ICMP_DEST_UNREACH,ICMP_FRAG_NEEDED, htonl(mtu));
IP_VS_DBG_RL("%s(): frag needed\n", __func__);
goto tx_error_put;
@@ -903,7 +906,8 @@ ip_vs_tunnel_xmit_v6(struct sk_buff *skb
if (skb_dst(skb))
skb_dst(skb)->ops->update_pmtu(skb_dst(skb), mtu);
- if (mtu < ntohs(old_iph->payload_len) + sizeof(struct ipv6hdr)) {
+ if (mtu < ntohs(old_iph->payload_len) + sizeof(struct ipv6hdr) &&
+ !netif_needs_gso(rt->dst.dev, skb)) {
if (!skb->dev) {
struct net *net = dev_net(skb_dst(skb)->dev);
@@ -1008,7 +1012,8 @@ ip_vs_dr_xmit(struct sk_buff *skb, struc
/* MTU checking */
mtu = dst_mtu(&rt->dst);
- if ((iph->frag_off & htons(IP_DF)) && skb->len > mtu) {
+ if ((iph->frag_off & htons(IP_DF)) && skb->len > mtu &&
+ !netif_needs_gso(rt->dst.dev, skb)) {
icmp_send(skb, ICMP_DEST_UNREACH,ICMP_FRAG_NEEDED, htonl(mtu));
ip_rt_put(rt);
IP_VS_DBG_RL("%s(): frag needed\n", __func__);
@@ -1174,7 +1179,8 @@ ip_vs_icmp_xmit(struct sk_buff *skb, str
/* MTU checking */
mtu = dst_mtu(&rt->dst);
- if ((skb->len > mtu) && (ip_hdr(skb)->frag_off & htons(IP_DF))) {
+ if ((skb->len > mtu) && (ip_hdr(skb)->frag_off & htons(IP_DF)) &&
+ !netif_needs_gso(rt->dst.dev, skb)) {
icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED, htonl(mtu));
IP_VS_DBG_RL("%s(): frag needed\n", __func__);
goto tx_error_put;
@@ -1288,7 +1294,7 @@ ip_vs_icmp_xmit_v6(struct sk_buff *skb,
/* MTU checking */
mtu = dst_mtu(&rt->dst);
- if (skb->len > mtu) {
+ if (skb->len > mtu && !netif_needs_gso(rt->dst.dev, skb)) {
if (!skb->dev) {
struct net *net = dev_net(skb_dst(skb)->dev);
^ permalink raw reply
* Re: OOM when adding ipv6 route: How to make available more per-cpu memory?
From: Ben Greear @ 2010-11-06 0:07 UTC (permalink / raw)
To: Eric Dumazet; +Cc: NetDev, linux-kernel, Tejun Heo
In-Reply-To: <1288995103.2665.653.camel@edumazet-laptop>
On 11/05/2010 03:11 PM, Eric Dumazet wrote:
> Le vendredi 05 novembre 2010 à 21:20 +0100, Eric Dumazet a écrit :
>> Your vmalloc space is very fragmented. pcpu_get_vm_areas() want
>> hugepages (4MB on your machine, 2MB on mine because I have
>> CONFIG_HIGHMEM64G=y)
>
> Well, this is wrong. We use normal (4KB) pages, unfortunately.
>
> I have a NUMA machine, with two nodes, so pcpu_get_vm_areas() allocates
> two zones, one for each node, with a 'known' offset between them.
> Then, 4KB pages are allocated to populate the zone when needed.
>
> # grep pcpu_get_vm_areas /proc/vmallocinfo
> 0xffffe8ffa0400000-0xffffe8ffa0600000 2097152 pcpu_get_vm_areas+0x0/0x740 vmalloc
> 0xffffe8ffffc00000-0xffffe8ffffe00000 2097152 pcpu_get_vm_areas+0x0/0x740 vmalloc
>
> BTW, we dont have the number of pages currently allocated in each
> 'vmalloc' zone, and/or node information.
>
> Tejun, do you have plans to use hugepages eventually ?
> (and fallback to 4KB pages, but most percpu data are allocated right
> after boot)
We just tried creating 1000 macvlans with IPv6 addrs on a 64-bit machine
with 12GB RAM. Only around 520 interfaces properly set their IPs, and
again there are errors about of-of-memory from 'ip', but no obvious
splats in dmesg.
'top' shows 10G or so free.
It will take some time to figure out what exactly is returning
the ENOMEM....
Thanks,
Ben
>
> Thanks
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* FINANCE
From: ACCESS FINANCE INC @ 2010-11-05 20:57 UTC (permalink / raw)
AP
PLY NOW FOR YOUR FINANCIAL ADVANCEMENT. ACCESS FINANCE LOAN FACILITY TO PEOPLE A
T 2.5% FIXED INTEREST RATE. IF YOUR ARE INTERESTED IN GETTING THIS LOAN PLEASE S
END IN THE FOLLOWING INFORMATION TO US WITHOUT DELAY: NAME.... LOAN AMOUNT... DU
RATION... PHONE NUMBER... FROM STEVE BARRY.GUARANTEED NO MATTER YOUR CREDIT SCOR
E.
^ permalink raw reply
* Re: radvd and auto-ipv6 address regression from 2.6.31 to 2.6.34+
From: Mikael Abrahamsson @ 2010-11-06 6:17 UTC (permalink / raw)
To: Ben Greear; +Cc: NetDev
In-Reply-To: <4CD48FB4.2050903@candelatech.com>
On Fri, 5 Nov 2010, Ben Greear wrote:
>> On hacked 2.6.34 and 2.6.36 kernels, however, the veth0 gains a new
>> address that appears to be generated similar to other IPs associated
>> with auto-creation via radvd.
>>
>> I have not yet tested intervening kernels or physical interfaces between
>> two machines.
>>
>> So, the question is: Is the new behaviour on purpose, or is it a
>> regression bug?
>
> Actually, this doesn't seem to work for 2.6.31 either, so I guess it
> isn't a regression.
>
> Is it expected behaviour, however?
I would not be surprised if the IPv6 stack on Linux would gain IPv6
addresses using SLAAC from any interface if it sees RAs on it, regardless
if these are locally generated or not.
I guess any Linux device running radvd should turn off autoconf on those
interface that radvd is acting on?
net.ipv6.conf.veth0.accept_ra=0 should do the trick?
--
Mikael Abrahamsson email: swmike@swm.pp.se
^ permalink raw reply
* Re: 2.6.36 vlans & bridge crash - status?
From: Nikola Ciprich @ 2010-11-06 7:11 UTC (permalink / raw)
To: Jesse Gross; +Cc: netdev list, nikola.ciprich
In-Reply-To: <AANLkTin130xsLRQRMH2W6Yy=gJSD-qS29vR-E6Qvfgpg@mail.gmail.com>
Hello Jesse,
It really fixes the problem, thanks!
Was the patch submitted to Greg for 2.6.36.y ?
n.
On Fri, Nov 05, 2010 at 08:05:17AM -0700, Jesse Gross wrote:
> On Fri, Nov 5, 2010 at 3:35 AM, Nikola Ciprich <extmaillist@linuxbox.cz> wrote:
> > Hello,
> > I would like to ask if somebody is trying to solve
> > https://bugzilla.kernel.org/show_bug.cgi?id=20462
> > and if needed, could I provide some help, testing etc?
>
> I sent out a patch for something related:
> http://permalink.gmane.org/gmane.linux.network/176566
>
> My guess is that it will also fix your issue. Can you test it?
> --
> 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
>
--
-------------------------------------
Ing. Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava
tel.: +420 596 603 142
fax: +420 596 621 273
mobil: +420 777 093 799
www.linuxbox.cz
mobil servis: +420 737 238 656
email servis: servis@linuxbox.cz
-------------------------------------
^ permalink raw reply
* Re: OOM when adding ipv6 route: How to make available more per-cpu memory?
From: Eric Dumazet @ 2010-11-06 7:26 UTC (permalink / raw)
To: Ben Greear; +Cc: NetDev, linux-kernel, Tejun Heo
In-Reply-To: <4CD49C2F.3060904@candelatech.com>
Le vendredi 05 novembre 2010 à 17:07 -0700, Ben Greear a écrit :
> We just tried creating 1000 macvlans with IPv6 addrs on a 64-bit machine
> with 12GB RAM. Only around 520 interfaces properly set their IPs, and
> again there are errors about of-of-memory from 'ip', but no obvious
> splats in dmesg.
>
> 'top' shows 10G or so free.
>
> It will take some time to figure out what exactly is returning
> the ENOMEM....
At least, nothing to do with percpu stuff ?
On my 4GB machine, 16 'cpus' (but 32 possible cpus), I was able to
allocate.
8192 percpu 8192 bytes structures
(total : 32 * 8192 * 8192 = 2 Gbytes)
setup_percpu: NR_CPUS:32 nr_cpumask_bits:32 nr_cpu_ids:32 nr_node_ids:2
PERCPU: Embedded 26 pages/cpu @ffff88007fc00000 s76032 r8192 d22272 u131072
pcpu-alloc: s76032 r8192 d22272 u131072 alloc=1*2097152
pcpu-alloc: [0] 00 02 04 06 08 10 12 14 17 19 21 23 25 27 29 31
pcpu-alloc: [1] 01 03 05 07 09 11 13 15 16 18 20 22 24 26 28 30
grep Vmalloc /proc/meminfo
VmallocTotal: 34359738367 kB
VmallocUsed: 2202592 kB
VmallocChunk: 34356996456 kB
Make sure udev / hotplug is not the problem, if you create your devices
very fast.
(modprobe dummy numdummies=2000) can be very slow because of that.
All tasks are fighting for RTNL or sysfs mutex.
^ permalink raw reply
* Re: OOM when adding ipv6 route: How to make available more per-cpu memory?
From: Tejun Heo @ 2010-11-06 9:11 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Ben Greear, NetDev, linux-kernel
In-Reply-To: <1288995103.2665.653.camel@edumazet-laptop>
Hello,
On 11/05/2010 11:11 PM, Eric Dumazet wrote:
> Le vendredi 05 novembre 2010 à 21:20 +0100, Eric Dumazet a écrit :
>> Your vmalloc space is very fragmented. pcpu_get_vm_areas() want
>> hugepages (4MB on your machine, 2MB on mine because I have
>> CONFIG_HIGHMEM64G=y)
>
> Well, this is wrong. We use normal (4KB) pages, unfortunately.
>
> I have a NUMA machine, with two nodes, so pcpu_get_vm_areas() allocates
> two zones, one for each node, with a 'known' offset between them.
> Then, 4KB pages are allocated to populate the zone when needed.
>
> # grep pcpu_get_vm_areas /proc/vmallocinfo
> 0xffffe8ffa0400000-0xffffe8ffa0600000 2097152 pcpu_get_vm_areas+0x0/0x740 vmalloc
> 0xffffe8ffffc00000-0xffffe8ffffe00000 2097152 pcpu_get_vm_areas+0x0/0x740 vmalloc
>
> BTW, we dont have the number of pages currently allocated in each
> 'vmalloc' zone, and/or node information.
>
> Tejun, do you have plans to use hugepages eventually ?
> (and fallback to 4KB pages, but most percpu data are allocated right
> after boot)
Well, it's rather complicated. Till now, the percpu usage hasn't
justified allocating hugepages but it might someday, but more
importantly the reason why those big chunks of address space are used
is to keep the first chunk embedded in the regular linear kernel
address space to avoid extra TLB pressure.
On configurations where vmalloc area is a scarce resource,
percpu_alloc=page can be specified to use page-mapped allocation.
This will use much smaller chunks in vmalloc area at the cost of
additional 4k page TLB pressure for percpu memory in the first chunk
(all the static percpu variables and then some).
pcpu_embed_first_chunk() contains heuristic which makes it yield to
page allocator but the parameter is pretty generous (maximum distance
between chunks > 75% of vmalloc area). It's there just to avoid
completely crazy cases. Also, x86 setup_per_cpu_areas() chooses page
allocator on 32bit NUMAs. This case didn't trigger either. We
probably need to add another condition.
That large machine on 32bit is bound to be flaky. To be short on
virtual address space is a pretty silly and stupid thing. Anyways,
any good idea on what criteria we could test?
Thanks.
--
tejun
^ permalink raw reply
* Re: bonding: flow control regression [was Re: bridging: flow control regression]
From: Simon Horman @ 2010-11-06 9:25 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Jay Vosburgh, David S. Miller
In-Reply-To: <1288690185.2832.8.camel@edumazet-laptop>
On Tue, Nov 02, 2010 at 10:29:45AM +0100, Eric Dumazet wrote:
> Le mardi 02 novembre 2010 à 17:46 +0900, Simon Horman a écrit :
>
> > Thanks Eric, that seems to resolve the problem that I was seeing.
> >
> > With your patch I see:
> >
> > No bonding
> >
> > # netperf -c -4 -t UDP_STREAM -H 172.17.60.216 -l 30 -- -m 1472
> > UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 172.17.60.216 (172.17.60.216) port 0 AF_INET
> > Socket Message Elapsed Messages CPU Service
> > Size Size Time Okay Errors Throughput Util Demand
> > bytes bytes secs # # 10^6bits/sec % SU us/KB
> >
> > 116736 1472 30.00 2438413 0 957.2 8.52 1.458
> > 129024 30.00 2438413 957.2 -1.00 -1.000
> >
> > With bonding (one slave, the interface used in the test above)
> >
> > netperf -c -4 -t UDP_STREAM -H 172.17.60.216 -l 30 -- -m 1472
> > UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 172.17.60.216 (172.17.60.216) port 0 AF_INET
> > Socket Message Elapsed Messages CPU Service
> > Size Size Time Okay Errors Throughput Util Demand
> > bytes bytes secs # # 10^6bits/sec % SU us/KB
> >
> > 116736 1472 30.00 2438390 0 957.1 8.97 1.535
> > 129024 30.00 2438390 957.1 -1.00 -1.000
> >
>
>
> Sure the patch helps when not too many flows are involved, but this is a
> hack.
>
> Say the device queue is 1000 packets, and you run a workload with 2000
> sockets, it wont work...
>
> Or device queue is 1000 packets, one flow, and socket send queue size
> allows for more than 1000 packets to be 'in flight' (echo 2000000
> >/proc/sys/net/core/wmem_default) , it wont work too with bonding, only
> with devices with a qdisc sitting in the first device met after the
> socket.
True, thanks for pointing that out.
The scenario that I am actually interested in is virtualisation.
And I believe that your patch helps the vhostnet case (I don't see
flow control problems with bonding + virtio without vhostnet). However,
I am unsure if there are also some easy work-arounds to degrade
flow control in the vhostnet case too.
^ permalink raw reply
* [PATCH] iproute2: remove useless use of buffer
From: Andreas Schwab @ 2010-11-06 9:26 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
Print directly to the file instead of going through a buffer.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
---
ip/ipaddress.c | 16 +++++++---------
1 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index 19b3d6e..fc306e6 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -613,23 +613,21 @@ int print_addrinfo(const struct sockaddr_nl *who, struct nlmsghdr *n,
fprintf(fp, "%s", (char*)RTA_DATA(rta_tb[IFA_LABEL]));
if (rta_tb[IFA_CACHEINFO]) {
struct ifa_cacheinfo *ci = RTA_DATA(rta_tb[IFA_CACHEINFO]);
- char buf[128];
fprintf(fp, "%s", _SL_);
+ fprintf(fp, " valid_lft ");
if (ci->ifa_valid == INFINITY_LIFE_TIME)
- sprintf(buf, "valid_lft forever");
+ fprintf(fp, "forever");
else
- sprintf(buf, "valid_lft %usec", ci->ifa_valid);
+ fprintf(fp, "%usec", ci->ifa_valid);
+ fprintf(fp, " preferred_lft ");
if (ci->ifa_prefered == INFINITY_LIFE_TIME)
- sprintf(buf+strlen(buf), " preferred_lft forever");
+ fprintf(fp, "forever");
else {
if (deprecated)
- sprintf(buf+strlen(buf), " preferred_lft %dsec",
- ci->ifa_prefered);
+ fprintf(fp, "%dsec", ci->ifa_prefered);
else
- sprintf(buf+strlen(buf), " preferred_lft %usec",
- ci->ifa_prefered);
+ fprintf(fp, "%usec", ci->ifa_prefered);
}
- fprintf(fp, " %s", buf);
}
fprintf(fp, "\n");
fflush(fp);
--
1.7.3.2
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply related
* hi
From: Gabriel kante @ 2010-11-06 8:25 UTC (permalink / raw)
I write to seek your help in the retrieval sum funds from US Bank account
belonging to my late Dad.
^ permalink raw reply
* Re: ping -I eth1 ....
From: Joakim Tjernlund @ 2010-11-06 9:42 UTC (permalink / raw)
To: Thomas Graf; +Cc: Eric Dumazet, netdev, Thomas Graf
In-Reply-To: <20101105203150.GA12118@canuck.infradead.org>
Thomas Graf <tgr@infradead.org> wrote on 2010/11/05 21:31:50:
>
> On Fri, Nov 05, 2010 at 04:54:18PM +0100, Joakim Tjernlund wrote:
> > Eric Dumazet <eric.dumazet@gmail.com> wrote on 2010/11/05 16:06:54:
> > >
> > > > Hopefully most of that is legacy or just plain wrong? Unless
> > > > someone can say why only test IFF_UP one should consider changing them.
> > > >
> > >
> > > Most of the places are hot path.
> > >
> > > You dont want to replace one test by four tests.
> > >
> > > _This_ would be wrong :)
> >
> > Wrong is wrong, even if it is in the hot path :)
> > Perhaps it is time define and internal IFF_OPERATIONAL flag
> > which is the sum of IFF_UP, IFF_RUNNING etc.? Tht
> > way you still get one test in the hot path and can abstract
> > what defines an operational link.
>
> You definitely don't want to have your send() call fail simply because
> the carrier was off for a few msec or the routing daemon has put a link
> down temporarly. Also, the outgoing interface looked up at routing
> decision is not necessarly the interface used for sending in the end.
> The packet may get mangled and rerouted by netfilter or tc on the way.
But do you handle the case when the link is non operational for a long time?
>
> Personally I'm even ok with the current behaviour of sendto() while the
> socket is bound to an interface but if we choose to return an error
> if the interface is down we might as well do so based on the operational
> status.
Perhaps there is a better way. This all started when pppd hung because
of ping -I <ppp interface>, then someone pulled the cable for the on the link.
This is a strace where we have two ping -I,
ping -I p1-2-1-2-2 .. and ping -I p1-2-3-2-4 ..
Notice how pppd hangs for a long time in PPPIOCDETACH
As far as I can tell this is due to ping -I has claimed the ppp interfaces
and doesn't noticed that the link is down. Ideally ping should receive
a ENODEV as soon as pppd calls PPPIOCDETACH.
0.000908 write(0, "Connection terminated.\n", 23) = 23
0.000481 gettimeofday({1288952770, 566048}, NULL) = 0
0.001553 ioctl(7, PPPIOCDETACH
Message from syslogd@Brazil at Fri Nov 5 11:26:20 2010 ...
Brazil kernel: unregister_netdevice: waiting for p1-2-1-2-2 to become free. Usage count = 3
Message from syslogd@Brazil at Fri Nov 5 11:26:20 2010 ...
Brazil kernel: unregister_netdevice: waiting for p1-2-3-2-4 to become free. Usage count = 3
Message from syslogd@Brazil at Fri Nov 5 11:26:51 2010 ...
Brazil last message repeated 3 times
, 0xbfbc3398) = 0
66.559216 connect(9, {sa_family=AF_PPPOX, sa_data="\0\0\0\0\0\0\0\252\273\314\335\356hd"}, 30) = 0
0.000693 close(10) = 0
0.000449 close(7) = 0
0.009801 close(9) = 0
^ permalink raw reply
* PERSONAL
From: Harry Barnes @ 2010-11-06 12:32 UTC (permalink / raw)
To: netdev
Hello,
This is Harry Barnes of the US Marine Corps, but redeployed to Iraq, and presently stationed in Mosul. I will like to share some very vital information that would bring some good financial returns to us in just a few weeks or days depending on how fast we pursue the matter. I am seeking your assistance to evacuate the sum of $28m to you,as far as I can be assured that it will be safe in your care until I complete my service here.
This may not be the best medium to make this kind of contact because of the numerous scam offers transmitted through the Internet, but it is all I have access to for now. I will be very grateful if you can give me the opportunity to discuss this matter with you by assuring me that you will not use any part of it against me in anyway, I hope you understand my limitations here. Should you have reasons to reject this offer, please destroy this mail as any leakage will be too bad for us.
Respectfully,
Harry Barnes.
^ permalink raw reply
* Re: [RFC v2] ipvs: allow transmit of GRO aggregated skbs
From: Julian Anastasov @ 2010-11-06 14:18 UTC (permalink / raw)
To: Simon Horman; +Cc: lvs-devel, netdev
In-Reply-To: <20101105235411.GA2443@verge.net.au>
Hello,
On Sat, 6 Nov 2010, Simon Horman wrote:
> This is a first attempt at allowing LVS to transmit
> skbs of greater than MTU length that have been aggregated by GRO.
>
> I have lightly tested the ip_vs_dr_xmit() portion of this patch and
> although it seems to work I am unsure that netif_needs_gso() is the correct
> test to use.
ip_forward() uses !skb_is_gso(skb), so may be it is
enough to check for GRO instead of using netif_needs_gso?
> Signed-off-by: Simon Horman <horms@verge.net.au>
>
> ---
>
> * LRO is still an outstanding issue, but as its deprecated in favour
> of GRO perhaps it doesn't need to be solved.
>
> * v1
> - Based on 2.6.35
>
> * v2
> - Rebase on current nf-next-2.6 tree (~2.6.37-rc1)
> --- lvs-test-2.6.orig/net/netfilter/ipvs/ip_vs_xmit.c 2010-10-30 11:43:37.000000000 +0900
> +++ lvs-test-2.6/net/netfilter/ipvs/ip_vs_xmit.c 2010-11-06 08:09:17.000000000 +0900
> @@ -1008,7 +1012,8 @@ ip_vs_dr_xmit(struct sk_buff *skb, struc
>
> /* MTU checking */
> mtu = dst_mtu(&rt->dst);
> - if ((iph->frag_off & htons(IP_DF)) && skb->len > mtu) {
> + if ((iph->frag_off & htons(IP_DF)) && skb->len > mtu &&
> + !netif_needs_gso(rt->dst.dev, skb)) {
> icmp_send(skb, ICMP_DEST_UNREACH,ICMP_FRAG_NEEDED, htonl(mtu));
> ip_rt_put(rt);
> IP_VS_DBG_RL("%s(): frag needed\n", __func__);
Regards
--
Julian Anastasov <ja@ssi.bg>
^ 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