* Re: [PATCH 3/4] Fix the wanxl firmware to include missing constants
From: David Miller @ 2012-11-09 21:29 UTC (permalink / raw)
To: dhowells; +Cc: khc, netdev, linux
In-Reply-To: <20121107123724.4147.98542.stgit@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Wed, 07 Nov 2012 12:37:24 +0000
> Fix the wanxl firmware to include missing constants such as PARITY_NONE. It
> should be #including the linux/hdlc/ioctl.h header.
>
> To make this work, we also have to guard parts of ioctl.h with !__ASSEMBLY__.
>
> Signed-off-by: David Howells <dhowells@redhat.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH 2/4] UAPI: (Scripted) Disintegrate include/linux/hdlc
From: David Miller @ 2012-11-09 21:29 UTC (permalink / raw)
To: dhowells; +Cc: khc, netdev, linux
In-Reply-To: <20121107123717.4147.15213.stgit@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Wed, 07 Nov 2012 12:37:17 +0000
> Signed-off-by: David Howells <dhowells@redhat.com>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Acked-by: Thomas Gleixner <tglx@linutronix.de>
> Acked-by: Michael Kerrisk <mtk.manpages@gmail.com>
> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Acked-by: Dave Jones <davej@redhat.com>
> Acked-by: Krzysztof Halasa <khc@pm.waw.pl>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH 1/4] UAPI: Fix compilation of the wanxl firmware blob.
From: David Miller @ 2012-11-09 21:29 UTC (permalink / raw)
To: dhowells; +Cc: khc, netdev, linux
In-Reply-To: <20121107123709.4147.98018.stgit@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Wed, 07 Nov 2012 12:37:09 +0000
> The wanxl firmware needs access to some bits of UAPI stuff, so the -I flag in
> the Makefile needs adjusting to point at the UAPI headers.
>
> Signed-off-by: David Howells <dhowells@redhat.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH] bonding: rlb mode of bond should not alter ARP replies originating via bridge
From: David Miller @ 2012-11-09 21:25 UTC (permalink / raw)
To: zheng.x.li; +Cc: netdev, fubar, andy, linux-kernel, joe.jin
In-Reply-To: <1352258580-8272-1-git-send-email-zheng.x.li@oracle.com>
From: Zheng Li <zheng.x.li@oracle.com>
Date: Wed, 7 Nov 2012 11:23:00 +0800
> ARP traffic passing through a bridge and out via the bond (when the bond is a
> port of the bridge) should not have its source MAC address adjusted by the
> receive load balance code in rlb_arp_xmit.
>
> Signed-off-by: Zheng Li <zheng.x.li@oracle.com>
Please format these change properly, this is not indented
correctly at all:
> + if (ether_addr_equal_64bits(arp->mac_src,
> + tmp_slave->dev->dev_addr)) {
> + memcpy(arp->mac_src,
> + tx_slave->dev->dev_addr,
> + ETH_ALEN);
> + break;
Arguments to functions should line up, always, with the first column
after the openning parenthesis of the function call.
If that makes the far right column of the line go too far past
80 columns, too bad. Make and use a helper function to perform
this test in that case.
Thanks.
^ permalink raw reply
* Re: [PATCH] ipv6: add knob to send unsolicited ND on link-layer address change
From: David Miller @ 2012-11-09 21:22 UTC (permalink / raw)
To: hannes; +Cc: netdev
In-Reply-To: <20121109130141.GA31099@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Fri, 9 Nov 2012 14:01:41 +0100
> David, if you intend to merge this patch, could you please remove the empty
> line I accidently added in the addrconf_sysctl_table, directly following
> .proc_handler? As usual, I noticed it just after sending the patch.
I intend to eventually apply this to net-next, and I'll take care
of the empty line when I do so, thanks.
^ permalink raw reply
* Re: [PATCH] ipv6: send unsolicited neighbour advertisements to all-nodes
From: David Miller @ 2012-11-09 21:22 UTC (permalink / raw)
To: hannes; +Cc: netdev
In-Reply-To: <20121107021841.GC26398@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Wed, 7 Nov 2012 03:18:41 +0100
> As documented in RFC4861 (Neighbor Discovery for IP version 6) 7.2.6.,
> unsolicited neighbour advertisements should be sent to the all-nodes
> multicast address.
>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: How to compile tcp fast open client app with kernel tfo client support ?
From: Vincent Li @ 2012-11-09 21:09 UTC (permalink / raw)
To: Vijay Subramanian; +Cc: Eric Dumazet, Yuchung Cheng, netdev
In-Reply-To: <CAGK4HS_SpdECk_KCu98Z1X9W02G9j9u7QE9B6qHEnTXLeZbqgA@mail.gmail.com>
On Fri, Nov 9, 2012 at 12:54 PM, Vijay Subramanian
<subramanian.vijay@gmail.com> wrote:
> On 9 November 2012 12:27, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> On Fri, 2012-11-09 at 12:17 -0800, Vincent Li wrote:
>>
>>> I have tried to run fresh build net-next, for some reason the build
>>> stops ssh service from starting up, tried 3.7.0-rc4 too, same issue. I
>>> don't know if it is new kernel bug or ubuntu upstart bug, but that is
>>> another issue.
>>>
>>
>> Not sure Ubuntu 10.04 binaries can run a 3.7 kernel.
>>
>> Some bug fixes in kernel need bug fixes in userland.
>>
>> You could try a bisection ?
>>
> I saw the same issue with Ubuntu starting around 3.7.0-rc1 but 3.6
> was fine if I recall. (I did a partial bisection but was not sure it
> was a kernel issue)
> sshd would not start up on boot and I 'fixed' it by adding the
> following in /etc/rc.local since I assumed it was a userspace issue.
>
> if [ ! -d /var/run/sshd ]; then
> mkdir /var/run/sshd
> chmod 0755 /var/run/sshd
> fi
> /usr/sbin/sshd
>
>
> Thanks,
> Vijay
thanks again, you "fixed" my other issue :-)
Vincent
^ permalink raw reply
* Re: [PATCH 2/2] smsc95xx: set MII_BUSY bit to read/write PHY regs
From: David Miller @ 2012-11-09 21:08 UTC (permalink / raw)
To: steve.glendinning; +Cc: netdev
In-Reply-To: <1352196533-2674-1-git-send-email-steve.glendinning@shawell.net>
From: Steve Glendinning <steve.glendinning@shawell.net>
Date: Tue, 6 Nov 2012 10:08:53 +0000
> The device datasheet specifies the BUSY bit must be set when reading
> or writing phy registers. This patch ensures we do that.
>
> Signed-off-by: Steve Glendinning <steve.glendinning@shawell.net>
Steve please let me know why you only submitted patch #2
of an apparent 2 part series.
If I don't get a response soon I'm just going to toss this
patch instead of letting it simply rot in patchwork.
Thanks.
^ permalink raw reply
* Re: [PATCH] cdc_ether: use USB_DEVICE_AND_INTERFACE_INFO for Novatel 551L/E362
From: David Miller @ 2012-11-09 21:07 UTC (permalink / raw)
To: dcbw; +Cc: bjorn, aleksander, netdev
In-Reply-To: <1352398152.22225.14.camel@dcbw.foobar.com>
From: Dan Williams <dcbw@redhat.com>
Date: Thu, 08 Nov 2012 12:09:12 -0600
> Small cleanup.
>
> Signed-off-by: Dan Williams <dcbw@redhat.com>
> Cc: stable@vger.kernel.org
Don't do things like this, _please_.
A cleanup is absolutely not appropriate for -stable. Yet you
tagged this as being destined for there.
What's more this screws up the second patch, which in fact could
be -stable material. But I'm not going to apply it as it is
because it could have dependencies on this patch which as
states is not inappropriate for both 'net' and -stable.
I'm therefore tossing both of these changes, submit things properly
please.
^ permalink raw reply
* Re: How to compile tcp fast open client app with kernel tfo client support ?
From: Vijay Subramanian @ 2012-11-09 20:54 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Vincent Li, Yuchung Cheng, netdev
In-Reply-To: <1352492823.19779.825.camel@edumazet-glaptop>
On 9 November 2012 12:27, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Fri, 2012-11-09 at 12:17 -0800, Vincent Li wrote:
>
>> I have tried to run fresh build net-next, for some reason the build
>> stops ssh service from starting up, tried 3.7.0-rc4 too, same issue. I
>> don't know if it is new kernel bug or ubuntu upstart bug, but that is
>> another issue.
>>
>
> Not sure Ubuntu 10.04 binaries can run a 3.7 kernel.
>
> Some bug fixes in kernel need bug fixes in userland.
>
> You could try a bisection ?
>
I saw the same issue with Ubuntu starting around 3.7.0-rc1 but 3.6
was fine if I recall. (I did a partial bisection but was not sure it
was a kernel issue)
sshd would not start up on boot and I 'fixed' it by adding the
following in /etc/rc.local since I assumed it was a userspace issue.
if [ ! -d /var/run/sshd ]; then
mkdir /var/run/sshd
chmod 0755 /var/run/sshd
fi
/usr/sbin/sshd
Thanks,
Vijay
^ permalink raw reply
* Re: essentially offline...
From: Jan Ceuleers @ 2012-11-09 20:49 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20121108.160149.1435441347312920431.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On 11/08/2012 10:01 PM, David Miller wrote:
> I used the work jackass just as frequently before I lived part time
> in New York. Try again...
Well then it seems you were born that way. Still doesn't make it acceptable.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Question about Mellanox FW reporting (incorrect) port types
From: Marcelo Ricardo Leitner @ 2012-11-09 20:37 UTC (permalink / raw)
To: Or Gerlitz
Cc: Yevgeny Petrilin, netdev, Or Gerlitz, Doug Ledford, Yishai Hadas
In-Reply-To: <507F0BD5.7080005@redhat.com>
Em 17-10-2012 16:49, Marcelo Ricardo Leitner escreveu:
> On 10/17/2012 04:22 PM, Or Gerlitz wrote:
>> Marcelo Ricardo Leitner <mleitner@redhat.com> wrote:
>>>
>>> [...] So my questions are: is it possible to the firmware report a
>>> wrong port type like
>>> that? Is it somehow configurable by sysadmin (via fw update, ..), can
>>> we flip that byte
>>> or is it a manufacturing issue?
For completeness,
As it happens the customer had the HP Infinband Enablement Kit
(614841-B21) installed at jumper location 53 (J53) of the motherboard,
which makes the QSFP port of the S390s' NC543i interface an Infiniband
interface rather than a 10gbE interface. Removing this allowed the port
to be brought-up as 10GbE just fine.
Interesting that it worked as 10GbE even with InifiniBand Enablement Kit
on it, so the port was just advertised, but not forced, as InfiniBand.
Or something like that.
Thanks,
Marcelo.
^ permalink raw reply
* Re: How to compile tcp fast open client app with kernel tfo client support ?
From: Eric Dumazet @ 2012-11-09 20:27 UTC (permalink / raw)
To: Vincent Li; +Cc: Yuchung Cheng, Vijay Subramanian, netdev
In-Reply-To: <CAK3+h2xAqjs8CvkcwXiFryyQhDnohsN7-0KfQVjpegZh_AD1eg@mail.gmail.com>
On Fri, 2012-11-09 at 12:17 -0800, Vincent Li wrote:
> I have tried to run fresh build net-next, for some reason the build
> stops ssh service from starting up, tried 3.7.0-rc4 too, same issue. I
> don't know if it is new kernel bug or ubuntu upstart bug, but that is
> another issue.
>
Not sure Ubuntu 10.04 binaries can run a 3.7 kernel.
Some bug fixes in kernel need bug fixes in userland.
You could try a bisection ?
^ permalink raw reply
* Re: How to compile tcp fast open client app with kernel tfo client support ?
From: Vincent Li @ 2012-11-09 20:17 UTC (permalink / raw)
To: Yuchung Cheng; +Cc: Vijay Subramanian, netdev
In-Reply-To: <CAK6E8=fc=hYppk=4+tnNF9UPvQNFhw8YKo-ebG2y6FwXTft_EQ@mail.gmail.com>
> Hi Vincent,
>
> Note that MSG_FASTOPEN flag should be used only once. Subsequent
> sendto(MSG_FASTOPEN) == connect() on connected sockets. You can verify
> if the fast open is successful by checking a bit in TCP_INFO.
> http://patchwork.o zlabs.org/patch/192883/ if you are running a fresh
> netdev build.
>
> I'll submit a patch to update the man page on MSG_FASTOPEN too.
>
> Yuchung
>
I have tried to run fresh build net-next, for some reason the build
stops ssh service from starting up, tried 3.7.0-rc4 too, same issue. I
don't know if it is new kernel bug or ubuntu upstart bug, but that is
another issue.
I will study the tcp fast open more, thanks.
Vincent
^ permalink raw reply
* Re: [PATCH v3 1/9] net: core: use this_cpu_ptr per-cpu helper
From: Eric Dumazet @ 2012-11-09 20:15 UTC (permalink / raw)
To: Christoph Lameter
Cc: Shan Wei, David Miller, timo.teras, steffen.klassert, NetDev,
Kernel-Maillist
In-Reply-To: <0000013ae6c9e81a-eabe295b-72a5-4ebd-85c5-231bec1a70c5-000000@email.amazonses.com>
On Fri, 2012-11-09 at 20:08 +0000, Christoph Lameter wrote:
> On Fri, 9 Nov 2012, Shan Wei wrote:
>
> > diff --git a/net/core/flow.c b/net/core/flow.c
> > index e318c7e..b0901ee 100644
> > --- a/net/core/flow.c
> > +++ b/net/core/flow.c
> > @@ -327,11 +327,9 @@ static void flow_cache_flush_tasklet(unsigned long data)
> > static void flow_cache_flush_per_cpu(void *data)
> > {
> > struct flow_flush_info *info = data;
> > - int cpu;
> > struct tasklet_struct *tasklet;
> >
> > - cpu = smp_processor_id();
> > - tasklet = &per_cpu_ptr(info->cache->percpu, cpu)->flush_tasklet;
> > + tasklet = this_cpu_ptr(&info->cache->percpu->flush_tasklet);
> > tasklet->data = (unsigned long)info;
>
> this_cpu_write(info->cache->percpu->flush_tasklet->data, (unsigned
> long)info);
>
> should also do the trick in less instructions and get rid of all temporary
> variables as well.
Its not the case.
We need the _pointer_ to call :
tasklet_schedule(tasklet);
^ permalink raw reply
* Re: [PATCH v3 4/9] net: openvswitch: use this_cpu_ptr per-cpu helper
From: Christoph Lameter @ 2012-11-09 20:12 UTC (permalink / raw)
To: Shan Wei
Cc: dev-yBygre7rU0TnMu66kgdUjQ, NetDev, Kernel-Maillist, David Miller
In-Reply-To: <509C6895.6020300-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, 9 Nov 2012, Shan Wei wrote:
> just use more faster this_cpu_ptr instead of per_cpu_ptr(p, smp_processor_id());
Reviewed-by: Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org>
^ permalink raw reply
* Re: [PATCH v3 3/9] net: xfrm: use __this_cpu_read per-cpu helper
From: Christoph Lameter @ 2012-11-09 20:12 UTC (permalink / raw)
To: Shan Wei
Cc: steffen.klassert, David Miller, NetDev, Herbert Xu,
Kernel-Maillist
In-Reply-To: <509C688B.5010502@gmail.com>
On Fri, 9 Nov 2012, Shan Wei wrote:
> v3 fix compile warning:
> net/xfrm/xfrm_ipcomp.c: In function 'ipcomp_alloc_tfms':
> net/xfrm/xfrm_ipcomp.c:285: warning: assignment from incompatible pointer type
Why exactly is the pointer type not compatible? Looks like we have a
problem here.
^ permalink raw reply
* Re: [PATCH v3 2/9] net: rds: use this_cpu_ptr per-cpu helper
From: Christoph Lameter @ 2012-11-09 20:09 UTC (permalink / raw)
To: Shan Wei
Cc: venkat.x.venkatsubra, David Miller, rds-devel, NetDev,
Kernel-Maillist
In-Reply-To: <509C687E.1080106@gmail.com>
On Fri, 9 Nov 2012, Shan Wei wrote:
> net/rds/ib_recv.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/rds/ib_recv.c b/net/rds/ib_recv.c
> index 8d19491..a4a5064 100644
> --- a/net/rds/ib_recv.c
> +++ b/net/rds/ib_recv.c
> @@ -423,7 +423,7 @@ static void rds_ib_recv_cache_put(struct list_head *new_item,
>
> local_irq_save(flags);
>
> - chp = per_cpu_ptr(cache->percpu, smp_processor_id());
> + chp = this_cpu_ptr(cache->percpu);
> if (!chp->first)
if (!__this_cpu_read(cache-0>percpu->first))
?
^ permalink raw reply
* Re: [PATCH v3 1/9] net: core: use this_cpu_ptr per-cpu helper
From: Christoph Lameter @ 2012-11-09 20:08 UTC (permalink / raw)
To: Shan Wei
Cc: David Miller, timo.teras, steffen.klassert, NetDev,
Kernel-Maillist
In-Reply-To: <509C686F.20400@gmail.com>
On Fri, 9 Nov 2012, Shan Wei wrote:
> diff --git a/net/core/flow.c b/net/core/flow.c
> index e318c7e..b0901ee 100644
> --- a/net/core/flow.c
> +++ b/net/core/flow.c
> @@ -327,11 +327,9 @@ static void flow_cache_flush_tasklet(unsigned long data)
> static void flow_cache_flush_per_cpu(void *data)
> {
> struct flow_flush_info *info = data;
> - int cpu;
> struct tasklet_struct *tasklet;
>
> - cpu = smp_processor_id();
> - tasklet = &per_cpu_ptr(info->cache->percpu, cpu)->flush_tasklet;
> + tasklet = this_cpu_ptr(&info->cache->percpu->flush_tasklet);
> tasklet->data = (unsigned long)info;
this_cpu_write(info->cache->percpu->flush_tasklet->data, (unsigned
long)info);
should also do the trick in less instructions and get rid of all temporary
variables as well.
^ permalink raw reply
* Re: [PATCH net-next 1/3] ipip: advertise tunnel param via rtnl
From: Eric Dumazet @ 2012-11-09 19:42 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev, davem
In-Reply-To: <509D36CB.9030509@6wind.com>
On Fri, 2012-11-09 at 18:00 +0100, Nicolas Dichtel wrote:
> If the principle is approved, yes. If we add it, we will have two
> ways to manage these tunnels, via netlink and via ioctl, is it ok?
>
> A side effect could be to have an option or an argument to the module to not
> create the control interface (tunl0, sit0, ...).
The principle is already used for gre tunnels, so it definitely is
approved ;)
^ permalink raw reply
* Re: question on netdev_completed_queue()
From: Eric Dumazet @ 2012-11-09 19:38 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Oliver Neukum, netdev
In-Reply-To: <1352480979.3159.13.camel@bwh-desktop.uk.solarflarecom.com>
On Fri, 2012-11-09 at 17:09 +0000, Ben Hutchings wrote:
> The underlying DQL algorithm doesn't care what it's counting. However
> the administrator can adjust the queue limits through sysfs, and they
> will expect the numbers to be byte counts.
Yes, skb->len should be a fine approximation, even if slightly wrong for
TSO packets.
^ permalink raw reply
* [PATCH] r8169: Kill RX_BUF_SIZE macro
From: Kirill Smelkov @ 2012-11-09 19:29 UTC (permalink / raw)
To: Francois Romieu
Cc: Realtek linux nic maintainers, netdev, Kirill Smelkov,
Eric Dumazet
After 6f0333b8 (r8169: use 50% less ram for RX ring) RX_BUF_SIZE is not
used and should be gone.
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Kirill Smelkov <kirr@navytux.spb.ru>
---
drivers/net/ethernet/realtek/r8169.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index d6c6cfb..029a028 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -84,7 +84,6 @@ static const int multicast_filter_limit = 32;
#define R8169_NAPI_WEIGHT 64
#define NUM_TX_DESC 64 /* Number of Tx descriptor registers */
#define NUM_RX_DESC 256 /* Number of Rx descriptor registers */
-#define RX_BUF_SIZE 1536 /* Rx Buffer size */
#define R8169_TX_RING_BYTES (NUM_TX_DESC * sizeof(struct TxDesc))
#define R8169_RX_RING_BYTES (NUM_RX_DESC * sizeof(struct RxDesc))
--
1.8.0.337.g4cdca5d
^ permalink raw reply related
* Re: [PATCH net-next] ipv6: export IP6_RT_PRIO_* to userland
From: David Miller @ 2012-11-09 19:05 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev
In-Reply-To: <509CD046.4060302@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Fri, 09 Nov 2012 10:43:34 +0100
> Le 05/11/2012 20:24, Nicolas Dichtel a écrit :
>> Le 05/11/2012 18:43, David Miller a écrit :
>>> From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>>> Date: Mon, 05 Nov 2012 18:22:39 +0100
>>>
>>>> Le 05/11/2012 18:00, David Miller a écrit :
>>>>> From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>>>>> Date: Mon, 5 Nov 2012 16:28:18 +0100
>>>>>
>>>>>> The kernel uses some default metric when routes are managed. For
>>>>>> example, a
>>>>>> static route added with a metric set to 0 is inserted in the kernel
>>>>>> with
>>>>>> metric 1024 (IP6_RT_PRIO_USER).
>>>>>> It is useful for routing daemons to know these values, to be able to
>>>>>> set routes
>>>>>> without interfering with what the kernel does.
>>>>>>
>>>>>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>>>>>
>>>>> But these belong in the libc headers anyways.
>>>>>
>>>>> If we haven't provided them for so long, there's no real value of
>>>>> adding them now.
>>>>>
>>>> But how can a daemon know which default values are used? If it wants
>>>> to add a route with metric = default + x, it should first add it with
>>>> metric = 0, check the result and then change the metric.
>>>
>>> What do we do on the ipv4 side and how do daemons cope in that
>>> situation?
>>>
>> In IPv4, there is no such default metric. If you add a route with
>> metric X, it
>> remains X in the kernel, even if it's 0.
> So we need to duplicate these values in the daemon?
>
I'm without real internet access again for the past 2 days and simply
too backlogged to even continue considering this issue.
Please be patient.
^ permalink raw reply
* Re: How to compile tcp fast open client app with kernel tfo client support ?
From: Yuchung Cheng @ 2012-11-09 18:53 UTC (permalink / raw)
To: Vincent Li; +Cc: Vijay Subramanian, netdev
In-Reply-To: <CAK3+h2z5=n6BHGzPjfbrJS4MbVGQ2pdMQP54dOZ8M=8xigUd3Q@mail.gmail.com>
On Fri, Nov 9, 2012 at 1:47 PM, Vincent Li <vincent.mc.li@gmail.com> wrote:
> On Fri, Nov 9, 2012 at 10:23 AM, Vijay Subramanian
> <subramanian.vijay@gmail.com> wrote:
>>> htmlgettfo.c: In function 'get_page_thread':
>>> htmlgettfo.c:109: error: 'MSG_FASTOPEN' undeclared (first use in this function)
>>> htmlgettfo.c:109: error: (Each undeclared identifier is reported only once
>>> htmlgettfo.c:109: error: for each function it appears in.)
>>>
>>> I have the 3.6.0 kernel header file package installed
>>> /usr/src/linux-headers-3.6.0-custom, the user space include file
>>> /usr/include/linux is original one coming with 10.0.4 distro kernel
>>>
>>> I am suspecting I don't have proper linux header file that has
>>> MSG_FASTOPEN declared in user space. can anyone shed a light on how to
>>> get MSG_FASTOPEN supported and compiled in client code properly?
>>>
>>
>> Vincent ,
>> You can try adding the following to the client code.
>>
>> #define MSG_FASTOPEN 0x20000000
>>
>> This is missing still from user space header files I presume.
>>
>> Vijay
>
> Thanks Vijay, that did it. and the load banlancer doesn't recognize
> the option, but traffic pass through ok. the data is sent through the
> final ack of 3WHS from linux.
Hi Vincent,
Note that MSG_FASTOPEN flag should be used only once. Subsequent
sendto(MSG_FASTOPEN) == connect() on connected sockets. You can verify
if the fast open is successful by checking a bit in TCP_INFO.
http://patchwork.o zlabs.org/patch/192883/ if you are running a fresh
netdev build.
I'll submit a patch to update the man page on MSG_FASTOPEN too.
Yuchung
>
> Vincent
> --
> 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: How to compile tcp fast open client app with kernel tfo client support ?
From: Vincent Li @ 2012-11-09 18:47 UTC (permalink / raw)
To: Vijay Subramanian; +Cc: netdev
In-Reply-To: <CAGK4HS-U+Ov5x8z+1CRZdiAD9MhfBUfurKKBbt1EWGYFLN8TcA@mail.gmail.com>
On Fri, Nov 9, 2012 at 10:23 AM, Vijay Subramanian
<subramanian.vijay@gmail.com> wrote:
>> htmlgettfo.c: In function 'get_page_thread':
>> htmlgettfo.c:109: error: 'MSG_FASTOPEN' undeclared (first use in this function)
>> htmlgettfo.c:109: error: (Each undeclared identifier is reported only once
>> htmlgettfo.c:109: error: for each function it appears in.)
>>
>> I have the 3.6.0 kernel header file package installed
>> /usr/src/linux-headers-3.6.0-custom, the user space include file
>> /usr/include/linux is original one coming with 10.0.4 distro kernel
>>
>> I am suspecting I don't have proper linux header file that has
>> MSG_FASTOPEN declared in user space. can anyone shed a light on how to
>> get MSG_FASTOPEN supported and compiled in client code properly?
>>
>
> Vincent ,
> You can try adding the following to the client code.
>
> #define MSG_FASTOPEN 0x20000000
>
> This is missing still from user space header files I presume.
>
> Vijay
Thanks Vijay, that did it. and the load banlancer doesn't recognize
the option, but traffic pass through ok. the data is sent through the
final ack of 3WHS from linux.
Vincent
^ 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