* [PATCH 1/1 net-next] tcp: add __init to tcp_init_mem
From: Fabian Frederick @ 2014-10-01 16:27 UTC (permalink / raw)
To: linux-kernel
Cc: Fabian Frederick, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev
tcp_init_mem is only called by __init tcp_init.
Signed-off-by: Fabian Frederick <fabf@skynet.be>
---
net/ipv4/tcp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index cf5e508..5c17034 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -3172,7 +3172,7 @@ static int __init set_thash_entries(char *str)
}
__setup("thash_entries=", set_thash_entries);
-static void tcp_init_mem(void)
+static void __init tcp_init_mem(void)
{
unsigned long limit = nr_free_buffer_pages() / 8;
limit = max(limit, 128UL);
--
1.9.3
^ permalink raw reply related
* Re: [PATCH net-next] udp: increment UDP_NO_PORTS when dropping unmatched multicasts
From: Rick Jones @ 2014-10-01 16:32 UTC (permalink / raw)
To: David L Stevens, netdev; +Cc: davem
In-Reply-To: <542C23AA.6060505@oracle.com>
On 10/01/2014 08:54 AM, David L Stevens wrote:
> I think this would have the unpleasant side-effect of incrementing a drop
> stat when we have not joined a multicast group that has UDP traffic, but the
> interface is in promiscuous mode. Also, false positives for the multicast
> address filter.
>
> Multicast address filters are not perfect matches, so it is "normal" to receive
> multicasts and broadcasts that are not addressed to our host. I'm not sure those
> should count as "noports" any more than traffic addressed to someone else's IP
> address if we're in promiscuous mode should.
>
> In the multicast case, it would really only make sense if we have actually joined
> the group it's addressed to.
Do you think an "ignored" statistic would be appropriate then?
rick
^ permalink raw reply
* Re: [PATCH net-next 2/2] net/mlx4_core: Disable BF when write combining is not available
From: Alexei Starovoitov @ 2014-10-01 16:52 UTC (permalink / raw)
To: Or Gerlitz
Cc: David S. Miller, netdev@vger.kernel.org, Amir Vadai,
Jack Morgenstein, Moshe Lazer, Tal Alon, Yevgeny Petrilin
In-Reply-To: <1412175282-25212-3-git-send-email-ogerlitz@mellanox.com>
On Wed, Oct 1, 2014 at 7:54 AM, Or Gerlitz <ogerlitz@mellanox.com> wrote:
> From: Moshe Lazer <moshel@mellanox.com>
>
> In mlx4 for better latency, we write send descriptors to a write-combining
> (WC) mapped buffer instead of ringing a doorbell and having the HW fetch
> the descriptor from system memory.
>
> However, if write-combining is not supported on the host, then we
> obtain better latency by using the doorbell-ring/HW fetch mechanism.
>
> The mechanism that uses WC is called Blue-Flame (BF). BF is beneficial
> only when the system supports write combining. When the BF buffer is
> mapped as a write-combine buffer, the HCA receives data in multi-word
> bursts. However, if the BF buffer is mapped only as non-cached, the
> HCA receives data in individual dword chunks, which harms performance.
>
> Therefore, disable blueflame when write combining is not available.
curious, what numbers you're seeing:
- bf=on with wc
- bf=on without wc
- bf=off and doorbell
they will help to justify this change.
^ permalink raw reply
* Re: [PATCH net-next] udp: increment UDP_NO_PORTS when dropping unmatched multicasts
From: David L Stevens @ 2014-10-01 16:59 UTC (permalink / raw)
To: Rick Jones, netdev; +Cc: davem
In-Reply-To: <542C2CAB.2030501@hp.com>
On 10/01/2014 12:32 PM, Rick Jones wrote:
>
> Do you think an "ignored" statistic would be appropriate then?
I guess I don't know what that means. If we didn't join the group, it
should be treated like anything we'd receive in promiscuous mode that
is not addressed to us. I'd assume interface stats are going up, but not
any protocol stats in that case. (already the case)
If we did join the group, it should be treated the way we would, say,
a broadcast UDP packet where we have no listener on that port.
It isn't clear to me that maintaining the stat is worth checking for
group membership, but we wouldn't want an admin to conclude there is
a problem or an error because we increment a stat when doing the
equivalent of hardware MAC address filtering, just because multicast
address filters are defined to be leaky.
+-DLS
^ permalink raw reply
* Re: [PATCH V1 net-next 2/4] net/mlx5_core: Use hardware registers description header file
From: Alexei Starovoitov @ 2014-10-01 17:12 UTC (permalink / raw)
To: Eli Cohen
Cc: David S. Miller, netdev@vger.kernel.org, Or Gerlitz,
Yevgeny Petrilin, Joe Perches
In-Reply-To: <1412169488-17500-3-git-send-email-eli@mellanox.com>
On Wed, Oct 1, 2014 at 6:18 AM, Eli Cohen <eli@mellanox.com> wrote:
>
> Change-Id: Ieea94e4b329ec46902b1634cf66b0c3a04445a04
checkpatch errors on gerrit tags by default,
but I'm not sure what's an official stance on it, since I see patches
with this tag slip through here and there.
> +static inline void non_existent_function(void)
> +{
> + pr_info("%s\n", __func__);
> +}
> +
> +static inline void non_existent_function_sz_align32(void)
> +{
> + pr_info("%s\n", __func__);
> +}
> +
> +static inline void non_existent_function_const_overflow(void)
> +{
> + pr_info("%s\n", __func__);
> +}
> +
> +static inline void memcpy_cpu_to_be32(void *dst, void *src, int len)
> +{
> + u32 *dst_u32 = (u32 *)dst;
> + int i;
> +
> + memcpy(dst, src, len);
> +
> + for (i = 0; i < (len >> 2); i++)
> + dst_u32[i] = cpu_to_be32(dst_u32[i]);
it just assumes that pointers are aligned and len is power of 4 ?
> +}
> +
> +/* insert a value to a struct */
> +#define MLX5_SET(typ, p, fld, v) do { \
> + if (__mlx5_st_sz_bits(typ) % 32) \
> + non_existent_function_sz_align32(); \
> + *((__be32 *)(p) + __mlx5_dw_off(typ, fld)) = \
> + cpu_to_be32((be32_to_cpu(*((__be32 *)(p) + __mlx5_dw_off(typ, fld))) & \
> + (~__mlx5_dw_mask(typ, fld))) | (((v) & __mlx5_mask(typ, fld)) \
> + << __mlx5_dw_bit_off(typ, fld))); \
> +} while (0)
> +
> +#define MLX5_GET(typ, p, fld) ((be32_to_cpu(*((__be32 *)(p) +\
> +__mlx5_dw_off(typ, fld))) >> __mlx5_dw_bit_off(typ, fld)) & \
> +__mlx5_mask(typ, fld))
> +
> +#define MLX5_GET_PR(typ, p, fld) ({ \
> + u32 ___t = MLX5_GET(typ, p, fld); \
> + pr_debug(#fld " = 0x%x\n", ___t); \
> + ___t; \
> +})
> +
> +#define MLX5_SET64(typ, p, fld, v) do { \
> + if (__mlx5_bit_sz(typ, fld) != 64) \
> + non_existent_function(); \
> + else if (__mlx5_bit_off(typ, fld) % 64) \
> + non_existent_function(); \
> + else \
> + *((__be64 *)(p) + __mlx5_64_off(typ, fld)) = cpu_to_be64(v); \
> +} while (0)
is it possible to use BUILD_BUG_ON instead of runtime pr_info() ?
^ permalink raw reply
* Re: [PATCH net-next] udp: increment UDP_NO_PORTS when dropping unmatched multicasts
From: Sergei Shtylyov @ 2014-10-01 17:14 UTC (permalink / raw)
To: Rick Jones, netdev; +Cc: davem
In-Reply-To: <20141001151921.7131E29003A2@tardy>
Hello.
On 10/01/2014 07:19 PM, Rick Jones wrote:
> From: Rick Jones <rick.jones2@hp.com>
> When there is absolutely no match for an incoming UDP multicast we
> should increment a suitable UDP statistic in addition to the kfree_skb().
> When there were some matches, we should not and simply call consume_skb().
> Signed-off-by: Rick Jones <rick.jones2@hp.com>
> ---
> Noticed __udp4_lib_mcast_deliver showing-up in a perf dropped packet
> profile on a system sitting on a network with a bunch of Windows boxes
> sending what they are fond of sending.
> Verified that UDP_MIB_NOPORTS increments when it was not before and hit
> the system with a bit of netperf multicast UDP_RR but that is the extent
> of the testing performed.
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index cd0db54..376e3d3 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -1656,6 +1656,7 @@ static int __udp4_lib_mcast_deliver(struct net *net, struct sk_buff *skb,
> int dif = skb->dev->ifindex;
> unsigned int count = 0, offset = offsetof(typeof(*sk), sk_nulls_node);
> unsigned int hash2 = 0, hash2_any = 0, use_hash2 = (hslot->count > 10);
> + unsigned int inner_flushed = 0;
>
> if (use_hash2) {
> hash2_any = udp4_portaddr_hash(net, htonl(INADDR_ANY), hnum) &
> @@ -1694,8 +1695,12 @@ start_lookup:
> */
> if (count) {
> flush_stack(stack, count, skb, count - 1);
> - } else {
> + } else if (!inner_flushed) {
I don't see where this new variable is changed. It's always 0 here.
> + UDP_INC_STATS_BH(net, UDP_MIB_NOPORTS, 0);
> kfree_skb(skb);
> + } else {
> + /* there were matches flushed in the for_each */
> + consume_skb(skb);
> }
> return 0;
> }
WBR, Sergei
^ permalink raw reply
* Re: [PATCH v2 net-next 01/10] r8169:change uppercase number to lowercase nubmer
From: Sergei Shtylyov @ 2014-10-01 17:17 UTC (permalink / raw)
To: Chun-Hao Lin, netdev; +Cc: nic_swsd, linux-kernel
In-Reply-To: <1412176641-24393-1-git-send-email-hau@realtek.com>
Hello.
On 10/01/2014 07:17 PM, Chun-Hao Lin wrote:
> Signed-off-by: Chun-Hao Lin <hau@realtek.com>
How about correcting typo in the subject: s/nubmer/number/?
WBR, Sergei
^ permalink raw reply
* [PATCH 1/1 net-next] inet: frags: add __init to ip4_frags_ctl_register
From: Fabian Frederick @ 2014-10-01 17:18 UTC (permalink / raw)
To: linux-kernel
Cc: Fabian Frederick, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev
ip4_frags_ctl_register is only called by __init ipfrag_init
Signed-off-by: Fabian Frederick <fabf@skynet.be>
---
net/ipv4/ip_fragment.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
index 15f0e2b..2811cc1 100644
--- a/net/ipv4/ip_fragment.c
+++ b/net/ipv4/ip_fragment.c
@@ -790,7 +790,7 @@ static void __net_exit ip4_frags_ns_ctl_unregister(struct net *net)
kfree(table);
}
-static void ip4_frags_ctl_register(void)
+static void __init ip4_frags_ctl_register(void)
{
register_net_sysctl(&init_net, "net/ipv4", ip4_frags_ctl_table);
}
@@ -804,7 +804,7 @@ static inline void ip4_frags_ns_ctl_unregister(struct net *net)
{
}
-static inline void ip4_frags_ctl_register(void)
+static inline void __init ip4_frags_ctl_register(void)
{
}
#endif
--
1.9.3
^ permalink raw reply related
* Re: [PATCH V1 net-next 2/4] net/mlx5_core: Use hardware registers description header file
From: Sergei Shtylyov @ 2014-10-01 17:21 UTC (permalink / raw)
To: Alexei Starovoitov, Eli Cohen
Cc: David S. Miller, netdev@vger.kernel.org, Or Gerlitz,
Yevgeny Petrilin, Joe Perches
In-Reply-To: <CAADnVQ+0q=j9soWX-ge6Re4F6sDahq=O-Ptaguca8WUaTE-qQw@mail.gmail.com>
Hello.
On 10/01/2014 09:12 PM, Alexei Starovoitov wrote:
>> Change-Id: Ieea94e4b329ec46902b1634cf66b0c3a04445a04
> checkpatch errors on gerrit tags by default,
> but I'm not sure what's an official stance on it, since I see patches
> with this tag slip through here and there.
It's allowed by DaveM.
WBR, Sergei
^ permalink raw reply
* Re: Why include/net/tcp_states.h is not exported to user-space?
From: Arnaldo Carvalho de Melo @ 2014-10-01 17:25 UTC (permalink / raw)
To: Cong Wang; +Cc: David Miller, netdev
In-Reply-To: <CAHA+R7MDGKA1Z-1ytk8-+9XaKNcW+kG7UBn8drhdbLJeQYBCyQ@mail.gmail.com>
Em Tue, Sep 30, 2014 at 11:12:04AM -0700, Cong Wang escreveu:
> These states are needed for user-space to specify ->idiag_states.
> Currently both libnl and ss make their own copy of these definitions.
> Of course, new sock diag is not just limited to TCP, so we probably
> need to rename them to SS_* before exporting them.
>
> I can send a patch if you agree.
One would have to check what are the current best practices for doing
that, i.e. probably this would have to go via
include/uapi//linux/tcp_states.h? Or take the time and create a new
header for the inet_diag.h stuff as this is not TCP specific for quite a
while?
If you could investigate how to properly expose this and then come back
with a patch proposal I think that would ease reviewing :-)
- Arnaldo
^ permalink raw reply
* [PATCH v2] ssb: Fix Sparse error in main
From: Pramod Gurav @ 2014-10-01 17:28 UTC (permalink / raw)
To: linux-kernel; +Cc: Pramod Gurav, Michael Buesch, netdev
This change fixes below sparse error:
drivers/ssb/main.c:94:16: warning: symbol 'ssb_sdio_func_to_bus'
was not declared. Should it be static?
Cc: Michael Buesch <m@bues.ch>
Cc: netdev@vger.kernel.org
Signed-off-by: Pramod Gurav <pramod.gurav@smartplayin.com>
---
Changes since v1:
Removed the function as it is not called anywhere in the kernel
as per suggestion from Michael Buesch.
drivers/ssb/main.c | 19 -------------------
1 file changed, 19 deletions(-)
diff --git a/drivers/ssb/main.c b/drivers/ssb/main.c
index 2fead38..1e180c4 100644
--- a/drivers/ssb/main.c
+++ b/drivers/ssb/main.c
@@ -90,25 +90,6 @@ found:
}
#endif /* CONFIG_SSB_PCMCIAHOST */
-#ifdef CONFIG_SSB_SDIOHOST
-struct ssb_bus *ssb_sdio_func_to_bus(struct sdio_func *func)
-{
- struct ssb_bus *bus;
-
- ssb_buses_lock();
- list_for_each_entry(bus, &buses, list) {
- if (bus->bustype == SSB_BUSTYPE_SDIO &&
- bus->host_sdio == func)
- goto found;
- }
- bus = NULL;
-found:
- ssb_buses_unlock();
-
- return bus;
-}
-#endif /* CONFIG_SSB_SDIOHOST */
-
int ssb_for_each_bus_call(unsigned long data,
int (*func)(struct ssb_bus *bus, unsigned long data))
{
--
1.8.3.2
^ permalink raw reply related
* Re: [net-next PATCH V5] qdisc: bulk dequeue support for qdiscs with TCQ_F_ONETXQUEUE
From: Jesper Dangaard Brouer @ 2014-10-01 17:28 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Tom Herbert, David Miller, Linux Netdev List, Eric Dumazet,
Hannes Frederic Sowa, Florian Westphal, Daniel Borkmann,
Alexander Duyck, John Fastabend, Dave Taht,
Toke Høiland-Jørgensen, brouer
In-Reply-To: <542C1F1F.90404@mojatatu.com>
On Wed, 01 Oct 2014 11:34:55 -0400 Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> The issue is: if i am going to attempt to do a bulk transfer
> every single time (with new code) and for the common use case the
> result is "no need to do bulking" then you just added extra code that
> is unnecessary for that common case.
> Even a single extra if statement at high packet rate is still
> costly and would be easy to observe.
[...]
>
> That is if the added code ends up being hit
> meaningfully. Jesper said (and it was my experience as well)
> that it was _hard_ to achieve bulking in such a case.
Let me close this one...
The bulk dequeue code *is* being hit meaningfully. It is _only_ going
to be activated when (q->qlen > 0) see __dev_xmit_skb() in dev.c.
When there is no queue pfifo_fast is allowed to directly call
sch_direct_xmit() without a enqueue/dequeue cycle. Thus, this code
would not be hit for every packet.
Thus, code is activated only when q->qlen is >= 1. And I have already
shown that we see a win with just bulking 2 packets:
"Subject: qdisc/UDP_STREAM: measuring effect of qdisc bulk dequeue"
http://thread.gmane.org/gmane.linux.network/331152/focus=331154
I actually believe, that I have already measured and shown that going
though the bulk dequeue is a win, this should show direct_xmit vs.
bulking:
"Subject: qdisc/trafgen: Measuring effect of qdisc bulk dequeue, with trafgen"
http://thread.gmane.org/gmane.linux.network/331152
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* [PATCH 1/1 net-next] cipso: add __init to cipso_v4_cache_init
From: Fabian Frederick @ 2014-10-01 17:30 UTC (permalink / raw)
To: linux-kernel
Cc: Fabian Frederick, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev
cipso_v4_cache_init is only called by __init cipso_v4_init
Signed-off-by: Fabian Frederick <fabf@skynet.be>
---
net/ipv4/cipso_ipv4.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/cipso_ipv4.c b/net/ipv4/cipso_ipv4.c
index 05b708b..4715f25 100644
--- a/net/ipv4/cipso_ipv4.c
+++ b/net/ipv4/cipso_ipv4.c
@@ -246,7 +246,7 @@ static u32 cipso_v4_map_cache_hash(const unsigned char *key, u32 key_len)
* success, negative values on error.
*
*/
-static int cipso_v4_cache_init(void)
+static int __init cipso_v4_cache_init(void)
{
u32 iter;
--
1.9.3
^ permalink raw reply related
* Re: [PATCH net-next] udp: increment UDP_NO_PORTS when dropping unmatched multicasts
From: Rick Jones @ 2014-10-01 17:32 UTC (permalink / raw)
To: David L Stevens, netdev; +Cc: davem
In-Reply-To: <542C32E6.7080106@oracle.com>
On 10/01/2014 09:59 AM, David L Stevens wrote:
> On 10/01/2014 12:32 PM, Rick Jones wrote:
>
>>
>> Do you think an "ignored" statistic would be appropriate then?
>
> I guess I don't know what that means.
It would be an added statistic for "ignored" UDP multicast datagrams,
incremented instead of UDP_MIB_NOPORTS. "UDP_MIB_IGNOREDMULTI" if you
will.
Similar in concept to what HP-UX NIC drivers would increment when they
received a frame for which there was no bound protocol - "inbound
unknown protocols" but not a drop
http://ptgmedia.pearsoncmg.com/images/chap1_0130428167/elementLinks/01fig16.gif
rick
^ permalink raw reply
* Re: linux-next: build failure after merge of the net-next tree
From: David Miller @ 2014-10-01 17:42 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, alexander.h.duyck,
jeffrey.t.kirsher
In-Reply-To: <20141001170403.7a319458@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 1 Oct 2014 17:04:03 +1000
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 1 Oct 2014 17:00:49 +1000
> Subject: [PATCH] fm10k: using vmalloc requires including linux/vmalloc.h
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Applied, thanks Stephen.
^ permalink raw reply
* Re: [PATCH net-next] udp: increment UDP_NO_PORTS when dropping unmatched multicasts
From: David L Stevens @ 2014-10-01 17:43 UTC (permalink / raw)
To: Rick Jones, netdev; +Cc: davem
In-Reply-To: <542C3A95.8050804@hp.com>
On 10/01/2014 01:32 PM, Rick Jones wrote:
> It would be an added statistic for "ignored" UDP multicast datagrams, incremented instead of UDP_MIB_NOPORTS. "UDP_MIB_IGNOREDMULTI" if you will.
>
> Similar in concept to what HP-UX NIC drivers would increment when they received a frame for which there was no bound protocol - "inbound unknown protocols" but not a drop
> http://ptgmedia.pearsoncmg.com/images/chap1_0130428167/elementLinks/01fig16.gif
I guess I'm ok with that.
Ideally, it wouldn't be affected by running a sniffer, so I think best would be to increment
NOPORTS when someone has joined the group on the interface and IGNOREDMULTI when nobody has,
but I'm not sure it's worth the trouble to check. So I'm good with that, or IGNOREDMULTI all
the time.
+-DLS
^ permalink raw reply
* Re: [PATCH net-next] ipv4: mentions skb_gro_postpull_rcsum() in inet_gro_receive()
From: David Miller @ 2014-10-01 17:44 UTC (permalink / raw)
To: eric.dumazet; +Cc: Yuval.Mintz, therbert, netdev
In-Reply-To: <1412140325.16704.31.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 30 Sep 2014 22:12:05 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> Proper CHECKSUM_COMPLETE support needs to adjust skb->csum
> when we remove one header. Its done using skb_gro_postpull_rcsum()
>
> In the case of IPv4, we know that the adjustment is not really needed,
> because the checksum over IPv4 header is 0. Lets add a comment to
> ease code comprehension and avoid copy/paste errors.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] net: ethernet : stmicro: fixed power suspend and resume failure in stmmac driver
From: David Miller @ 2014-10-01 17:45 UTC (permalink / raw)
To: hliang1025; +Cc: peppe.cavallaro, netdev, linux-kernel, adi-linux-docs
In-Reply-To: <CAPig_t=oA6BuAt77DDsLqrtRBDbV_vsoAxM31XxLjkAFpYG1-Q@mail.gmail.com>
From: Hao Liang <hliang1025@gmail.com>
Date: Wed, 1 Oct 2014 14:08:28 +0800
> I double-check my patch and the ->mac->xxx calls are still under the lock.
> I think that lock is trying to protect priv struct and related data, so i
> just remove some functions have no bearing on priv struct.
It's preventing parallel invocations of the ->mac->xxx calls.
The other instances are in device open/close, where RTNL semaphore is
held, and no other code paths in the driver can be active.
You need the lock.
^ permalink raw reply
* Re: [PATCH net-next] udp: increment UDP_NO_PORTS when dropping unmatched multicasts
From: Rick Jones @ 2014-10-01 17:51 UTC (permalink / raw)
To: eric.dumazet, netdev; +Cc: davem
In-Reply-To: <542C3D28.6050705@oracle.com>
On 10/01/2014 10:43 AM, David L Stevens wrote:
>
>
> On 10/01/2014 01:32 PM, Rick Jones wrote:
>
>> It would be an added statistic for "ignored" UDP multicast datagrams, incremented instead of UDP_MIB_NOPORTS. "UDP_MIB_IGNOREDMULTI" if you will.
>>
>> Similar in concept to what HP-UX NIC drivers would increment when they received a frame for which there was no bound protocol - "inbound unknown protocols" but not a drop
>> http://ptgmedia.pearsoncmg.com/images/chap1_0130428167/elementLinks/01fig16.gif
>
> I guess I'm ok with that.
>
> Ideally, it wouldn't be affected by running a sniffer, so I think best would be to increment
> NOPORTS when someone has joined the group on the interface and IGNOREDMULTI when nobody has,
> but I'm not sure it's worth the trouble to check. So I'm good with that, or IGNOREDMULTI all
> the time.
Eric -
What is your feeling? I have a UDP_MIB_NOPORTS v2 with UDP lite, fixed
inner_flushed and IPv6 I can post now, or I can tweak it to add an
IGNOREDMULTI stat and use that instead of NOPORTS. If taking the
IGNOREDMULTI path, I'd be inclined to go with consume_skb()
unconditionally since the philosophy would be that it is an ignored
packet rather than a drop (similar to the recent change in ARP).
rick
^ permalink raw reply
* Re: [PATCH] net: dsa: Fix build warning for !PM_SLEEP
From: Florian Fainelli @ 2014-10-01 18:13 UTC (permalink / raw)
To: Thierry Reding, David S. Miller; +Cc: netdev, linux-kernel
In-Reply-To: <1412164740-32452-1-git-send-email-thierry.reding@gmail.com>
On 10/01/2014 04:59 AM, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> The dsa_switch_suspend() and dsa_switch_resume() functions are only used
> when PM_SLEEP is enabled, so they need #ifdef CONFIG_PM_SLEEP protection
> to avoid a compiler warning.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Thanks Thierry!
> ---
> net/dsa/dsa.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
> index 6905f2d84c44..22f34cf4cb27 100644
> --- a/net/dsa/dsa.c
> +++ b/net/dsa/dsa.c
> @@ -238,6 +238,7 @@ static void dsa_switch_destroy(struct dsa_switch *ds)
> {
> }
>
> +#ifdef CONFIG_PM_SLEEP
> static int dsa_switch_suspend(struct dsa_switch *ds)
> {
> int i, ret = 0;
> @@ -280,6 +281,7 @@ static int dsa_switch_resume(struct dsa_switch *ds)
>
> return 0;
> }
> +#endif
>
>
> /* link polling *************************************************************/
>
^ permalink raw reply
* Re: [PATCH net v6 4/4] tg3: Fix tx_pending checks for tg3_tso_bug
From: Prashant @ 2014-10-01 18:29 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, bpoirier, mchan, netdev, linux-kernel
In-Reply-To: <1412137489.16704.26.camel@edumazet-glaptop2.roam.corp.google.com>
On 9/30/2014 9:24 PM, Eric Dumazet wrote:
> On Tue, 2014-09-30 at 20:14 -0700, Prashant wrote:
>
>> Sorry about the late reply, out of all the HW bug conditions checked in
>> tg3_tx_frag_set() the most frequently hit condition is the short 8 byte
>> dma bug, where the chip cannot handle TX descriptors whose data buffer
>> is 8 bytes or less. Most of the LSO skb's given to the driver has their
>> fragments filled upto PAGE_SIZE (expect the last fragment depending on
>> skb->len). And if such a LSO skb's last fragment meets the 8 bytes HW
>> bug condition the above routine will not help workaround this particular
>> case.
>
> Thats pretty easy to work around.
>
> Say rebuilt skb has N frags (N > 1 given your description)
>
> They are numbered 0, ... N-2, N-1
>
> Instead of filling N-2 completely, fill it to PAGE_SIZE-8, so that last
> frag has at least 8 bytes in it.
definitely it can be tweaked to match what is needed with additional
workarounds.
>
> Also take a look at commit 2e4e44107176d552f8bb1bb76053e850e3809841
> ("net: add alloc_skb_with_frags() helper")
>
>
This helper is much modular/flexible than the initial proposed one. Thanks.
>
^ permalink raw reply
* [PATCH net-next] net: bcmgenet: fix bcmgenet_put_tx_csum()
From: Petri Gynther @ 2014-10-01 18:30 UTC (permalink / raw)
To: netdev; +Cc: davem, f.fainelli
bcmgenet_put_tx_csum() needs to return skb pointer back to the caller
because it reallocates a new one in case of lack of skb headroom.
Signed-off-by: Petri Gynther <pgynther@google.com>
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index 77cb755..d51729c 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -1054,7 +1054,8 @@ static int bcmgenet_xmit_frag(struct net_device *dev,
/* Reallocate the SKB to put enough headroom in front of it and insert
* the transmit checksum offsets in the descriptors
*/
-static int bcmgenet_put_tx_csum(struct net_device *dev, struct sk_buff *skb)
+static struct sk_buff *bcmgenet_put_tx_csum(struct net_device *dev,
+ struct sk_buff *skb)
{
struct status_64 *status = NULL;
struct sk_buff *new_skb;
@@ -1072,7 +1073,7 @@ static int bcmgenet_put_tx_csum(struct net_device *dev, struct sk_buff *skb)
if (!new_skb) {
dev->stats.tx_errors++;
dev->stats.tx_dropped++;
- return -ENOMEM;
+ return NULL;
}
skb = new_skb;
}
@@ -1090,7 +1091,7 @@ static int bcmgenet_put_tx_csum(struct net_device *dev, struct sk_buff *skb)
ip_proto = ipv6_hdr(skb)->nexthdr;
break;
default:
- return 0;
+ return skb;
}
offset = skb_checksum_start_offset(skb) - sizeof(*status);
@@ -1111,7 +1112,7 @@ static int bcmgenet_put_tx_csum(struct net_device *dev, struct sk_buff *skb)
status->tx_csum_info = tx_csum_info;
}
- return 0;
+ return skb;
}
static netdev_tx_t bcmgenet_xmit(struct sk_buff *skb, struct net_device *dev)
@@ -1158,8 +1159,8 @@ static netdev_tx_t bcmgenet_xmit(struct sk_buff *skb, struct net_device *dev)
/* set the SKB transmit checksum */
if (priv->desc_64b_en) {
- ret = bcmgenet_put_tx_csum(dev, skb);
- if (ret) {
+ skb = bcmgenet_put_tx_csum(dev, skb);
+ if (!skb) {
ret = NETDEV_TX_OK;
goto out;
}
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next] net: phy: add BCM7425 and BCM7429 PHYs
From: Petri Gynther @ 2014-10-01 18:31 UTC (permalink / raw)
To: netdev; +Cc: davem, f.fainelli
Signed-off-by: Petri Gynther <pgynther@google.com>
---
drivers/net/phy/bcm7xxx.c | 28 ++++++++++++++++++++++++++++
include/linux/brcmphy.h | 2 ++
2 files changed, 30 insertions(+)
diff --git a/drivers/net/phy/bcm7xxx.c b/drivers/net/phy/bcm7xxx.c
index daae699..0ae90f1 100644
--- a/drivers/net/phy/bcm7xxx.c
+++ b/drivers/net/phy/bcm7xxx.c
@@ -350,6 +350,32 @@ static struct phy_driver bcm7xxx_driver[] = {
BCM7XXX_28NM_GPHY(PHY_ID_BCM7439, "Broadcom BCM7439"),
BCM7XXX_28NM_GPHY(PHY_ID_BCM7445, "Broadcom BCM7445"),
{
+ .phy_id = PHY_ID_BCM7425,
+ .phy_id_mask = 0xffffffff,
+ .name = "Broadcom BCM7425 External PHY",
+ .features = PHY_GBIT_FEATURES |
+ SUPPORTED_Pause | SUPPORTED_Asym_Pause,
+ .flags = 0,
+ .config_init = bcm7xxx_config_init,
+ .config_aneg = genphy_config_aneg,
+ .read_status = genphy_read_status,
+ .suspend = bcm7xxx_suspend,
+ .resume = bcm7xxx_config_init,
+ .driver = { .owner = THIS_MODULE },
+}, {
+ .phy_id = PHY_ID_BCM7429,
+ .phy_id_mask = 0xffffffff,
+ .name = "Broadcom BCM7429 Internal PHY",
+ .features = PHY_GBIT_FEATURES |
+ SUPPORTED_Pause | SUPPORTED_Asym_Pause,
+ .flags = PHY_IS_INTERNAL,
+ .config_init = bcm7xxx_config_init,
+ .config_aneg = genphy_config_aneg,
+ .read_status = genphy_read_status,
+ .suspend = bcm7xxx_suspend,
+ .resume = bcm7xxx_config_init,
+ .driver = { .owner = THIS_MODULE },
+}, {
.phy_id = PHY_BCM_OUI_4,
.phy_id_mask = 0xffff0000,
.name = "Broadcom BCM7XXX 40nm",
@@ -381,6 +407,8 @@ static struct mdio_device_id __maybe_unused bcm7xxx_tbl[] = {
{ PHY_ID_BCM7250, 0xfffffff0, },
{ PHY_ID_BCM7364, 0xfffffff0, },
{ PHY_ID_BCM7366, 0xfffffff0, },
+ { PHY_ID_BCM7425, 0xffffffff, },
+ { PHY_ID_BCM7429, 0xffffffff, },
{ PHY_ID_BCM7439, 0xfffffff0, },
{ PHY_ID_BCM7445, 0xfffffff0, },
{ PHY_BCM_OUI_4, 0xffff0000 },
diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h
index 3f626fe..666132e 100644
--- a/include/linux/brcmphy.h
+++ b/include/linux/brcmphy.h
@@ -16,6 +16,8 @@
#define PHY_ID_BCM7250 0xae025280
#define PHY_ID_BCM7364 0xae025260
#define PHY_ID_BCM7366 0x600d8490
+#define PHY_ID_BCM7425 0x03625e69
+#define PHY_ID_BCM7429 0x600d8731
#define PHY_ID_BCM7439 0x600d8480
#define PHY_ID_BCM7445 0x600d8510
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* Re: linux-next: manual merge of the net-next tree with the berlin tree
From: Sebastian Hesselbarth @ 2014-10-01 18:31 UTC (permalink / raw)
To: Stephen Rothwell, David Miller, netdev
Cc: linux-next, linux-kernel, Antoine Ténart
In-Reply-To: <20141001112212.44f53d35@canb.auug.org.au>
On 01.10.2014 03:22, Stephen Rothwell wrote:
> Today's linux-next merge of the net-next tree got a conflict in
> arch/arm/boot/dts/berlin2q-marvell-dmp.dts between commit 461316fca705
> ("ARM: berlin: enable the eSATA interface on the BG2Q DMP") from the
> berlin tree and commit 75215193b975 ("ARM: dts: berlin: enable the
> Ethernet port on the BG2Q DMP") from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Looks good to me,
Thanks Stephen!
Sebastian
^ permalink raw reply
* Re: [PATCH net-next] net: phy: add BCM7425 and BCM7429 PHYs
From: Florian Fainelli @ 2014-10-01 18:34 UTC (permalink / raw)
To: Petri Gynther, netdev; +Cc: davem
In-Reply-To: <20141001183102.DF007100A08@puck.mtv.corp.google.com>
Hello Petri,
This looks good to me, some minor comments below
On 10/01/2014 11:31 AM, Petri Gynther wrote:
> Signed-off-by: Petri Gynther <pgynther@google.com>
> ---
> drivers/net/phy/bcm7xxx.c | 28 ++++++++++++++++++++++++++++
> include/linux/brcmphy.h | 2 ++
> 2 files changed, 30 insertions(+)
>
> diff --git a/drivers/net/phy/bcm7xxx.c b/drivers/net/phy/bcm7xxx.c
> index daae699..0ae90f1 100644
> --- a/drivers/net/phy/bcm7xxx.c
> +++ b/drivers/net/phy/bcm7xxx.c
> @@ -350,6 +350,32 @@ static struct phy_driver bcm7xxx_driver[] = {
> BCM7XXX_28NM_GPHY(PHY_ID_BCM7439, "Broadcom BCM7439"),
> BCM7XXX_28NM_GPHY(PHY_ID_BCM7445, "Broadcom BCM7445"),
> {
> + .phy_id = PHY_ID_BCM7425,
> + .phy_id_mask = 0xffffffff,
The last 4 bits contain the revision, although we never increased it, it
is safer to match with 0xffff_fff0. If that means dropping the catch all
40nm entry, that's fine by me.
> + .name = "Broadcom BCM7425 External PHY",
Just use "Broadcom BCM7425" here, for consistency with the other
entries, and since that's really the internal PHY of the chip.
> + .features = PHY_GBIT_FEATURES |
> + SUPPORTED_Pause | SUPPORTED_Asym_Pause,
> + .flags = 0,
> + .config_init = bcm7xxx_config_init,
> + .config_aneg = genphy_config_aneg,
> + .read_status = genphy_read_status,
> + .suspend = bcm7xxx_suspend,
> + .resume = bcm7xxx_config_init,
> + .driver = { .owner = THIS_MODULE },
> +}, {
> + .phy_id = PHY_ID_BCM7429,
> + .phy_id_mask = 0xffffffff,
> + .name = "Broadcom BCM7429 Internal PHY",
Same thing here.
> + .features = PHY_GBIT_FEATURES |
> + SUPPORTED_Pause | SUPPORTED_Asym_Pause,
> + .flags = PHY_IS_INTERNAL,
> + .config_init = bcm7xxx_config_init,
> + .config_aneg = genphy_config_aneg,
> + .read_status = genphy_read_status,
> + .suspend = bcm7xxx_suspend,
> + .resume = bcm7xxx_config_init,
> + .driver = { .owner = THIS_MODULE },
> +}, {
> .phy_id = PHY_BCM_OUI_4,
> .phy_id_mask = 0xffff0000,
> .name = "Broadcom BCM7XXX 40nm",
> @@ -381,6 +407,8 @@ static struct mdio_device_id __maybe_unused bcm7xxx_tbl[] = {
> { PHY_ID_BCM7250, 0xfffffff0, },
> { PHY_ID_BCM7364, 0xfffffff0, },
> { PHY_ID_BCM7366, 0xfffffff0, },
> + { PHY_ID_BCM7425, 0xffffffff, },
> + { PHY_ID_BCM7429, 0xffffffff, },
> { PHY_ID_BCM7439, 0xfffffff0, },
> { PHY_ID_BCM7445, 0xfffffff0, },
> { PHY_BCM_OUI_4, 0xffff0000 },
> diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h
> index 3f626fe..666132e 100644
> --- a/include/linux/brcmphy.h
> +++ b/include/linux/brcmphy.h
> @@ -16,6 +16,8 @@
> #define PHY_ID_BCM7250 0xae025280
> #define PHY_ID_BCM7364 0xae025260
> #define PHY_ID_BCM7366 0x600d8490
> +#define PHY_ID_BCM7425 0x03625e69
> +#define PHY_ID_BCM7429 0x600d8731
> #define PHY_ID_BCM7439 0x600d8480
> #define PHY_ID_BCM7445 0x600d8510
>
>
^ 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