* Re: [PATCH net-next] ipv6: RTAX_FEATURE_ALLFRAG causes inefficient TCP segment sizing
From: Maciej Żenczykowski @ 2012-04-24 19:49 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Tore Anderson, David Miller, netdev, Tom Herbert
In-Reply-To: <1335289058.5205.165.camel@edumazet-glaptop>
Why do we refuse to set ipv6 mtu's below 1280?
how is what we do any better?
On Tue, Apr 24, 2012 at 10:37 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> Quoting Tore Anderson from :
> https://bugzilla.kernel.org/show_bug.cgi?id=42572
>
> When RTAX_FEATURE_ALLFRAG is set on a route, the effective TCP segment
> size does not take into account the size of the IPv6 Fragmentation
> header that needs to be included in outbound packets, causing every
> transmitted TCP segment to be fragmented across two IPv6 packets, the
> latter of which will only contain 8 bytes of actual payload.
>
> RTAX_FEATURE_ALLFRAG is typically set on a route in response to
> receving a ICMPv6 Packet Too Big message indicating a Path MTU of less
> than 1280 bytes. 1280 bytes is the minimum IPv6 MTU, however ICMPv6
> PTBs with MTU < 1280 are still valid, in particular when an IPv6
> packet is sent to an IPv4 destination through a stateless translator.
> Any ICMPv4 Need To Fragment packets originated from the IPv4 part of
> the path will be translated to ICMPv6 PTB which may then indicate an
> MTU of less than 1280.
>
> The Linux kernel refuses to reduce the effective MTU to anything below
> 1280 bytes, instead it sets it to exactly 1280 bytes, and
> RTAX_FEATURE_ALLFRAG is also set. However, the TCP segment size appears
> to be set to 1240 bytes (1280 Path MTU - 40 bytes of IPv6 header),
> instead of 1232 (additionally taking into account the 8 bytes required
> by the IPv6 Fragmentation extension header).
>
> This in turn results in rather inefficient transmission, as every
> transmitted TCP segment now is split in two fragments containing
> 1232+8 bytes of payload.
>
> After this patch, all the outgoing packets that includes a
> Fragmentation header all are "atomic" or "non-fragmented" fragments,
> i.e., they both have Offset=0 and More Fragments=0.
>
> With help from David S. Miller
>
> Reported-by: Tore Anderson <tore@fud.no>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Maciej Żenczykowski <maze@google.com>
> Cc: Tom Herbert <therbert@google.com>
> Tested-by: Tore Anderson <tore@fud.no>
> ---
> include/net/inet_connection_sock.h | 1 +
> include/net/tcp.h | 4 ++--
> net/ipv4/tcp_output.c | 19 +++++++++++++++++--
> net/ipv6/tcp_ipv6.c | 1 +
> 4 files changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/include/net/inet_connection_sock.h b/include/net/inet_connection_sock.h
> index 46c9e2c..7d83f90 100644
> --- a/include/net/inet_connection_sock.h
> +++ b/include/net/inet_connection_sock.h
> @@ -45,6 +45,7 @@ struct inet_connection_sock_af_ops {
> struct dst_entry *dst);
> struct inet_peer *(*get_peer)(struct sock *sk, bool *release_it);
> u16 net_header_len;
> + u16 net_frag_header_len;
> u16 sockaddr_len;
> int (*setsockopt)(struct sock *sk, int level, int optname,
> char __user *optval, unsigned int optlen);
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index fc880e9..0fb84de 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -544,8 +544,8 @@ extern int tcp_read_sock(struct sock *sk, read_descriptor_t *desc,
>
> extern void tcp_initialize_rcv_mss(struct sock *sk);
>
> -extern int tcp_mtu_to_mss(const struct sock *sk, int pmtu);
> -extern int tcp_mss_to_mtu(const struct sock *sk, int mss);
> +extern int tcp_mtu_to_mss(struct sock *sk, int pmtu);
> +extern int tcp_mss_to_mtu(struct sock *sk, int mss);
> extern void tcp_mtup_init(struct sock *sk);
> extern void tcp_valid_rtt_meas(struct sock *sk, u32 seq_rtt);
>
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 7b7cf38..834e89f 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -1150,7 +1150,7 @@ int tcp_trim_head(struct sock *sk, struct sk_buff *skb, u32 len)
> }
>
> /* Calculate MSS. Not accounting for SACKs here. */
> -int tcp_mtu_to_mss(const struct sock *sk, int pmtu)
> +int tcp_mtu_to_mss(struct sock *sk, int pmtu)
> {
> const struct tcp_sock *tp = tcp_sk(sk);
> const struct inet_connection_sock *icsk = inet_csk(sk);
> @@ -1161,6 +1161,14 @@ int tcp_mtu_to_mss(const struct sock *sk, int pmtu)
> */
> mss_now = pmtu - icsk->icsk_af_ops->net_header_len - sizeof(struct tcphdr);
>
> + /* IPv6 adds a frag_hdr in case RTAX_FEATURE_ALLFRAG is set */
> + if (icsk->icsk_af_ops->net_frag_header_len) {
> + const struct dst_entry *dst = __sk_dst_get(sk);
> +
> + if (dst && dst_allfrag(dst))
> + mss_now -= icsk->icsk_af_ops->net_frag_header_len;
> + }
> +
> /* Clamp it (mss_clamp does not include tcp options) */
> if (mss_now > tp->rx_opt.mss_clamp)
> mss_now = tp->rx_opt.mss_clamp;
> @@ -1179,7 +1187,7 @@ int tcp_mtu_to_mss(const struct sock *sk, int pmtu)
> }
>
> /* Inverse of above */
> -int tcp_mss_to_mtu(const struct sock *sk, int mss)
> +int tcp_mss_to_mtu(struct sock *sk, int mss)
> {
> const struct tcp_sock *tp = tcp_sk(sk);
> const struct inet_connection_sock *icsk = inet_csk(sk);
> @@ -1190,6 +1198,13 @@ int tcp_mss_to_mtu(const struct sock *sk, int mss)
> icsk->icsk_ext_hdr_len +
> icsk->icsk_af_ops->net_header_len;
>
> + /* IPv6 adds a frag_hdr in case RTAX_FEATURE_ALLFRAG is set */
> + if (icsk->icsk_af_ops->net_frag_header_len) {
> + const struct dst_entry *dst = __sk_dst_get(sk);
> +
> + if (dst && dst_allfrag(dst))
> + mtu += icsk->icsk_af_ops->net_frag_header_len;
> + }
> return mtu;
> }
>
> diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
> index cdbf292..57b2109 100644
> --- a/net/ipv6/tcp_ipv6.c
> +++ b/net/ipv6/tcp_ipv6.c
> @@ -1778,6 +1778,7 @@ static const struct inet_connection_sock_af_ops ipv6_specific = {
> .syn_recv_sock = tcp_v6_syn_recv_sock,
> .get_peer = tcp_v6_get_peer,
> .net_header_len = sizeof(struct ipv6hdr),
> + .net_frag_header_len = sizeof(struct frag_hdr),
> .setsockopt = ipv6_setsockopt,
> .getsockopt = ipv6_getsockopt,
> .addr2sockaddr = inet6_csk_addr2sockaddr,
>
>
--
Maciej A. Żenczykowski
Kernel Networking Developer @ Google
1600 Amphitheatre Parkway, Mountain View, CA 94043
tel: +1 (650) 253-0062
^ permalink raw reply
* Hello
From: Abegail Benson @ 2012-04-24 19:40 UTC (permalink / raw)
Hello..
my name is Abegail i seek for a honest
partner for friendship i hope you
don't mind
if you don't mind please reply me i will
like to hear from you ok so i can tell
you more about myself and we
can exchange picture too and share
some other things with love
^ permalink raw reply
* Re: [PATCH] NET: bcm63xx_enet: move phy_(dis)connect into probe/remove
From: Andy Fleming @ 2012-04-24 19:05 UTC (permalink / raw)
To: Jonas Gorski
Cc: mbizon, Andy Fleming, netdev, Florian Fainelli, Eric Dumazet,
David S. Miller
In-Reply-To: <CAOiHx=nG_v11LWoc39236aPyFOjOPXJQz6BVNSVqmXhv_jKDVA@mail.gmail.com>
On Sun, Apr 22, 2012 at 6:31 AM, Jonas Gorski <jonas.gorski@gmail.com> wrote:
> On 19 April 2012 18:17, Maxime Bizon <mbizon@freebox.fr> wrote:
>>
>> On Thu, 2012-04-19 at 16:52 +0200, Jonas Gorski wrote:
>>
>>> Yes, but none of the ethtool functions cause register writes in the
>>> priv->has_phy = true case when in PHY_READY or PHY_HALTED state. All
>>> they do is modify the phy_device's settings.
>>
>> unless I'm mistaken:
>>
>> phy_ethtool_sset() => phy_start_aneg()
>>
>> will kick the state machine even when state is PHY_READY
>
> Hmm. I see what you mean. I wonder if it is intended that you can do
> that without having phy_start() called first.
>
> @Andy, can you perhaps shed some light on this? How are ethernet
> drivers supposed to behave/when should they call
> phy_connect()/phy_start()? Currently most drivers call phy_connect()
> in their _probe(), and phy_start() in _open(), so many seem to have
> the issue that the phy state machine is in PHY_READY after _probe(),
> and can be kicked into running through ethtool even if the interface
> is down.
>
> This problem goes away after the first ifup/ifdown cycle, since the
> phy state machine is then in PHY_HALTED, which gets properly caught in
> phy_start_aneg().
>
> To me it looks like phy_start_aneg() should check for some more
> states, as it currently would also overwrite a PHY_STARTING or
> PHY_PENDING state, which looks definitely wrong to me.
Ugh, it looks like much has gone wrong with the state machine
(possibly from when I wrote it). I'm thinking that what we should
probably do is eliminate PHY_UP and PHY_READY, and have the PHY come
up to PHY_HALTED. For some reason, PHY_RESUMING always enables
interrupts, even if phydev->irq is in POLL mode, so that should be
fixed.
Other than that, it looks like PHY_RESUMING should work in the place
of PHY_UP, and PHY_HALTED should be the same as PHY_READY...
Andy
^ permalink raw reply
* Re: restoring IP multicast addresses when restarting the interface.
From: Flavio Leitner @ 2012-04-24 18:30 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, David Miller
In-Reply-To: <20120423121425.GA29883@gondor.apana.org.au>
On Mon, 23 Apr 2012 22:14:25 +1000
Herbert Xu <herbert@gondor.hengli.com.au> wrote:
> On Fri, Apr 20, 2012 at 09:25:33PM -0300, Flavio Leitner wrote:
> >
> > Although the new behavior seems nice and save some user space
> > work, I think it was unintentional and likely to be a bug.
> >
> > What you guys think?
>
> Are you talking about multicast subscriptions on the interface?
Yes.
> I don't see why they should disappear when the interface goes
> down and then comes back up since these ultimately come from
> application sockets which continue to exist after a down/up.
Yeah, but that's not how things used to work before, so my
question is if the kernel should be responsible for keeping
the subscription or the application.
If the admin puts down the interface and remove the module,
for instance, then the multicast subscription is gone.
Should the application monitor for that then?
David? Any thoughts?
thanks,
fbl
^ permalink raw reply
* Re: [PATCH v2 3/5] change number_of_cpusets to an atomic
From: Christoph Lameter @ 2012-04-24 18:27 UTC (permalink / raw)
To: Glauber Costa
Cc: Tejun Heo, netdev-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA, Li Zefan,
kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A, David Miller,
devel-GEFAQzZX7r8dnm+yROfE0A
In-Reply-To: <4F96D50D.4020804-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
On Tue, 24 Apr 2012, Glauber Costa wrote:
> > > It doesn't seem to be the case here.
> >
> > How did you figure that? number_of_cpusets was introduced exactly because
> > the functions are used in places where we do not pay the cost of calling
> > __cpuset_node_allowed_soft/hardwall. Have a look at these. They may take
> > locks etc etc in critical allocation paths
> I am not arguing that.
>
> You want to avoid the cost of processing a function, that's fair.
> (Note that by "function call cost" I don't mean the cost of processing a
> function, but the cost of a (potentially empty) function call.)
> The real question is: Are you okay with the cost of a branch + a global
> variable (which is almost read only) fetch?
No and that is why the static branching comes in. It takes away the global
read of the number_of_cpusets variable in the critical paths.
> The test of a global variable can - and do as of right now - avoid all the
> expensive operations like locking, sleeping, etc, and if you don't need to
> squeeze every nanosecond you can, they are often simpler - and therefore
> better - than static branching.
Better than static branching? This is in critical VM functions and
reducing the cache footprint there is good for everyone.
> Just to mention one point I am coming across these days - that initiated all
> this: static patching holds the cpu_hotplug.lock. So it can't be called if you
> hold any lock that has been already held under the cpu_hotplug.lock. This will
> probably mean any lock the cpuset cgroup needs to take, because it is called -
> and to do a lot of things - from the cpu hotplug handler, that holds the
> cpu_hotplug.lock.
Transitions from one to two cpusets are rare and are only done when a
cpuset is created in the /dev/cpuset hierachy). You could move the
code modification outside of locks or defer action into an event
thread if there are locks in the way.
^ permalink raw reply
* Re: [PATCH net-next 1/3] Add capability to retrieve plug-in module EEPROM
From: Ben Hutchings @ 2012-04-24 17:44 UTC (permalink / raw)
To: David Miller
Cc: smhodgson, netdev, bruce.w.allan, decot, alexander.h.duyck,
linux-kernel
In-Reply-To: <20120423.172848.1733968863825393980.davem@davemloft.net>
On Mon, 2012-04-23 at 17:28 -0400, David Miller wrote:
> You can't just submit three seperate patches each with the same exact
> Subject line.
>
> Otherwise someone scanning the commit headers can't figure out what
> is different in each of these changes.
>
> There also is no signoff from Ben for patches #2 or #3, did he review
> them? If so, why didn't he ACK or sign off on it? If not, why not?
Sorry, I've been busy with another project. I'll reply to Stuart's
patches faster next round.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH net-next 3/3] Add capability to retrieve plug-in module EEPROM
From: Ben Hutchings @ 2012-04-24 17:43 UTC (permalink / raw)
To: Stuart Hodgson
Cc: netdev, bruce.w.allan, decot, alexander.h.duyck, davem,
linux-kernel
In-Reply-To: <4F9031C7.9070206@solarflare.com>
On Thu, 2012-04-19 at 16:39 +0100, Stuart Hodgson wrote:
> Currently allows for SFP+ eeprom to be returned using the ethtool API.
> This can be extended in future to handle different eeprom formats
> and sizes
[...]
> --- a/drivers/net/ethernet/sfc/mcdi_phy.c
> +++ b/drivers/net/ethernet/sfc/mcdi_phy.c
> @@ -304,6 +304,26 @@ static u32 mcdi_to_ethtool_media(u32 media)
> }
> }
>
> +static u32 mcdi_to_module_eeprom_len(u32 media)
> +{
> + switch (media) {
> + case MC_CMD_MEDIA_SFP_PLUS:
> + return ETH_MODULE_SFF_8079_LEN;
> + default:
> + return 0;
> + }
> +}
> +
> +static u32 mcdi_to_module_eeprom_type(u32 media)
> +{
> + switch (media) {
> + case MC_CMD_MEDIA_SFP_PLUS:
> + return ETH_MODULE_SFF_8079;
> + default:
> + return 0;
> + }
> +}
These functions ended up unused, so don't add them. You should have got
a compiler warning about this...
> static int efx_mcdi_phy_probe(struct efx_nic *efx)
> {
> struct efx_mcdi_phy_data *phy_data;
> @@ -739,6 +759,95 @@ static const char *efx_mcdi_phy_test_name(struct efx_nic *efx,
> return NULL;
> }
>
> +#define SFP_PAGE_SIZE 128
> +#define SFP_NUM_PAGES 2
> +static int efx_mcdi_phy_get_module_eeprom(struct efx_nic *efx,
> + struct ethtool_eeprom *ee, u8 *data)
> +{
> + u8 outbuf[MC_CMD_GET_PHY_MEDIA_INFO_OUT_LENMAX];
> + u8 inbuf[MC_CMD_GET_PHY_MEDIA_INFO_IN_LEN];
> + size_t outlen;
> + int rc;
> + unsigned int payload_len;
> + unsigned int copied = 0;
> + unsigned int space_remaining = ee->len;
> + unsigned int page;
> + unsigned int page_off;
> + unsigned int to_copy;
> + u8 *user_data = data;
> +
> + if (ee->offset > (SFP_PAGE_SIZE * SFP_NUM_PAGES))
> + return -EINVAL;
Please also add this sanity-check:
BUILD_BUG_ON(SFP_PAGE_SIZE * SFP_NUM_PAGES != ETH_MODULE_SFF_8079_LEN);
> + page_off = (ee->offset % SFP_PAGE_SIZE);
> + page = (ee->offset > SFP_PAGE_SIZE) ? 1 : 0;
Off-by-one error; the comparison should be >=. Why not use the
straightforward calculation:
page = ee->offset / SFP_PAGE_SIZE;
[...]
> +static int efx_mcdi_phy_get_module_info(struct efx_nic *efx,
> + struct ethtool_modinfo *modinfo)
> +{
> + /* This will return a length of the eeprom
> + * type of the module that was detected during the probe,
> + * if not modules inserted then phy_data will be NULL */
> + struct efx_mcdi_phy_data *phy_cfg;
> +
> + phy_cfg = efx->phy_data;
> + modinfo->eeprom_len = 0;
> + modinfo->type = 0;
> +
> + switch (phy_cfg->media) {
> + case MC_CMD_MEDIA_SFP_PLUS:
> + modinfo->type = ETH_MODULE_SFF_8079;
> + modinfo->eeprom_len = ETH_MODULE_SFF_8079_LEN;
> + break;
> + default:
The default case should return -EOPNOTSUPP, just as if we didn't
implement this operation at all. And there's no need to set
modinfo->{type,eeprom_len} to 0 in that case.
Ben.
> + break;
> + }
> +
> + return 0;
> +}
[...]
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH net-next] ipv6: RTAX_FEATURE_ALLFRAG causes inefficient TCP segment sizing
From: Eric Dumazet @ 2012-04-24 17:37 UTC (permalink / raw)
To: Tore Anderson, David Miller; +Cc: netdev, Maciej Żenczykowski, Tom Herbert
From: Eric Dumazet <edumazet@google.com>
Quoting Tore Anderson from :
https://bugzilla.kernel.org/show_bug.cgi?id=42572
When RTAX_FEATURE_ALLFRAG is set on a route, the effective TCP segment
size does not take into account the size of the IPv6 Fragmentation
header that needs to be included in outbound packets, causing every
transmitted TCP segment to be fragmented across two IPv6 packets, the
latter of which will only contain 8 bytes of actual payload.
RTAX_FEATURE_ALLFRAG is typically set on a route in response to
receving a ICMPv6 Packet Too Big message indicating a Path MTU of less
than 1280 bytes. 1280 bytes is the minimum IPv6 MTU, however ICMPv6
PTBs with MTU < 1280 are still valid, in particular when an IPv6
packet is sent to an IPv4 destination through a stateless translator.
Any ICMPv4 Need To Fragment packets originated from the IPv4 part of
the path will be translated to ICMPv6 PTB which may then indicate an
MTU of less than 1280.
The Linux kernel refuses to reduce the effective MTU to anything below
1280 bytes, instead it sets it to exactly 1280 bytes, and
RTAX_FEATURE_ALLFRAG is also set. However, the TCP segment size appears
to be set to 1240 bytes (1280 Path MTU - 40 bytes of IPv6 header),
instead of 1232 (additionally taking into account the 8 bytes required
by the IPv6 Fragmentation extension header).
This in turn results in rather inefficient transmission, as every
transmitted TCP segment now is split in two fragments containing
1232+8 bytes of payload.
After this patch, all the outgoing packets that includes a
Fragmentation header all are "atomic" or "non-fragmented" fragments,
i.e., they both have Offset=0 and More Fragments=0.
With help from David S. Miller
Reported-by: Tore Anderson <tore@fud.no>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Maciej Żenczykowski <maze@google.com>
Cc: Tom Herbert <therbert@google.com>
Tested-by: Tore Anderson <tore@fud.no>
---
include/net/inet_connection_sock.h | 1 +
include/net/tcp.h | 4 ++--
net/ipv4/tcp_output.c | 19 +++++++++++++++++--
net/ipv6/tcp_ipv6.c | 1 +
4 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/include/net/inet_connection_sock.h b/include/net/inet_connection_sock.h
index 46c9e2c..7d83f90 100644
--- a/include/net/inet_connection_sock.h
+++ b/include/net/inet_connection_sock.h
@@ -45,6 +45,7 @@ struct inet_connection_sock_af_ops {
struct dst_entry *dst);
struct inet_peer *(*get_peer)(struct sock *sk, bool *release_it);
u16 net_header_len;
+ u16 net_frag_header_len;
u16 sockaddr_len;
int (*setsockopt)(struct sock *sk, int level, int optname,
char __user *optval, unsigned int optlen);
diff --git a/include/net/tcp.h b/include/net/tcp.h
index fc880e9..0fb84de 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -544,8 +544,8 @@ extern int tcp_read_sock(struct sock *sk, read_descriptor_t *desc,
extern void tcp_initialize_rcv_mss(struct sock *sk);
-extern int tcp_mtu_to_mss(const struct sock *sk, int pmtu);
-extern int tcp_mss_to_mtu(const struct sock *sk, int mss);
+extern int tcp_mtu_to_mss(struct sock *sk, int pmtu);
+extern int tcp_mss_to_mtu(struct sock *sk, int mss);
extern void tcp_mtup_init(struct sock *sk);
extern void tcp_valid_rtt_meas(struct sock *sk, u32 seq_rtt);
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 7b7cf38..834e89f 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1150,7 +1150,7 @@ int tcp_trim_head(struct sock *sk, struct sk_buff *skb, u32 len)
}
/* Calculate MSS. Not accounting for SACKs here. */
-int tcp_mtu_to_mss(const struct sock *sk, int pmtu)
+int tcp_mtu_to_mss(struct sock *sk, int pmtu)
{
const struct tcp_sock *tp = tcp_sk(sk);
const struct inet_connection_sock *icsk = inet_csk(sk);
@@ -1161,6 +1161,14 @@ int tcp_mtu_to_mss(const struct sock *sk, int pmtu)
*/
mss_now = pmtu - icsk->icsk_af_ops->net_header_len - sizeof(struct tcphdr);
+ /* IPv6 adds a frag_hdr in case RTAX_FEATURE_ALLFRAG is set */
+ if (icsk->icsk_af_ops->net_frag_header_len) {
+ const struct dst_entry *dst = __sk_dst_get(sk);
+
+ if (dst && dst_allfrag(dst))
+ mss_now -= icsk->icsk_af_ops->net_frag_header_len;
+ }
+
/* Clamp it (mss_clamp does not include tcp options) */
if (mss_now > tp->rx_opt.mss_clamp)
mss_now = tp->rx_opt.mss_clamp;
@@ -1179,7 +1187,7 @@ int tcp_mtu_to_mss(const struct sock *sk, int pmtu)
}
/* Inverse of above */
-int tcp_mss_to_mtu(const struct sock *sk, int mss)
+int tcp_mss_to_mtu(struct sock *sk, int mss)
{
const struct tcp_sock *tp = tcp_sk(sk);
const struct inet_connection_sock *icsk = inet_csk(sk);
@@ -1190,6 +1198,13 @@ int tcp_mss_to_mtu(const struct sock *sk, int mss)
icsk->icsk_ext_hdr_len +
icsk->icsk_af_ops->net_header_len;
+ /* IPv6 adds a frag_hdr in case RTAX_FEATURE_ALLFRAG is set */
+ if (icsk->icsk_af_ops->net_frag_header_len) {
+ const struct dst_entry *dst = __sk_dst_get(sk);
+
+ if (dst && dst_allfrag(dst))
+ mtu += icsk->icsk_af_ops->net_frag_header_len;
+ }
return mtu;
}
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index cdbf292..57b2109 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1778,6 +1778,7 @@ static const struct inet_connection_sock_af_ops ipv6_specific = {
.syn_recv_sock = tcp_v6_syn_recv_sock,
.get_peer = tcp_v6_get_peer,
.net_header_len = sizeof(struct ipv6hdr),
+ .net_frag_header_len = sizeof(struct frag_hdr),
.setsockopt = ipv6_setsockopt,
.getsockopt = ipv6_getsockopt,
.addr2sockaddr = inet6_csk_addr2sockaddr,
^ permalink raw reply related
* Re: [PATCH net-next 2/3] Add capability to retrieve plug-in module EEPROM
From: Ben Hutchings @ 2012-04-24 17:29 UTC (permalink / raw)
To: Stuart Hodgson
Cc: netdev, bruce.w.allan, decot, alexander.h.duyck, davem,
linux-kernel
In-Reply-To: <4F9031CE.1060702@solarflare.com>
On Thu, 2012-04-19 at 16:39 +0100, Stuart Hodgson wrote:
> Provides a new struct ethtool_modinfo that will return the
> type and size of plug-in module eeprom (such as SFP+) for parsing
> by userland program.
>
> The second provides the API to get the raw eeprom information
> using the existing ethtool_eeprom structture to return the data
>
> Signed-off-by: Stuart Hodgson <smhodgson@solarflare.com>
> ---
> include/linux/ethtool.h | 33 +++++++++++++++++++++++++++++++++
> net/core/ethtool.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 80 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> index 89d68d8..f6500f3 100644
> --- a/include/linux/ethtool.h
> +++ b/include/linux/ethtool.h
> @@ -137,6 +137,23 @@ struct ethtool_eeprom {
> };
>
> /**
> + * struct ethtool_modinfo - plugin module eeprom information
> + * @cmd: ETHTOOL_GMODULEINFO
> + * @type: Standard the module information conforms to SFF_xxxx
You renamed the type codes to begin with 'ETH_MODULE_SFF_', so this line
needs to be updated too.
> + * @eeprom_len: Length of the eeprom
> + *
> + * This structure is used to return the information to
> + * properly size memory for a subsequent call to ETHTOOL_GMODULEEEPROM
[...]
The type code is also essential in order to parse the information.
Also, a minor nitpick: you should put a '%' in front of the names of
constants so they can be pretty-printed properly.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH v2 3/5] change number_of_cpusets to an atomic
From: Glauber Costa @ 2012-04-24 16:30 UTC (permalink / raw)
To: Christoph Lameter
Cc: Tejun Heo, netdev-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA, Li Zefan,
kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A, David Miller,
devel-GEFAQzZX7r8dnm+yROfE0A
In-Reply-To: <alpine.DEB.2.00.1204241120130.26005-sBS69tsa9Uj/9pzu0YdTqQ@public.gmane.org>
On 04/24/2012 01:24 PM, Christoph Lameter wrote:
> On Tue, 24 Apr 2012, Glauber Costa wrote:
>
>>> Would this not also be a good case to introduce static branching?
>>>
>>> number_of_cpusets is used to avoid going through unnecessary processing
>>> should there be no cpusets in use.
>>
>> static branches comes with a set of problems themselves, so I usually prefer
>> to use them only in places where we don't want to pay even a cache miss if we
>> can avoid, or a function call, or anything like that - like the slub cache
>> alloc as you may have seen in my kmem memcg series.
>>
>> It doesn't seem to be the case here.
>
> How did you figure that? number_of_cpusets was introduced exactly because
> the functions are used in places where we do not pay the cost of calling
> __cpuset_node_allowed_soft/hardwall. Have a look at these. They may take
> locks etc etc in critical allocation paths
I am not arguing that.
You want to avoid the cost of processing a function, that's fair.
(Note that by "function call cost" I don't mean the cost of processing a
function, but the cost of a (potentially empty) function call.)
The real question is: Are you okay with the cost of a branch + a global
variable (which is almost read only) fetch?
The test of a global variable can - and do as of right now - avoid all
the expensive operations like locking, sleeping, etc, and if you don't
need to squeeze every nanosecond you can, they are often simpler - and
therefore better - than static branching.
Just to mention one point I am coming across these days - that initiated
all this: static patching holds the cpu_hotplug.lock. So it can't be
called if you hold any lock that has been already held under the
cpu_hotplug.lock. This will probably mean any lock the cpuset cgroup
needs to take, because it is called - and to do a lot of things - from
the cpu hotplug handler, that holds the cpu_hotplug.lock.
So if if were a case of simple static branch usage, I am not opposed to
it. But I foresee it getting so complicated, that a global variable
seems to do the job we need just fine.
^ permalink raw reply
* Re: [PATCH v2 3/5] change number_of_cpusets to an atomic
From: Christoph Lameter @ 2012-04-24 16:24 UTC (permalink / raw)
To: Glauber Costa
Cc: Tejun Heo, netdev-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA, Li Zefan,
kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A, David Miller,
devel-GEFAQzZX7r8dnm+yROfE0A
In-Reply-To: <4F96D1A8.6040604-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
On Tue, 24 Apr 2012, Glauber Costa wrote:
> > Would this not also be a good case to introduce static branching?
> >
> > number_of_cpusets is used to avoid going through unnecessary processing
> > should there be no cpusets in use.
>
> static branches comes with a set of problems themselves, so I usually prefer
> to use them only in places where we don't want to pay even a cache miss if we
> can avoid, or a function call, or anything like that - like the slub cache
> alloc as you may have seen in my kmem memcg series.
>
> It doesn't seem to be the case here.
How did you figure that? number_of_cpusets was introduced exactly because
the functions are used in places where we do not pay the cost of calling
__cpuset_node_allowed_soft/hardwall. Have a look at these. They may take
locks etc etc in critical allocation paths
^ permalink raw reply
* Re: [RFC v4] Add TCP encap_rcv hook (repost)
From: Kyle Mestery (kmestery) @ 2012-04-24 16:16 UTC (permalink / raw)
To: Stephen Hemminger
Cc: <dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org>,
<eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
<netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
<jhs-jkUAjuhPggJWk0Htik3J/w@public.gmane.org>,
<stephen.hemminger-ZtmgI6mnKB3QT0dZR+AlfA@public.gmane.org>,
David Miller
In-Reply-To: <20120424091317.08953fd2-We1ePj4FEcvRI77zikRAJc56i+j3xesD0e7PPNI6Mm0@public.gmane.org>
On Apr 24, 2012, at 11:13 AM, Stephen Hemminger wrote:
> On Tue, 24 Apr 2012 16:02:41 +0000
> "Kyle Mestery (kmestery)" <kmestery-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> wrote:
>
>> On Apr 23, 2012, at 9:25 PM, Simon Horman wrote:
>>> On Mon, Apr 23, 2012 at 03:59:24PM -0700, Jesse Gross wrote:
>>>> On Mon, Apr 23, 2012 at 3:32 PM, Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
>>>>> On Mon, Apr 23, 2012 at 02:38:07PM -0700, Jesse Gross wrote:
>>>>>> On Mon, Apr 23, 2012 at 2:08 PM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
>>>>>>> From: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
>>>>>>> Date: Mon, 23 Apr 2012 13:53:42 -0700
>>>>>>>
>>>>>>>> On Mon, Apr 23, 2012 at 1:13 PM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
>>>>>>>>> From: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
>>>>>>>>> Date: Mon, 23 Apr 2012 13:08:49 -0700
>>>>>>>>>
>>>>>>>>>> Assuming that the TCP stack generates large TSO frames on transmit
>>>>>>>>>> (which could be the local stack; something sent by a VM; or packets
>>>>>>>>>> received, coalesced by GRO and then encapsulated by STT) then you can
>>>>>>>>>> just prepend the STT header (possibly slightly adjusting things like
>>>>>>>>>> requested MSS, number of segments, etc. slightly). After that it's
>>>>>>>>>> possible to just output the resulting frame through the IP stack like
>>>>>>>>>> all tunnels do today.
>>>>>>>>>
>>>>>>>>> Which seems to potentially suggest a stronger intergration of the STT
>>>>>>>>> tunnel transmit path into our IP stack rather than the approach Simon
>>>>>>>>> is taking
>>>>>>>>
>>>>>>>> Did you have something in mind?
>>>>>>>
>>>>>>> A normal bonafide tunnel netdevice driver like GRE instead of the
>>>>>>> openvswitch approach Simon is using.
>>>>>>
>>>>>> Ahh, yes, that I agree with. Independent of this, there's work being
>>>>>> done to make it so that OVS can use the normal in-tree tunneling code
>>>>>> and not need its own. Once that's done I expect that STT will follow
>>>>>> the same model.
>>>>>
>>>>> Hi Jesse,
>>>>>
>>>>> I am wondering how firm the plans to on allowing OVS to use in-tree tunnel
>>>>> code are. I'm happy to move my efforts over to an in-tree STT implementation
>>>>> but ultimately I would like to get STT running in conjunction with OVS.
>>>>
>>>> I would say that it's a firm goal but the implementation probably
>>>> still has a ways to go. Kyle Mestery (CC'ed) has volunteered to work
>>>> on this in support of adding VXLAN, which needs some additional
>>>> flexibility that this approach would also provide. You might want to
>>>> talk to him to see if there are ways that you guys can work together
>>>> on it if you are interested. Having better integration with upstream
>>>> tunneling is definitely a step that OVS needs to make and sooner would
>>>> be better than later.
>>>
>>> Hi Jesse, Hi Kyle,
>>>
>>> that sounds like an excellent plan.
>>>
>>> Kyle, do you have any thoughts on how we might best work together on this?
>>> Perhaps there are some patches floating around that I could take a look at?
>>>
>>
>> Hi Simon:
>>
>> The VXLAN work has been slow going for me at this point. What I have works, but is far from complete. It's available here:
>>
>> https://github.com/mestery/ovs-vxlan/tree/vxlan
>>
>> This is based on a fairly recent version of OVS. I'm currently working to allow tunnels to be flow-based rather than port-based, as they currently exist. As Jesse may have mentioned, doing this allows us to move most tunnel state into user space. The outer header can now be part of the flow lookup and can be passed to user space, so things like multicast learning for VXLAN become possible.
>>
>> With regards to working together, ping me off-list and we can work something out, I'm very much in favor of this!
>>
>
> My use of VXVLAN was to be key based (like existing GRE), not flow based.
>
Yes, for OVS the idea is to add the tunnel key values to the flow-key in the OVS kernel module.
^ permalink raw reply
* Re: [PATCH v2 3/5] change number_of_cpusets to an atomic
From: Glauber Costa @ 2012-04-24 16:15 UTC (permalink / raw)
To: Christoph Lameter
Cc: Tejun Heo, netdev-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA, Li Zefan,
kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A, David Miller,
devel-GEFAQzZX7r8dnm+yROfE0A
In-Reply-To: <alpine.DEB.2.00.1204241001050.26005-sBS69tsa9Uj/9pzu0YdTqQ@public.gmane.org>
On 04/24/2012 12:02 PM, Christoph Lameter wrote:
> On Mon, 23 Apr 2012, Glauber Costa wrote:
>
>> This will allow us to call destroy() without holding the
>> cgroup_mutex(). Other important updates inside update_flags()
>> are protected by the callback_mutex.
>>
>> We could protect this variable with the callback_mutex as well,
>> as suggested by Li Zefan, but we need to make sure we are protected
>> by that mutex at all times, and some of its updates happen inside the
>> cgroup_mutex - which means we would deadlock.
>
> Would this not also be a good case to introduce static branching?
>
> number_of_cpusets is used to avoid going through unnecessary processing
> should there be no cpusets in use.
>
Well,
static branches comes with a set of problems themselves, so I usually
prefer to use them only in places where we don't want to pay even a
cache miss if we can avoid, or a function call, or anything like that -
like the slub cache alloc as you may have seen in my kmem memcg series.
It doesn't seem to be the case here.
^ permalink raw reply
* Re: [RFC v4] Add TCP encap_rcv hook (repost)
From: Stephen Hemminger @ 2012-04-24 16:13 UTC (permalink / raw)
To: Kyle Mestery (kmestery)
Cc: <dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org>,
<eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
<netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
<jhs-jkUAjuhPggJWk0Htik3J/w@public.gmane.org>,
David-/PVsmBQoxgPKo9QCiBeYKEEOCMrvLtNR,
<stephen.hemminger-ZtmgI6mnKB3QT0dZR+AlfA@public.gmane.org>,
Miller
In-Reply-To: <807AC914-2F33-46C7-99DC-E2F8F0F97531-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
On Tue, 24 Apr 2012 16:02:41 +0000
"Kyle Mestery (kmestery)" <kmestery-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> wrote:
> On Apr 23, 2012, at 9:25 PM, Simon Horman wrote:
> > On Mon, Apr 23, 2012 at 03:59:24PM -0700, Jesse Gross wrote:
> >> On Mon, Apr 23, 2012 at 3:32 PM, Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
> >>> On Mon, Apr 23, 2012 at 02:38:07PM -0700, Jesse Gross wrote:
> >>>> On Mon, Apr 23, 2012 at 2:08 PM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
> >>>>> From: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
> >>>>> Date: Mon, 23 Apr 2012 13:53:42 -0700
> >>>>>
> >>>>>> On Mon, Apr 23, 2012 at 1:13 PM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
> >>>>>>> From: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
> >>>>>>> Date: Mon, 23 Apr 2012 13:08:49 -0700
> >>>>>>>
> >>>>>>>> Assuming that the TCP stack generates large TSO frames on transmit
> >>>>>>>> (which could be the local stack; something sent by a VM; or packets
> >>>>>>>> received, coalesced by GRO and then encapsulated by STT) then you can
> >>>>>>>> just prepend the STT header (possibly slightly adjusting things like
> >>>>>>>> requested MSS, number of segments, etc. slightly). After that it's
> >>>>>>>> possible to just output the resulting frame through the IP stack like
> >>>>>>>> all tunnels do today.
> >>>>>>>
> >>>>>>> Which seems to potentially suggest a stronger intergration of the STT
> >>>>>>> tunnel transmit path into our IP stack rather than the approach Simon
> >>>>>>> is taking
> >>>>>>
> >>>>>> Did you have something in mind?
> >>>>>
> >>>>> A normal bonafide tunnel netdevice driver like GRE instead of the
> >>>>> openvswitch approach Simon is using.
> >>>>
> >>>> Ahh, yes, that I agree with. Independent of this, there's work being
> >>>> done to make it so that OVS can use the normal in-tree tunneling code
> >>>> and not need its own. Once that's done I expect that STT will follow
> >>>> the same model.
> >>>
> >>> Hi Jesse,
> >>>
> >>> I am wondering how firm the plans to on allowing OVS to use in-tree tunnel
> >>> code are. I'm happy to move my efforts over to an in-tree STT implementation
> >>> but ultimately I would like to get STT running in conjunction with OVS.
> >>
> >> I would say that it's a firm goal but the implementation probably
> >> still has a ways to go. Kyle Mestery (CC'ed) has volunteered to work
> >> on this in support of adding VXLAN, which needs some additional
> >> flexibility that this approach would also provide. You might want to
> >> talk to him to see if there are ways that you guys can work together
> >> on it if you are interested. Having better integration with upstream
> >> tunneling is definitely a step that OVS needs to make and sooner would
> >> be better than later.
> >
> > Hi Jesse, Hi Kyle,
> >
> > that sounds like an excellent plan.
> >
> > Kyle, do you have any thoughts on how we might best work together on this?
> > Perhaps there are some patches floating around that I could take a look at?
> >
>
> Hi Simon:
>
> The VXLAN work has been slow going for me at this point. What I have works, but is far from complete. It's available here:
>
> https://github.com/mestery/ovs-vxlan/tree/vxlan
>
> This is based on a fairly recent version of OVS. I'm currently working to allow tunnels to be flow-based rather than port-based, as they currently exist. As Jesse may have mentioned, doing this allows us to move most tunnel state into user space. The outer header can now be part of the flow lookup and can be passed to user space, so things like multicast learning for VXLAN become possible.
>
> With regards to working together, ping me off-list and we can work something out, I'm very much in favor of this!
>
My use of VXVLAN was to be key based (like existing GRE), not flow based.
^ permalink raw reply
* Re: [RFC v4] Add TCP encap_rcv hook (repost)
From: Kyle Mestery (kmestery) @ 2012-04-24 16:02 UTC (permalink / raw)
To: Simon Horman
Cc: <dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org>,
<eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
<netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
<jhs-jkUAjuhPggJWk0Htik3J/w@public.gmane.org>,
<stephen.hemminger-ZtmgI6mnKB3QT0dZR+AlfA@public.gmane.org>,
<shemminger-ZtmgI6mnKB3QT0dZR+AlfA@public.gmane.org>,
David Miller
In-Reply-To: <20120424022514.GB5357-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
On Apr 23, 2012, at 9:25 PM, Simon Horman wrote:
> On Mon, Apr 23, 2012 at 03:59:24PM -0700, Jesse Gross wrote:
>> On Mon, Apr 23, 2012 at 3:32 PM, Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
>>> On Mon, Apr 23, 2012 at 02:38:07PM -0700, Jesse Gross wrote:
>>>> On Mon, Apr 23, 2012 at 2:08 PM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
>>>>> From: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
>>>>> Date: Mon, 23 Apr 2012 13:53:42 -0700
>>>>>
>>>>>> On Mon, Apr 23, 2012 at 1:13 PM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
>>>>>>> From: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
>>>>>>> Date: Mon, 23 Apr 2012 13:08:49 -0700
>>>>>>>
>>>>>>>> Assuming that the TCP stack generates large TSO frames on transmit
>>>>>>>> (which could be the local stack; something sent by a VM; or packets
>>>>>>>> received, coalesced by GRO and then encapsulated by STT) then you can
>>>>>>>> just prepend the STT header (possibly slightly adjusting things like
>>>>>>>> requested MSS, number of segments, etc. slightly). After that it's
>>>>>>>> possible to just output the resulting frame through the IP stack like
>>>>>>>> all tunnels do today.
>>>>>>>
>>>>>>> Which seems to potentially suggest a stronger intergration of the STT
>>>>>>> tunnel transmit path into our IP stack rather than the approach Simon
>>>>>>> is taking
>>>>>>
>>>>>> Did you have something in mind?
>>>>>
>>>>> A normal bonafide tunnel netdevice driver like GRE instead of the
>>>>> openvswitch approach Simon is using.
>>>>
>>>> Ahh, yes, that I agree with. Independent of this, there's work being
>>>> done to make it so that OVS can use the normal in-tree tunneling code
>>>> and not need its own. Once that's done I expect that STT will follow
>>>> the same model.
>>>
>>> Hi Jesse,
>>>
>>> I am wondering how firm the plans to on allowing OVS to use in-tree tunnel
>>> code are. I'm happy to move my efforts over to an in-tree STT implementation
>>> but ultimately I would like to get STT running in conjunction with OVS.
>>
>> I would say that it's a firm goal but the implementation probably
>> still has a ways to go. Kyle Mestery (CC'ed) has volunteered to work
>> on this in support of adding VXLAN, which needs some additional
>> flexibility that this approach would also provide. You might want to
>> talk to him to see if there are ways that you guys can work together
>> on it if you are interested. Having better integration with upstream
>> tunneling is definitely a step that OVS needs to make and sooner would
>> be better than later.
>
> Hi Jesse, Hi Kyle,
>
> that sounds like an excellent plan.
>
> Kyle, do you have any thoughts on how we might best work together on this?
> Perhaps there are some patches floating around that I could take a look at?
>
Hi Simon:
The VXLAN work has been slow going for me at this point. What I have works, but is far from complete. It's available here:
https://github.com/mestery/ovs-vxlan/tree/vxlan
This is based on a fairly recent version of OVS. I'm currently working to allow tunnels to be flow-based rather than port-based, as they currently exist. As Jesse may have mentioned, doing this allows us to move most tunnel state into user space. The outer header can now be part of the flow lookup and can be passed to user space, so things like multicast learning for VXLAN become possible.
With regards to working together, ping me off-list and we can work something out, I'm very much in favor of this!
Thanks!
Kyle
^ permalink raw reply
* Re: [PATCH v2] smsc95xx: mark link down on startup and let PHY interrupt deal with carrier changes
From: Steve Glendinning @ 2012-04-24 15:45 UTC (permalink / raw)
To: David Miller; +Cc: fillods, paolo.pisati, steve.glendinning, netdev
In-Reply-To: <20120424.004240.51699724664176823.davem@davemloft.net>
Hi all,
On 24 April 2012 05:42, David Miller <davem@davemloft.net> wrote:
>>> v2: added mantainer to the list of recipient
>>
>> His e-mail address has changed, but somehow it has not been updated yet
>> in MAINTAINERS directory: steve.glendinning () shawell.net
>
> Steve, please send a maintainers etc. update and please provide
> feedback on this link status fix.
I submitted an update to MAINTAINERS last week, I don't think it's
been picked up yet.
Thanks for the patch Paulo, I'd like to test this out. I'll get back
to you in a few days.
--
Steve Glendinning
^ permalink raw reply
* Re: [PATCH 2/2 net-next] tcp: sk_add_backlog() is too agressive for TCP
From: Christoph Lameter @ 2012-04-24 15:25 UTC (permalink / raw)
To: Rick Jones
Cc: Eric Dumazet, David Miller, netdev, therbert, ncardwell, maze,
ycheng, ilpo.jarvinen
In-Reply-To: <4F95D4CA.7020005@hp.com>
On Mon, 23 Apr 2012, Rick Jones wrote:
> Is it at all possible to have the copies happen without the connection being
> locked? If indeed it is possible to be held-off with the connection locked
> for the better part of 3/4 of a millisecond, just what will that do to 40 or
> 100 GbE? If you've been seeing queues of 300 ACKs at 10 GbE that would be
> 3000 at 100 GbE, and assuming those are all in a 2048 byte buffer thats 6MB
> just of ACKs. I suppose 100GbE does mean non-trivial quantities of buffering
> anyway but that does still seem rather high.
At some point people will need to realize that it is not business as usual
if one tries to use the current network porotocols at speeds above 1G.
There is a reason for high speed networks implementing new protocols like
RDMA techniques and lossless characteristics of a network.
^ permalink raw reply
* Re: [PATCH v2 3/5] change number_of_cpusets to an atomic
From: Christoph Lameter @ 2012-04-24 15:02 UTC (permalink / raw)
To: Glauber Costa
Cc: Tejun Heo, netdev, cgroups, Li Zefan, kamezawa.hiroyu,
David Miller, devel
In-Reply-To: <1335209867-1831-4-git-send-email-glommer@parallels.com>
On Mon, 23 Apr 2012, Glauber Costa wrote:
> This will allow us to call destroy() without holding the
> cgroup_mutex(). Other important updates inside update_flags()
> are protected by the callback_mutex.
>
> We could protect this variable with the callback_mutex as well,
> as suggested by Li Zefan, but we need to make sure we are protected
> by that mutex at all times, and some of its updates happen inside the
> cgroup_mutex - which means we would deadlock.
Would this not also be a good case to introduce static branching?
number_of_cpusets is used to avoid going through unnecessary processing
should there be no cpusets in use.
^ permalink raw reply
* Problem with iosize in Davicom DM9000 driver
From: jonsmirl @ 2012-04-24 14:54 UTC (permalink / raw)
To: netdev
In the probe code of the DM9000 driver...
iosize = resource_size(db->data_res);
------ iosize is the size of the resource block
static inline resource_size_t resource_size(const struct resource *res)
{
return res->end - res->start + 1;
}
db->data_req = request_mem_region(db->data_res->start, iosize,
pdev->name);
if (db->data_req == NULL) {
dev_err(db->dev, "cannot claim data reg area\n");
ret = -EIO;
goto out;
}
db->io_data = ioremap(db->data_res->start, iosize);
if (db->io_data == NULL) {
dev_err(db->dev, "failed to ioremap data reg\n");
ret = -EINVAL;
goto out;
}
/* fill in parameters for net-dev structure */
ndev->base_addr = (unsigned long)db->io_addr;
ndev->irq = db->irq_res->start;
/* ensure at least we have a default set of IO routines */
dm9000_set_io(db, iosize);
--------------------------
---- but it is passed into this routine which is expecting byte_width.
---- luckily the default case turns it into 32b IO which works on most systems.
---- I hit this working on a system with a 16b bus
static void dm9000_set_io(struct board_info *db, int byte_width)
{
/* use the size of the data resource to work out what IO
* routines we want to use
*/
switch (byte_width) {
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH 2/4] mISDN: Fixed hardware bridging/conference check routine of mISDN_dsp.ko.
From: Karsten Keil @ 2012-04-24 12:51 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Andreas Eversberg
In-Reply-To: <1335271912-5269-1-git-send-email-kkeil@linux-pingi.de>
From: Andreas Eversberg <jolly@eversberg.eu>
In some cases the hardware bridging/conference (2-n parties) was selected,
but still pure software bridging/conference was used.
Signed-off-by: Andreas Eversberg <jolly@eversberg.eu>
Signed-off-by: Karsten Keil <keil@b1-systems.de>
---
drivers/isdn/mISDN/dsp_cmx.c | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/isdn/mISDN/dsp_cmx.c b/drivers/isdn/mISDN/dsp_cmx.c
index b7589c2..0c104b9 100644
--- a/drivers/isdn/mISDN/dsp_cmx.c
+++ b/drivers/isdn/mISDN/dsp_cmx.c
@@ -742,8 +742,8 @@ dsp_cmx_hardware(struct dsp_conf *conf, struct dsp *dsp)
member->dsp->pcm_slot_tx,
member->dsp->pcm_bank_tx,
member->dsp->pcm_bank_rx);
- conf->hardware = 0;
- conf->software = 1;
+ conf->hardware = 1;
+ conf->software = tx_data;
return;
}
/* find a new slot */
@@ -834,8 +834,8 @@ dsp_cmx_hardware(struct dsp_conf *conf, struct dsp *dsp)
nextm->dsp->name,
member->dsp->pcm_slot_tx,
member->dsp->pcm_slot_rx);
- conf->hardware = 0;
- conf->software = 1;
+ conf->hardware = 1;
+ conf->software = tx_data;
return;
}
/* find two new slot */
@@ -939,8 +939,11 @@ dsp_cmx_hardware(struct dsp_conf *conf, struct dsp *dsp)
/* for more than two members.. */
/* if all members already have the same conference */
- if (all_conf)
+ if (all_conf) {
+ conf->hardware = 1;
+ conf->software = tx_data;
return;
+ }
/*
* if there is an existing conference, but not all members have joined
@@ -1013,6 +1016,8 @@ dsp_cmx_hardware(struct dsp_conf *conf, struct dsp *dsp)
dsp_cmx_hw_message(member->dsp,
MISDN_CTRL_HFC_CONF_JOIN, current_conf, 0, 0, 0);
}
+ conf->hardware = 1;
+ conf->software = tx_data;
return;
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH 1/4] mISDN: Fix NULL pointer bug in if-condition of mISDN_dsp
From: Karsten Keil @ 2012-04-24 12:51 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Andreas Eversberg
In-Reply-To: <1335271912-5269-1-git-send-email-kkeil@linux-pingi.de>
From: Andreas Eversberg <jolly@eversberg.eu>
Fix a bug (was introduced by a cut & paste error)
in cases when dsp->conf was NULL.
Signed-off-by: Andreas Eversberg <jolly@eversberg.eu>
Signed-off-by: Karsten Keil <keil@b1-systems.de>
---
drivers/isdn/mISDN/dsp_cmx.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/isdn/mISDN/dsp_cmx.c b/drivers/isdn/mISDN/dsp_cmx.c
index 334feab..b7589c2 100644
--- a/drivers/isdn/mISDN/dsp_cmx.c
+++ b/drivers/isdn/mISDN/dsp_cmx.c
@@ -1328,7 +1328,7 @@ dsp_cmx_send_member(struct dsp *dsp, int len, s32 *c, int members)
}
if (dsp->conf && dsp->conf->software && dsp->conf->hardware)
tx_data_only = 1;
- if (dsp->conf->software && dsp->echo.hardware)
+ if (dsp->echo.software && dsp->echo.hardware)
tx_data_only = 1;
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH 4/4] mISDN: DSP scheduling fix
From: Karsten Keil @ 2012-04-24 12:51 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Karsten Keil
In-Reply-To: <1335271912-5269-1-git-send-email-kkeil@linux-pingi.de>
From: Karsten Keil <isdn@linux-pingi.de>
dsp_spl_jiffies need to be the same datatype as jiffies (which is ulong).
If not, on 64 bit systems it will fallback to schedule the DSP every jiffie
tic as soon jiffies become > 2^32.
Signed-off-by: Karsten Keil <kkeil@linux-pingi.de>
---
drivers/isdn/mISDN/dsp.h | 4 +++-
drivers/isdn/mISDN/dsp_cmx.c | 2 +-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/isdn/mISDN/dsp.h b/drivers/isdn/mISDN/dsp.h
index afe4173..e020957 100644
--- a/drivers/isdn/mISDN/dsp.h
+++ b/drivers/isdn/mISDN/dsp.h
@@ -76,7 +76,9 @@ extern u8 dsp_silence;
#define MAX_SECONDS_JITTER_CHECK 5
extern struct timer_list dsp_spl_tl;
-extern u32 dsp_spl_jiffies;
+
+/* the datatype need to match jiffies datatype */
+extern ulong dsp_spl_jiffies;
/* the structure of conferences:
*
diff --git a/drivers/isdn/mISDN/dsp_cmx.c b/drivers/isdn/mISDN/dsp_cmx.c
index 0c104b9..3a3b3a5 100644
--- a/drivers/isdn/mISDN/dsp_cmx.c
+++ b/drivers/isdn/mISDN/dsp_cmx.c
@@ -1624,7 +1624,7 @@ send_packet:
static u32 jittercount; /* counter for jitter check */
struct timer_list dsp_spl_tl;
-u32 dsp_spl_jiffies; /* calculate the next time to fire */
+ulong dsp_spl_jiffies; /* calculate the next time to fire */
static u16 dsp_count; /* last sample count */
static int dsp_count_valid; /* if we have last sample count */
--
1.7.3.4
^ permalink raw reply related
* [PATCH 0/4] mISDN: Bugfixes for the mISDN DSP core
From: Karsten Keil @ 2012-04-24 12:51 UTC (permalink / raw)
To: David Miller; +Cc: netdev
This collection are bugfixes for the DSP functions of the mISDN
core.
Tested against net-next.
Hopeful the submission format is OK now with git send-email
(before I used sendmail).
Andreas Eversberg (2):
mISDN: Fix NULL pointer bug in if-condition of mISDN_dsp
mISDN: Fixed hardware bridging/conference check routine of
mISDN_dsp.ko.
Karsten Keil (2):
mISDN: Fix division by zero
mISDN: DSP scheduling fix
drivers/isdn/mISDN/dsp.h | 4 +++-
drivers/isdn/mISDN/dsp_cmx.c | 19 ++++++++++++-------
drivers/isdn/mISDN/dsp_dtmf.c | 19 ++++++++++++++-----
3 files changed, 29 insertions(+), 13 deletions(-)
--
1.7.3.4
^ permalink raw reply
* [PATCH 3/4] mISDN: Fix division by zero
From: Karsten Keil @ 2012-04-24 12:51 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Karsten Keil
In-Reply-To: <1335271912-5269-1-git-send-email-kkeil@linux-pingi.de>
From: Karsten Keil <isdn@linux-pingi.de>
If DTMF debug is set and tresh goes under 100, the printk will cause
a division by zero.
Signed-off-by: Karsten Keil <kkeil@linux-pingi.de>
---
drivers/isdn/mISDN/dsp_dtmf.c | 19 ++++++++++++++-----
1 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/isdn/mISDN/dsp_dtmf.c b/drivers/isdn/mISDN/dsp_dtmf.c
index 887860b..642f30b 100644
--- a/drivers/isdn/mISDN/dsp_dtmf.c
+++ b/drivers/isdn/mISDN/dsp_dtmf.c
@@ -222,16 +222,25 @@ coefficients:
goto storedigit;
}
- if (dsp_debug & DEBUG_DSP_DTMFCOEFF)
+ if (dsp_debug & DEBUG_DSP_DTMFCOEFF) {
+ s32 tresh_100 = tresh/100;
+
+ if (tresh_100 == 0) {
+ tresh_100 = 1;
+ printk(KERN_DEBUG
+ "tresh(%d) too small set tresh/100 to 1\n",
+ tresh);
+ }
printk(KERN_DEBUG "a %3d %3d %3d %3d %3d %3d %3d %3d"
" tr:%3d r %3d %3d %3d %3d %3d %3d %3d %3d\n",
result[0] / 10000, result[1] / 10000, result[2] / 10000,
result[3] / 10000, result[4] / 10000, result[5] / 10000,
result[6] / 10000, result[7] / 10000, tresh / 10000,
- result[0] / (tresh / 100), result[1] / (tresh / 100),
- result[2] / (tresh / 100), result[3] / (tresh / 100),
- result[4] / (tresh / 100), result[5] / (tresh / 100),
- result[6] / (tresh / 100), result[7] / (tresh / 100));
+ result[0] / (tresh_100), result[1] / (tresh_100),
+ result[2] / (tresh_100), result[3] / (tresh_100),
+ result[4] / (tresh_100), result[5] / (tresh_100),
+ result[6] / (tresh_100), result[7] / (tresh_100));
+ }
/* calc digit (lowgroup/highgroup) */
lowgroup = -1;
--
1.7.3.4
^ permalink raw reply related
* Re: net_sched: gred: red_calc_qavg() called with current qavg for backlog?
From: Thomas Graf @ 2012-04-24 12:37 UTC (permalink / raw)
To: David Miller; +Cc: david.ward, tgraf, eric.dumazet, netdev
In-Reply-To: <20120421.161032.2225288178918492428.davem@davemloft.net>
On Sat, Apr 21, 2012 at 04:10:32PM -0400, David Miller wrote:
> From: "Ward, David - 0663 - MITLL" <david.ward@ll.mit.edu>
> Date: Sat, 21 Apr 2012 14:46:31 -0400
>
> > In net/sched/sch_gred.c:
> >
> > static int gred_dump(struct Qdisc *sch, struct sk_buff *skb)
> > {
> > struct gred_sched *table = qdisc_priv(sch);
> > ...
> > for (i = 0; i < MAX_DPs; i++) {
> > struct gred_sched_data *q = table->tab[i];
> > struct tc_gred_qopt opt;
> > ...
> > opt.qave = red_calc_qavg(&q->parms, &q->vars, q->vars.qavg);
> >
> >
> > I can't tell if red_calc_qavg is intentionally being passed the current
> > qavg as the backlog (which effectively causes qavg to only be
> > re-calculated if we are idling)? Or should this be:
> >
> > opt.qave = red_calc_qavg(&q->parms,
> > &q->vars,
> > gred_backlog(table, q, sch));
>
> Looking at commit 22b33429ab93155895854e9518a253680a920493
> ("[PKT_SCHED]: GRED: Use new generic red interface") it appears
> that this line is intentional so that the dump reports the same
> qave as it would have before Thomas's changes.
When doing the convert, I simply preserved behaviour. I am not sure on
what basis the original behaviour has been written.
^ 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