* [PATCH net-next] tcp: avoid frag allocation for small frames
From: Eric Dumazet @ 2011-11-29 8:41 UTC (permalink / raw)
To: David Miller; +Cc: netdev, subramanian.vijay
tcp_sendmsg() uses select_size() helper to choose skb head size when a
new skb must be allocated.
If GSO is enabled for the socket, current strategy is to force all
payload data to be outside of headroom, in PAGE fragments.
This strategy is not welcome for small packets, wasting memory.
Experiments show that best results are obtained when using 2048 bytes
for skb head (This includes the skb overhead and various headers)
This patch provides better len/truesize ratios for packets sent to
loopback device, and reduce memory needs for in-flight loopback packets,
particularly on arches with big pages.
If a sender sends many 1-byte packets to an unresponsive application,
receiver rmem_alloc will grow faster and will stop queuing these packets
sooner, or will collapse its receive queue to free excess memory.
netperf -t TCP_RR results are improved by ~4 %, and many workloads are
improved as well (tbench, mysql...)
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/ipv4/tcp.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 704adad..cd45b44 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -897,9 +897,12 @@ static inline int select_size(const struct sock *sk, int sg)
int tmp = tp->mss_cache;
if (sg) {
- if (sk_can_gso(sk))
- tmp = 0;
- else {
+ if (sk_can_gso(sk)) {
+ /* Small frames wont use a full page:
+ * Payload will immediately follow tcp header.
+ */
+ tmp = SKB_WITH_OVERHEAD(2048 - MAX_TCP_HEADER);
+ } else {
int pgbreak = SKB_MAX_HEAD(MAX_TCP_HEADER);
if (tmp >= pgbreak &&
^ permalink raw reply related
* Re: [PATCH v4 0/10] bql: Byte Queue Limits
From: Dave Taht @ 2011-11-29 8:37 UTC (permalink / raw)
To: John Fastabend
Cc: Eric Dumazet, Tom Herbert, davem@davemloft.net,
netdev@vger.kernel.org
In-Reply-To: <4ED4885F.8060309@intel.com>
On Tue, Nov 29, 2011 at 8:23 AM, John Fastabend
<john.r.fastabend@intel.com> wrote:
>
> I wonder if we should consider enabling TSO/GSO per queue or per traffic
> class on devices that support this. At least in devices that support
> multiple traffic classes it seems to be a common usage case to put bulk
> storage traffic (iSCSI) on a traffic class and low latency traffic on a
> separate traffic class, VoIP for example.
VOIP is a drop in the bucket.
Turning TSO off on TCP exiting the datacenter (or more specifically),
destined anywhere there is potential tx/rx bandwidth disparity
would be goooooood.
>
> John.
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
^ permalink raw reply
* Re: pull request: wireless-next 2011-11-28
From: Johannes Berg @ 2011-11-29 8:22 UTC (permalink / raw)
To: John W. Linville
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20111128200221.GD2681-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
On Mon, 2011-11-28 at 15:02 -0500, John W. Linville wrote:
> Johannes Berg (12):
> mac80211: use skb list for fragments
> mac80211: move fragment flag adjustment
> mac80211: make TX LED handling independent of fragmentation
> mac80211: transmit fragment list to drivers
Since you included these patches, can you please pick up "mac80211: fix
TX warning" relatively quickly? It fixes a harmless but possibly
recurring WARN_ON in this code.
johannes
--
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: [PATCH net-next] tcp: avoid frag allocation for small frames
From: David Miller @ 2011-11-29 8:13 UTC (permalink / raw)
To: eric.dumazet; +Cc: subramanian.vijay, netdev
In-Reply-To: <1322553110.2970.79.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 29 Nov 2011 08:51:50 +0100
> David, do you want me to respin this ?
Please do, thank you.
^ permalink raw reply
* Re: [PATCH v4 0/10] bql: Byte Queue Limits
From: John Fastabend @ 2011-11-29 8:03 UTC (permalink / raw)
To: Eric Dumazet
Cc: Dave Taht, Tom Herbert, davem@davemloft.net,
netdev@vger.kernel.org
In-Reply-To: <1322552733.2970.78.camel@edumazet-laptop>
On 11/28/2011 11:45 PM, Eric Dumazet wrote:
> Le lundi 28 novembre 2011 à 23:23 -0800, John Fastabend a écrit :
>
>> I wonder if we should consider enabling TSO/GSO per queue or per traffic
>> class on devices that support this. At least in devices that support
>> multiple traffic classes it seems to be a common usage case to put bulk
>> storage traffic (iSCSI) on a traffic class and low latency traffic on a
>> separate traffic class, VoIP for example.
>>
>
> It all depends on how device itself is doing its mux from queues to
> ethernet wire. If queue 0 starts transmit of one 64KB 'super packet',
> will queue 1 be able to insert a litle frame between the frames of queue
> 0 ?
>
Yes this works at least on the ixgbe supported 82599 device as you
would hope. 'super packets' from queues can and will be interleaved,
perhaps with standard sized packets, depending on the currently
configured arbitration scheme. So with multiple traffic classes we
can make a link strict 'low latency' class to TX frames as soon as
they are available.
Also I would expect this to work correctly on any of the coined
CNA devices, the bnx2x devices for example. I'll probably see what
can be done after finishing up some other things first.
^ permalink raw reply
* Re: [PATCH net-next] tcp: avoid frag allocation for small frames
From: Eric Dumazet @ 2011-11-29 7:51 UTC (permalink / raw)
To: Vijay Subramanian; +Cc: netdev
In-Reply-To: <CAGK4HS_Nryz6jWuqcHPu8AK1Rp6kFRp6M_y-yaGFcnX+pjX47Q@mail.gmail.com>
Le lundi 28 novembre 2011 à 17:04 -0800, Vijay Subramanian a écrit :
> On 22 October 2011 05:23, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > tcp_sendmsg() uses select_size() helper to choose skb head size when a
> > new skb must be allocated.
> >
> > If GSO is enabled for the socket, current strategy is to force all
> > payload data to be outside of headroom, in PAGE fragments.
> >
> > This strategy is not welcome for small packets, wasting memory.
> >
> > Experiments show that best results are obtained when using 2048 bytes
> > for skb head (This includes the skb overhead and various headers)
> >
> > This patch provides better len/truesize ratios for packets sent to
> > loopback device, and reduce memory needs for in-flight loopback packets,
> > particularly on arches with big pages.
> >
> > If a sender sends many 1-byte packets to an unresponsive application,
> > receiver rmem_alloc will grow faster and will stop queuing these packets
> > sooner, or will collapse its receive queue to free excess memory.
> >
> > netperf -t TCP_RR results are improved by ~4 %, and many workloads are
> > improved as well (tbench, mysql...)
> >
> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> > ---
> > net/ipv4/tcp.c | 9 ++++++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> > index 704adad..cd45b44 100644
> > --- a/net/ipv4/tcp.c
> > +++ b/net/ipv4/tcp.c
> > @@ -897,9 +897,12 @@ static inline int select_size(const struct sock *sk, int sg)
> > int tmp = tp->mss_cache;
> >
> > if (sg) {
> > - if (sk_can_gso(sk))
> > - tmp = 0;
> > - else {
> > + if (sk_can_gso(sk)) {
> > + /* Small frames wont use a full page:
> > + * Payload will immediately follow tcp header.
> > + */
> > + tmp = SKB_WITH_OVERHEAD(2048 - MAX_TCP_HEADER);
> > + } else {
> > int pgbreak = SKB_MAX_HEAD(MAX_TCP_HEADER);
> >
> > if (tmp >= pgbreak &&
> >
> >
>
>
>
> This patch from Eric fixing select_size in tcp.c was queued to be
> applied but does not seem to be in net-next tree. Was this somehow
> overlooked or have I missed something?
>
Good catch Vijay, thanks for noticing !
David, do you want me to respin this ?
^ permalink raw reply
* Re: [PATCH v4 0/10] bql: Byte Queue Limits
From: Eric Dumazet @ 2011-11-29 7:45 UTC (permalink / raw)
To: John Fastabend
Cc: Dave Taht, Tom Herbert, davem@davemloft.net,
netdev@vger.kernel.org
In-Reply-To: <4ED4885F.8060309@intel.com>
Le lundi 28 novembre 2011 à 23:23 -0800, John Fastabend a écrit :
> I wonder if we should consider enabling TSO/GSO per queue or per traffic
> class on devices that support this. At least in devices that support
> multiple traffic classes it seems to be a common usage case to put bulk
> storage traffic (iSCSI) on a traffic class and low latency traffic on a
> separate traffic class, VoIP for example.
>
It all depends on how device itself is doing its mux from queues to
ethernet wire. If queue 0 starts transmit of one 64KB 'super packet',
will queue 1 be able to insert a litle frame between the frames of queue
0 ?
^ permalink raw reply
* Re: [PATCH] sctp: integer overflow in sctp_auth_create_key()
From: Xi Wang @ 2011-11-29 7:33 UTC (permalink / raw)
To: Vladislav Yasevich
Cc: linux-kernel, Sridhar Samudrala, David S. Miller, linux-sctp,
netdev, security
In-Reply-To: <4ED3AC7D.6090108@hp.com>
I agree that this is not a security issue if key_len can never get large.
So how about just removing the overflow check at all?
- xi
On Nov 28, 2011, at 10:45 AM, Vladislav Yasevich wrote:
>
> Hmm. Yes, this is a more correct check.
>
> Acked-by: Vlad Yasevich <vladislav.yasevich@hp.com>
>
>
> However, I don't think this is a security issue. As I've written before, this function is
> called from 2 places:
>
> 1) setsockopt() code path
>
> 2) sctp_auth_asoc_set_secret() code path
>
> In case (1), sca_keylength is never going to exceed 65535 since it's
> bounded by a u16 from the user api. As such, The integer promotion will
> not impact anything and the malloc() will never overflow.
>
> In case (2), sca_keylength is computed based on the key the user provided
> (MAX_USHORT) and the combination of protocol negotiated data where that
> combination has a max size of 3 * MAX_USHORT (see sctp_auth_make_key_vector()).
> So, even this case, our maximum key length can be 4* MAX_USHORT which still
> will always be below MAX_INT and will not overflow.
>
> So, I don't think there is big security consideration here, just a bad
> check that just happens to always work.
>
> -vlad
^ permalink raw reply
* Re: [PATCH v4 0/10] bql: Byte Queue Limits
From: John Fastabend @ 2011-11-29 7:23 UTC (permalink / raw)
To: Eric Dumazet
Cc: Dave Taht, Tom Herbert, davem@davemloft.net,
netdev@vger.kernel.org
In-Reply-To: <1322550138.2970.70.camel@edumazet-laptop>
On 11/28/2011 11:02 PM, Eric Dumazet wrote:
> Le mardi 29 novembre 2011 à 05:23 +0100, Dave Taht a écrit :
>>> In this test 100 netperf TCP_STREAMs were started to saturate the link.
>>> A single instance of a netperf TCP_RR was run with high priority set.
>>> Queuing discipline in pfifo_fast, NIC is e1000 with TX ring size set to
>>> 1024. tps for the high priority RR is listed.
>>>
>>> No BQL, tso on: 3000-3200K bytes in queue: 36 tps
>>> BQL, tso on: 156-194K bytes in queue, 535 tps
>>
>>> No BQL, tso off: 453-454K bytes int queue, 234 tps
>>> BQL, tso off: 66K bytes in queue, 914 tps
>>
>>
>> Jeeze. Under what circumstances is tso a win? I've always
>> had great trouble with it, as some e1000 cards do it rather badly.
>>
>> I assume these are while running at GigE speeds?
>>
>> What of 100Mbit? 10GigE? (I will duplicate your tests
>> at 100Mbit, but as for 10gigE...)
>>
>
> TSO on means a low priority 65Kbytes packet can be in TX ring right
> before the high priority packet. If you cant afford the delay, you lose.
>
> There is no mystery here.
>
> If you want low latencies :
> - TSO must be disabled so that packets are at most one ethernet frame.
> - You adjust BQL limit to small value
> - You even can lower MTU to get even more better latencies.
>
> If you want good throughput from your [10]GigE and low cpu cost, TSO
> should be enabled.
>
> If you want to be smart, you could have a dynamic behavior :
>
> Let TSO on as long as no high priority low latency producer is running
> (if low latency packets are locally generated)
>
>
I wonder if we should consider enabling TSO/GSO per queue or per traffic
class on devices that support this. At least in devices that support
multiple traffic classes it seems to be a common usage case to put bulk
storage traffic (iSCSI) on a traffic class and low latency traffic on a
separate traffic class, VoIP for example.
John.
^ permalink raw reply
* Re: [PATCH v4 0/10] bql: Byte Queue Limits
From: Eric Dumazet @ 2011-11-29 7:07 UTC (permalink / raw)
To: Dave Taht; +Cc: Tom Herbert, davem, netdev
In-Reply-To: <1322550138.2970.70.camel@edumazet-laptop>
Le mardi 29 novembre 2011 à 08:02 +0100, Eric Dumazet a écrit :
> TSO on means a low priority 65Kbytes packet can be in TX ring right
> before the high priority packet. If you cant afford the delay, you lose.
>
By the way, I hope TSO is off for wifi adapters.
At least here its off..
# ethtool -k wlan0
Offload parameters for wlan0:
rx-checksumming: off
tx-checksumming: off
scatter-gather: off
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: off
tx-vlan-offload: off
ntuple-filters: off
receive-hashing: off
0c:00.0 Network controller: Broadcom Corporation BCM4311 802.11a/b/g (rev 01)
^ permalink raw reply
* Re: [PATCH v4 0/10] bql: Byte Queue Limits
From: Eric Dumazet @ 2011-11-29 7:02 UTC (permalink / raw)
To: Dave Taht; +Cc: Tom Herbert, davem, netdev
In-Reply-To: <CAA93jw7P=7YMOS_sMQWBJx0UJ6e+xw4e_hw8szNiVTOjGNwukw@mail.gmail.com>
Le mardi 29 novembre 2011 à 05:23 +0100, Dave Taht a écrit :
> > In this test 100 netperf TCP_STREAMs were started to saturate the link.
> > A single instance of a netperf TCP_RR was run with high priority set.
> > Queuing discipline in pfifo_fast, NIC is e1000 with TX ring size set to
> > 1024. tps for the high priority RR is listed.
> >
> > No BQL, tso on: 3000-3200K bytes in queue: 36 tps
> > BQL, tso on: 156-194K bytes in queue, 535 tps
>
> > No BQL, tso off: 453-454K bytes int queue, 234 tps
> > BQL, tso off: 66K bytes in queue, 914 tps
>
>
> Jeeze. Under what circumstances is tso a win? I've always
> had great trouble with it, as some e1000 cards do it rather badly.
>
> I assume these are while running at GigE speeds?
>
> What of 100Mbit? 10GigE? (I will duplicate your tests
> at 100Mbit, but as for 10gigE...)
>
TSO on means a low priority 65Kbytes packet can be in TX ring right
before the high priority packet. If you cant afford the delay, you lose.
There is no mystery here.
If you want low latencies :
- TSO must be disabled so that packets are at most one ethernet frame.
- You adjust BQL limit to small value
- You even can lower MTU to get even more better latencies.
If you want good throughput from your [10]GigE and low cpu cost, TSO
should be enabled.
If you want to be smart, you could have a dynamic behavior :
Let TSO on as long as no high priority low latency producer is running
(if low latency packets are locally generated)
^ permalink raw reply
* RE: [bug?] r8169: hangs under heavy load
From: hayeswang @ 2011-11-29 6:47 UTC (permalink / raw)
To: 'Francois Romieu', booster
Cc: 'Jonathan Nieder', 'Eric Dumazet', netdev,
'nic_swsd', linux-kernel, 'Armin Kazmi'
In-Reply-To: <20111127231147.GA1784@electric-eye.fr.zoreil.com>
Francois Romieu [mailto:romieu@fr.zoreil.com]
[...]
>
> Hayes, does the 8168c require something special to recover
> from Rx FIFO
> overflow ?
>
For the 8168c and the later chips, our hardware engineer says that don't enable
the RxFIFOOver of IntrMask and don't clear the RxFIFOOver of IntrStatus. The
hardware will automatically escape Rx fifo full situation. Although you try to
clear the RxFIFOOver of IntrStatus, maybe the bit wouldn't be cleared. Just
disregard it.
Best Regards,
Hayes
^ permalink raw reply
* Re: [patch] batman-adv: remove extra negation in gw_out_of_range()
From: Marek Lindner @ 2011-11-29 6:41 UTC (permalink / raw)
To: b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Simon Wunderlich,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA, David S. Miller,
Dan Carpenter
In-Reply-To: <20111129060909.GA6098-mgFCXtclrQlZLf2FXnZxJA@public.gmane.org>
On Tuesday, November 29, 2011 14:09:09 Dan Carpenter wrote:
> There is a typo here where an extra '!' made the check to the opposite
> of what was intended.
>
> Signed-off-by: Dan Carpenter <dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
>
> diff --git a/net/batman-adv/gateway_client.c
> b/net/batman-adv/gateway_client.c index 9373a14..24403a7 100644
> --- a/net/batman-adv/gateway_client.c
> +++ b/net/batman-adv/gateway_client.c
> @@ -695,7 +695,7 @@ bool gw_out_of_range(struct bat_priv *bat_priv,
> }
>
> neigh_old = find_router(bat_priv, orig_dst_node, NULL);
> - if (!!neigh_old)
> + if (!neigh_old)
> goto out;
>
> if (curr_tq_avg - neigh_old->tq_avg > GW_THRESHOLD)
Wow - you are right! Applied in our tree.
Thanks,
Marek
^ permalink raw reply
* Re: [RFC] sky2: add bql support
From: Eric Dumazet @ 2011-11-29 6:38 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Tom Herbert, netdev
In-Reply-To: <20111128201907.6d31d4c3@nehalam.linuxnetplumber.net>
Le lundi 28 novembre 2011 à 20:19 -0800, Stephen Hemminger a écrit :
> Just for testing, here is how to add BQL support to sky2
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> @@ -2022,6 +2024,8 @@ static void sky2_tx_complete(struct sky2
> sky2->tx_stats.bytes += skb->len;
> u64_stats_update_end(&sky2->tx_stats.syncp);
>
> + netdev_completed_queue(dev, 1, skb->len);
> +
> re->skb = NULL;
> dev_kfree_skb_any(skb);
>
I believe you should batch these calls as much as possible.
This would also reduce the burden on
u64_stats_update_begin/u64_stats_update_end
diff --git a/drivers/net/ethernet/marvell/sky2.c b/drivers/net/ethernet/marvell/sky2.c
index 29adc78..1277c95 100644
--- a/drivers/net/ethernet/marvell/sky2.c
+++ b/drivers/net/ethernet/marvell/sky2.c
@@ -2003,6 +2003,7 @@ static void sky2_tx_complete(struct sky2_port *sky2, u16 done)
{
struct net_device *dev = sky2->netdev;
unsigned idx;
+ unsigned long pkts = 0, bytes = 0;
BUG_ON(done >= sky2->tx_ring_size);
@@ -2017,10 +2018,8 @@ static void sky2_tx_complete(struct sky2_port *sky2, u16 done)
netif_printk(sky2, tx_done, KERN_DEBUG, dev,
"tx done %u\n", idx);
- u64_stats_update_begin(&sky2->tx_stats.syncp);
- ++sky2->tx_stats.packets;
- sky2->tx_stats.bytes += skb->len;
- u64_stats_update_end(&sky2->tx_stats.syncp);
+ pkts++;
+ bytes += skb->len;
re->skb = NULL;
dev_kfree_skb_any(skb);
@@ -2031,6 +2030,11 @@ static void sky2_tx_complete(struct sky2_port *sky2, u16 done)
sky2->tx_cons = idx;
smp_mb();
+ u64_stats_update_begin(&sky2->tx_stats.syncp);
+ sky2->tx_stats.packets += pkts;
+ sky2->tx_stats.bytes += bytes;
+ u64_stats_update_end(&sky2->tx_stats.syncp);
+ netdev_completed_queue(dev, pkts, bytes);
}
static void sky2_tx_reset(struct sky2_hw *hw, unsigned port)
^ permalink raw reply related
* [PATCH net-next] flow_dissector: use a 64bit load/store
From: Eric Dumazet @ 2011-11-29 6:30 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20111128.190604.1713178066845491526.davem@davemloft.net>
Le lundi 28 novembre 2011 à 19:06 -0500, David Miller a écrit :
> From: Dimitris Michailidis <dm@chelsio.com>
> Date: Mon, 28 Nov 2011 08:25:39 -0800
>
> >> +bool skb_flow_dissect(const struct sk_buff *skb, struct flow_keys
> >> *flow)
> >> +{
> >> + int poff, nhoff = skb_network_offset(skb);
> >> + u8 ip_proto;
> >> + u16 proto = skb->protocol;
> >
> > __be16 instead of u16 for proto?
>
> I'll take care of this when I apply these patches.
( CC trimmed )
Thanks David !
Here is a small patch to use one 64bit load/store on x86_64 instead of
two 32bit load/stores.
[PATCH net-next] flow_dissector: use a 64bit load/store
gcc compiler is smart enough to use a single load/store if we
memcpy(dptr, sptr, 8) on x86_64, regardless of
CONFIG_CC_OPTIMIZE_FOR_SIZE
In IP header, daddr immediately follows saddr, this wont change in the
future. We only need to make sure our flow_keys (src,dst) fields wont
break the rule.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/net/flow_keys.h | 1 +
net/core/flow_dissector.c | 13 +++++++++++--
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/include/net/flow_keys.h b/include/net/flow_keys.h
index e4cb285..80461c1 100644
--- a/include/net/flow_keys.h
+++ b/include/net/flow_keys.h
@@ -2,6 +2,7 @@
#define _NET_FLOW_KEYS_H
struct flow_keys {
+ /* (src,dst) must be grouped, in the same way than in IP header */
__be32 src;
__be32 dst;
union {
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index f0516d9..87bb35c 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -8,6 +8,16 @@
#include <linux/ppp_defs.h>
#include <net/flow_keys.h>
+/* copy saddr & daddr, possibly using 64bit load/store
+ * Equivalent to : flow->src = iph->saddr;
+ * flow->dst = iph->daddr;
+ */
+static void iph_to_flow_copy_addrs(struct flow_keys *flow, const struct iphdr *iph)
+{
+ BUILD_BUG_ON(offsetof(typeof(*flow), dst) !=
+ offsetof(typeof(*flow), src) + sizeof(flow->src));
+ memcpy(&flow->src, &iph->saddr, sizeof(flow->src) + sizeof(flow->dst));
+}
bool skb_flow_dissect(const struct sk_buff *skb, struct flow_keys *flow)
{
@@ -31,8 +41,7 @@ ip:
ip_proto = 0;
else
ip_proto = iph->protocol;
- flow->src = iph->saddr;
- flow->dst = iph->daddr;
+ iph_to_flow_copy_addrs(flow, iph);
nhoff += iph->ihl * 4;
break;
}
^ permalink raw reply related
* Re: Subject: [PATCH 1/2] atm: br2684: Make headroom and hard_header_len depend on the payload type
From: David Miller @ 2011-11-29 6:21 UTC (permalink / raw)
To: chas; +Cc: netdev, linux-atm-general
In-Reply-To: <201111281840.pASIeFhI011675@cmf.nrl.navy.mil>
From: "chas williams - CONTRACTOR" <chas@cmf.nrl.navy.mil>
Date: Mon, 28 Nov 2011 13:40:15 -0500
>
> From: Pascal Hambourg <pascal@plouf.fr.eu.org>
> Date: Wed, 17 Aug 2011 08:37:18 +0200
> Subject: [PATCH 1/2] atm: br2684: Make headroom and hard_header_len depend on the payload type
>
> Routed payload requires less headroom than bridged payload.
> So do not reallocate headroom if not needed.
> Also, add worst case AAL5 overhead to netdev->hard_header_len.
>
> Signed-off-by: Pascal Hambourg <pascal@plouf.fr.eu.org>
> Signed-off-by: chas williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Applied.
^ permalink raw reply
* Re: Subject: [PATCH 2/2] atm: br2684: Avoid alignment issues
From: David Miller @ 2011-11-29 6:21 UTC (permalink / raw)
To: chas; +Cc: netdev, linux-atm-general
In-Reply-To: <201111281840.pASIehr6011893@cmf.nrl.navy.mil>
From: "chas williams - CONTRACTOR" <chas@cmf.nrl.navy.mil>
Date: Mon, 28 Nov 2011 13:40:43 -0500
>
> From: Pascal Hambourg <pascal@plouf.fr.eu.org>
> Date: Wed, 17 Aug 2011 08:37:52 +0200
> Subject: [PATCH 2/2] atm: br2684: Avoid alignment issues
>
> Use memcmp() instead of cast to u16 when checking the PAD field.
>
> Signed-off-by: Pascal Hambourg <pascal@plouf.fr.eu.org>
> Signed-off-by: chas williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: optimize socket timestamping
From: David Miller @ 2011-11-29 6:22 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1322517858.2970.31.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 28 Nov 2011 23:04:18 +0100
> We can test/set multiple bits from sk_flags at once, to shorten a bit
> socket setup/dismantle phase.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/1] netstamp_needed shouldn't be jump_label_key
From: David Miller @ 2011-11-29 6:22 UTC (permalink / raw)
To: eric.dumazet; +Cc: igorm, netdev
In-Reply-To: <1322515010.2970.24.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 28 Nov 2011 22:16:50 +0100
> [PATCH net-next] net: dont call jump_label_dec from irq context
>
> Igor Maravic reported an error caused by jump_label_dec() being called
> from IRQ context :
...
> Since jump_label_{inc|dec} must be called from process context only,
> we must defer jump_label_dec() if net_disable_timestamp() is called
> from interrupt context.
>
> Reported-by: Igor Maravic <igorm@etf.rs>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] corral some wayward N/A fw_version dust bunnies
From: David Miller @ 2011-11-29 6:18 UTC (permalink / raw)
To: raj; +Cc: netdev, romieu, jdmason
In-Reply-To: <20111123000626.43E58290084C@tardy>
From: raj@tardy.cup.hp.com (Rick Jones)
Date: Tue, 22 Nov 2011 16:06:26 -0800 (PST)
> From: Rick Jones <rick.jones2@hp.com>
>
> Round-up some wayward "N/A" fw_version dust bunnies as part of that
> clean-up.
>
> Signed-off-by: Rick Jones <rick.jones2@hp.com>
Applied.
^ permalink raw reply
* Re: [net-next v2 0/9] bnx2x: Link changes
From: David Miller @ 2011-11-29 6:21 UTC (permalink / raw)
To: yanivr; +Cc: netdev
In-Reply-To: <1322477393-22904-1-git-send-email-yanivr@broadcom.com>
From: "Yaniv Rosner" <yanivr@broadcom.com>
Date: Mon, 28 Nov 2011 12:49:44 +0200
> The following patch series describe some link changes.
> Please consider applying it to net-next.
Series applied.
^ permalink raw reply
* Re: [PATCH] net/can: convert drivers/net/can/* to use module_platform_driver()
From: David Miller @ 2011-11-29 6:17 UTC (permalink / raw)
To: mkl
Cc: axel.lin, linux-kernel, wg, bhupesh.sharma, jkosina, grant.likely,
agust, pebolle, kurt.van.dijck, adobriyan, linux-can, netdev
In-Reply-To: <4ED35FC4.3040007@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Mon, 28 Nov 2011 11:17:40 +0100
> On 11/28/2011 02:42 AM, Axel Lin wrote:
>> This patch converts the drivers in drivers/net/can/* to use the
>> module_platform_driver() macro which makes the code smaller and a bit
>> simpler.
>>
>> Cc: Wolfgang Grandegger <wg@grandegger.com>
>> Cc: "David S. Miller" <davem@davemloft.net>
>> Cc: Bhupesh Sharma <bhupesh.sharma@st.com>
>> Cc: Jiri Kosina <jkosina@suse.cz>
>> Cc: Grant Likely <grant.likely@secretlab.ca>
>> Cc: Anatolij Gustschin <agust@denx.de>
>> Cc: Paul Bolle <pebolle@tiscali.nl>
>> Cc: Kurt Van Dijck <kurt.van.dijck@eia.be>
>> Cc: Alexey Dobriyan <adobriyan@gmail.com>
>> Signed-off-by: Axel Lin <axel.lin@gmail.com>
>
> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 3/3] dsa: Move switch drivers to new directory drivers/net/dsa
From: David Miller @ 2011-11-29 6:20 UTC (permalink / raw)
To: ben; +Cc: buytenh, netdev
In-Reply-To: <1322449713.7454.36.camel@deadeye>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Mon, 28 Nov 2011 03:08:33 +0000
> Support for specific hardware belongs under drivers/net/ not net/.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/3] dsa: Move all definitions needed by drivers into <net/dsa.h>
From: David Miller @ 2011-11-29 6:20 UTC (permalink / raw)
To: ben; +Cc: buytenh, netdev
In-Reply-To: <1322449568.7454.35.camel@deadeye>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Mon, 28 Nov 2011 03:06:08 +0000
> Any headers included by drivers should be under include/, and
> any definitions they use are not really private to the core as
> the name "dsa_priv.h" suggests.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Applied.
^ permalink raw reply
* Re: [PATCH 1/3] dsa: Remove unnecessary exports
From: David Miller @ 2011-11-29 6:20 UTC (permalink / raw)
To: ben; +Cc: buytenh, netdev
In-Reply-To: <1322449506.7454.34.camel@deadeye>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Mon, 28 Nov 2011 03:05:06 +0000
> I mistakenly exported functions from slave.c that are only called from
> dsa.c, part of the same module.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Applied.
^ 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