* Re: [PATCH 3/4] sctp: fix some comments in associola.c
From: Vlad Yasevich @ 2013-10-25 23:43 UTC (permalink / raw)
To: Wang Weidong, davem, nhorman; +Cc: dingtianhong, linux-sctp, netdev
In-Reply-To: <1382665805-13952-4-git-send-email-wangweidong1@huawei.com>
On 10/24/2013 09:50 PM, Wang Weidong wrote:
> fix some spellings
>
> Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
-vlad
> ---
> net/sctp/associola.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/sctp/associola.c b/net/sctp/associola.c
> index cef5099..c9b91cb 100644
> --- a/net/sctp/associola.c
> +++ b/net/sctp/associola.c
> @@ -602,7 +602,7 @@ void sctp_assoc_rm_peer(struct sctp_association *asoc,
>
> /* Start a T3 timer here in case it wasn't running so
> * that these migrated packets have a chance to get
> - * retrnasmitted.
> + * retransmitted.
> */
> if (!timer_pending(&active->T3_rtx_timer))
> if (!mod_timer(&active->T3_rtx_timer,
> @@ -665,7 +665,7 @@ struct sctp_transport *sctp_assoc_add_peer(struct sctp_association *asoc,
> /* Set the path max_retrans. */
> peer->pathmaxrxt = asoc->pathmaxrxt;
>
> - /* And the partial failure retrnas threshold */
> + /* And the partial failure retrans threshold */
> peer->pf_retrans = asoc->pf_retrans;
>
> /* Initialize the peer's SACK delay timeout based on the
>
^ permalink raw reply
* Re: [PATCH 4/4] sctp: fix comment in chunk.c
From: Vlad Yasevich @ 2013-10-25 23:45 UTC (permalink / raw)
To: Wang Weidong, davem, nhorman; +Cc: dingtianhong, linux-sctp, netdev
In-Reply-To: <1382665805-13952-5-git-send-email-wangweidong1@huawei.com>
On 10/24/2013 09:50 PM, Wang Weidong wrote:
> fix a spelling
>
> Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
You could have combined these spelling fixes into 1 patch.
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
-vlad
> ---
> net/sctp/chunk.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/sctp/chunk.c b/net/sctp/chunk.c
> index 7bd5ed4..f2044fc 100644
> --- a/net/sctp/chunk.c
> +++ b/net/sctp/chunk.c
> @@ -201,7 +201,7 @@ struct sctp_datamsg *sctp_datamsg_from_user(struct sctp_association *asoc,
>
> max = asoc->frag_point;
> /* If the the peer requested that we authenticate DATA chunks
> - * we need to accound for bundling of the AUTH chunks along with
> + * we need to account for bundling of the AUTH chunks along with
> * DATA.
> */
> if (sctp_auth_send_cid(SCTP_CID_DATA, asoc)) {
>
^ permalink raw reply
* [PATCH net-next] tcp: gso: fix truesize tracking
From: Eric Dumazet @ 2013-10-26 0:26 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: David Miller, Eric Dumazet, stephen, netdev
In-Reply-To: <1382743502.4032.6.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <edumazet@google.com>
commit 6ff50cd55545 ("tcp: gso: do not generate out of order packets")
had an heuristic that can trigger a warning in skb_try_coalesce(),
because skb->truesize of the gso segments were exactly set to mss.
This breaks the requirement that
skb->truesize >= skb->len + truesizeof(struct sk_buff);
It can trivially be reproduced by :
ifconfig lo mtu 1500
ethtool -K lo tso off
netperf
As the skbs are looped into the TCP networking stack, skb_try_coalesce()
warns us of these skb under-estimating their truesize.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Alexei Starovoitov <ast@plumgrid.com>
---
Based on net-next but applies as well on net tree with some fuzz.
David, we might backport this one to 3.12 and stable later, I let you
decide.
net/ipv4/tcp_offload.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/net/ipv4/tcp_offload.c b/net/ipv4/tcp_offload.c
index a7a5583e..a2b68a1 100644
--- a/net/ipv4/tcp_offload.c
+++ b/net/ipv4/tcp_offload.c
@@ -18,6 +18,7 @@ struct sk_buff *tcp_gso_segment(struct sk_buff *skb,
netdev_features_t features)
{
struct sk_buff *segs = ERR_PTR(-EINVAL);
+ unsigned int sum_truesize = 0;
struct tcphdr *th;
unsigned int thlen;
unsigned int seq;
@@ -104,13 +105,7 @@ struct sk_buff *tcp_gso_segment(struct sk_buff *skb,
if (copy_destructor) {
skb->destructor = gso_skb->destructor;
skb->sk = gso_skb->sk;
- /* {tcp|sock}_wfree() use exact truesize accounting :
- * sum(skb->truesize) MUST be exactly be gso_skb->truesize
- * So we account mss bytes of 'true size' for each segment.
- * The last segment will contain the remaining.
- */
- skb->truesize = mss;
- gso_skb->truesize -= mss;
+ sum_truesize += skb->truesize;
}
skb = skb->next;
th = tcp_hdr(skb);
@@ -127,7 +122,9 @@ struct sk_buff *tcp_gso_segment(struct sk_buff *skb,
if (copy_destructor) {
swap(gso_skb->sk, skb->sk);
swap(gso_skb->destructor, skb->destructor);
- swap(gso_skb->truesize, skb->truesize);
+ sum_truesize += skb->truesize;
+ atomic_add(sum_truesize - gso_skb->truesize,
+ &skb->sk->sk_wmem_alloc);
}
delta = htonl(oldlen + (skb_tail_pointer(skb) -
^ permalink raw reply related
* Re: vxlan gso is broken by stackable gso_segment()
From: Eric Dumazet @ 2013-10-26 0:52 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: David Miller, Eric Dumazet, stephen, netdev
In-Reply-To: <1382743502.4032.6.camel@edumazet-glaptop.roam.corp.google.com>
On Fri, 2013-10-25 at 16:25 -0700, Eric Dumazet wrote:
> Please note the original performance is not that good, you mentioned 230
> Mbps on lxc, while I get more than 5Gb/s on a 10G link.
>
> This should be investigated ...
This is probably trivial to increase performance :
veth currently do not support any kind of tunneling TSO :
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-ipip-segmentation: off [fixed]
tx-sit-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-mpls-segmentation: off [fixed]
I'll submit a patch for net-next
^ permalink raw reply
* [PATCH net-next] veth: extend features to support tunneling
From: Eric Dumazet @ 2013-10-26 1:25 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: David Miller, Eric Dumazet, stephen, netdev
In-Reply-To: <1382748742.4032.24.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <edumazet@google.com>
While investigating on a recent vxlan regression, I found veth
was using a zero features set for vxlan tunnels.
We have to segment GSO frames, copy the payload, and do the checksum.
This patch brings a ~200% performance increase
We probably have to add hw_enc_features support
on other virtual devices.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Alexei Starovoitov <ast@plumgrid.com>
---
drivers/net/veth.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index b2d0347..b24db7a 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -261,6 +261,8 @@ static const struct net_device_ops veth_netdev_ops = {
#define VETH_FEATURES (NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_ALL_TSO | \
NETIF_F_HW_CSUM | NETIF_F_RXCSUM | NETIF_F_HIGHDMA | \
+ NETIF_F_GSO_GRE | NETIF_F_GSO_UDP_TUNNEL | \
+ NETIF_F_GSO_IPIP | NETIF_F_GSO_SIT | NETIF_F_UFO | \
NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_CTAG_RX | \
NETIF_F_HW_VLAN_STAG_TX | NETIF_F_HW_VLAN_STAG_RX )
@@ -279,6 +281,7 @@ static void veth_setup(struct net_device *dev)
dev->destructor = veth_dev_free;
dev->hw_features = VETH_FEATURES;
+ dev->hw_enc_features = VETH_FEATURES;
}
/*
^ permalink raw reply related
* Re: [PATCH net-next] tcp: gso: fix truesize tracking
From: Alexei Starovoitov @ 2013-10-26 1:46 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Eric Dumazet, stephen, netdev
In-Reply-To: <1382747177.4032.21.camel@edumazet-glaptop.roam.corp.google.com>
On Fri, Oct 25, 2013 at 5:26 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> commit 6ff50cd55545 ("tcp: gso: do not generate out of order packets")
> had an heuristic that can trigger a warning in skb_try_coalesce(),
> because skb->truesize of the gso segments were exactly set to mss.
>
> This breaks the requirement that
>
> skb->truesize >= skb->len + truesizeof(struct sk_buff);
>
> It can trivially be reproduced by :
>
> ifconfig lo mtu 1500
> ethtool -K lo tso off
> netperf
>
> As the skbs are looped into the TCP networking stack, skb_try_coalesce()
> warns us of these skb under-estimating their truesize.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Alexei Starovoitov <ast@plumgrid.com>
> ---
it fixed it in my setup. Thanks!
^ permalink raw reply
* Re: [PATCH net-next] veth: extend features to support tunneling
From: Alexei Starovoitov @ 2013-10-26 2:22 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Eric Dumazet, stephen, netdev
In-Reply-To: <1382750703.4032.32.camel@edumazet-glaptop.roam.corp.google.com>
On Fri, Oct 25, 2013 at 6:25 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> While investigating on a recent vxlan regression, I found veth
> was using a zero features set for vxlan tunnels.
oneliner can be better :)
> We have to segment GSO frames, copy the payload, and do the checksum.
>
> This patch brings a ~200% performance increase
>
> We probably have to add hw_enc_features support
> on other virtual devices.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Alexei Starovoitov <ast@plumgrid.com>
> ---
iperf over veth with gre/vxlan tunneling is now ~4Gbps. 20x gain as advertised.
Thanks!
^ permalink raw reply
* Re: [PATCH 1/4] sctp: merge two if statements to one
From: wangweidong @ 2013-10-26 2:55 UTC (permalink / raw)
To: Sergei Shtylyov, davem, nhorman, vyasevich
Cc: dingtianhong, linux-sctp, netdev
In-Reply-To: <526A6C45.3080200@cogentembedded.com>
On 2013/10/25 21:04, Sergei Shtylyov wrote:
> Hello.
>
> On 25-10-2013 5:50, Wang Weidong wrote:
>
>> Two if statements do the same work, maybe we can merge them to
>> one. There is just code simplification, no functional changes.
>
>> Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
>> ---
>> net/sctp/auth.c | 12 ++++--------
>> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> I understand what I noticed below is not your typos but maybe it's time to fix them?
Yeah, I will fix them.
Thanks.
>
>> diff --git a/net/sctp/auth.c b/net/sctp/auth.c
>> index 8c4fa5d..19fb0ae 100644
>> --- a/net/sctp/auth.c
>> +++ b/net/sctp/auth.c
>> @@ -539,18 +539,14 @@ struct sctp_hmac *sctp_auth_asoc_get_hmac(const struct sctp_association *asoc)
>> for (i = 0; i < n_elt; i++) {
>> id = ntohs(hmacs->hmac_ids[i]);
>>
>> - /* Check the id is in the supported range */
>> - if (id > SCTP_AUTH_HMAC_ID_MAX) {
>> - id = 0;
>> - continue;
>> - }
>> -
>> - /* See is we support the id. Supported IDs have name and
>> + /* Check the id is in the supported range. And
>> + * see is we support the id. Supported IDs have name and
>
> s/is/if/.
>
>> * length fields set, so that we can allocated and use
>
> s/allocated/allocate/.
>
> WBR, Sergei
>
>
>
^ permalink raw reply
* Re: [PATCH 1/4] sctp: merge two if statements to one
From: wangweidong @ 2013-10-26 2:59 UTC (permalink / raw)
To: Vlad Yasevich, davem, nhorman; +Cc: dingtianhong, linux-sctp, netdev
In-Reply-To: <526B016D.6030301@gmail.com>
On 2013/10/26 7:40, Vlad Yasevich wrote:
> On 10/24/2013 09:50 PM, Wang Weidong wrote:
>> Two if statements do the same work, maybe we can merge them to
>> one. There is just code simplification, no functional changes.
>>
>> Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
>> ---
>> net/sctp/auth.c | 12 ++++--------
>> 1 file changed, 4 insertions(+), 8 deletions(-)
>>
>> diff --git a/net/sctp/auth.c b/net/sctp/auth.c
>> index 8c4fa5d..19fb0ae 100644
>> --- a/net/sctp/auth.c
>> +++ b/net/sctp/auth.c
>> @@ -539,18 +539,14 @@ struct sctp_hmac *sctp_auth_asoc_get_hmac(const struct sctp_association *asoc)
>> for (i = 0; i < n_elt; i++) {
>> id = ntohs(hmacs->hmac_ids[i]);
>>
>> - /* Check the id is in the supported range */
>> - if (id > SCTP_AUTH_HMAC_ID_MAX) {
>> - id = 0;
>> - continue;
>> - }
>> -
>> - /* See is we support the id. Supported IDs have name and
>> + /* Check the id is in the supported range. And
>> + * see is we support the id. Supported IDs have name and
>> * length fields set, so that we can allocated and use
>> * them. We can safely just check for name, for without the
>> * name, we can't allocate the TFM.
>> */
>> - if (!sctp_hmac_list[id].hmac_name) {
>> + if (id > SCTP_AUTH_HMAC_ID_MAX ||
>> + !sctp_hmac_list[id].hmac_name) {
>
> Can you please make the 2 parts of the 'if' statement above line up
> with each other instead of the code below. I makes it easy to see what
> the whole 'if conditional' is.
>
> Thanks
> -vlad
>
Ok, I will resend a new version.
Thanks.
>> id = 0;
>> continue;
>> }
>>
>
>
>
^ permalink raw reply
* Re: [PATCH net 0/2] qlcnic: Bug fixes
From: David Miller @ 2013-10-26 4:05 UTC (permalink / raw)
To: shahed.shaikh; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1382711917-28501-1-git-send-email-shahed.shaikh@qlogic.com>
From: Shahed Shaikh <shahed.shaikh@qlogic.com>
Date: Fri, 25 Oct 2013 10:38:35 -0400
> From: Shahed Shaikh <shahed.shaikh@qlogic.com>
>
> This patch series contains following fixes-
> * Performace drop because driver was forcing adapter not to check
> destination IP for LRO.
> * driver was not issuing qlcnic_fw_cmd_set_drv_version() to 83xx adapter
> becasue of improper handling of QLCNIC_FW_CAPABILITY_MORE_CAPS bit.
>
> Please apply to net.
Applied, what exactly does that destination IP check do?
^ permalink raw reply
* Re: [PATCH net-next] veth: extend features to support tunneling
From: Eric Dumazet @ 2013-10-26 4:13 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: David Miller, Eric Dumazet, stephen, netdev
In-Reply-To: <CAMEtUuwgDpLFMj0DNx+c4QZz573rgmLiNcZOmHgou2A3684Shw@mail.gmail.com>
On Fri, 2013-10-25 at 19:22 -0700, Alexei Starovoitov wrote:
> On Fri, Oct 25, 2013 at 6:25 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > From: Eric Dumazet <edumazet@google.com>
> >
> > While investigating on a recent vxlan regression, I found veth
> > was using a zero features set for vxlan tunnels.
>
> oneliner can be better :)
Yes, I'll post the gso fix as well, of course ;)
>
> > We have to segment GSO frames, copy the payload, and do the checksum.
> >
> > This patch brings a ~200% performance increase
> >
> > We probably have to add hw_enc_features support
> > on other virtual devices.
> >
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > Cc: Alexei Starovoitov <ast@plumgrid.com>
> > ---
>
> iperf over veth with gre/vxlan tunneling is now ~4Gbps. 20x gain as advertised.
> Thanks!
Wow, such a difference might show another bug somewhere else...
Thanks !
^ permalink raw reply
* Hi,
From: John Reynolds @ 2013-10-26 4:15 UTC (permalink / raw)
To: netdev
Hi,
Is there a userspace API that can be used to determine if a network interface is a 802.1Q interface, and what its vlan id and parent interface is. it appears that SOICGIFPFLAGS is not supported and netdev_priv() is only available to drivers, or do I have to resort to parsing the /proc/net/* files ?
regards
^ permalink raw reply
* Re: [PATCH net 1/2] qlcnic: Do not force adapter to perform LRO without destination IP check
From: Eric Dumazet @ 2013-10-26 4:17 UTC (permalink / raw)
To: Shahed Shaikh; +Cc: davem, netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1382711917-28501-2-git-send-email-shahed.shaikh@qlogic.com>
On Fri, 2013-10-25 at 10:38 -0400, Shahed Shaikh wrote:
> From: Shahed Shaikh <shahed.shaikh@qlogic.com>
>
> Forcing adapter to perform LRO without destination IP check
> degrades the performance.
Hmm... the performance, or does it allow two packets belonging to
different flows being wrongly aggregated ?
It looks a critical bug fix, not only a performance issue.
^ permalink raw reply
* Re: [PATCH net-next] macsonic: Updated printk() statement to netdev_info function
From: Joe Perches @ 2013-10-26 4:26 UTC (permalink / raw)
To: Matt Zanchelli; +Cc: netdev
In-Reply-To: <1382738000-24202-1-git-send-email-zanchm@rpi.edu>
On Fri, 2013-10-25 at 21:53 +0000, Matt Zanchelli wrote:
> Updated the printk() statement in mac_sonic_probe() to recommended netdev_info.
Hi again Matt.
> Reviewed-by: Mukkai Krishnamoorthy <mskmoorthy@gmail.com>
> Reviewed-by: Maxwell Ensley-Field <mensleyfield@gmail.com>
> Reviewed-by: Nicole Negedly <nnegedly@gmail.com>
> Reviewed-by: Daniel Felizardo <danfelizardo@gmail.com>
> Signed-off-by: Matt Zanchelli <zanchm@rpi.edu>
Does it really take 4 reviewers for a single line change?
I'd rather have each of these reviewers submit patches to
different files rather than have them review this pretty
trivial change to a pretty old driver that really doesn't
need much in the way of changes.
And please, if you modify this file all, please be more
comprehensive in the printk conversions.
There are many printks in this file, not just this one.
> diff --git a/drivers/net/ethernet/natsemi/macsonic.c b/drivers/net/ethernet/natsemi/macsonic.c
[]
> @@ -601,7 +601,7 @@ found:
> if (err)
> goto out;
>
> - printk("%s: MAC %pM IRQ %d\n", dev->name, dev->dev_addr, dev->irq);
> + netdev_info(dev, "MAC %pM IRQ %d\n", dev->dev_addr, dev->irq);
>
> return 0;
Something like:
drivers/net/ethernet/natsemi/macsonic.c | 66 +++++++++++++++------------------
drivers/net/ethernet/natsemi/sonic.h | 3 +-
2 files changed, 30 insertions(+), 39 deletions(-)
diff --git a/drivers/net/ethernet/natsemi/macsonic.c b/drivers/net/ethernet/natsemi/macsonic.c
index 346a4e0..bc33181 100644
--- a/drivers/net/ethernet/natsemi/macsonic.c
+++ b/drivers/net/ethernet/natsemi/macsonic.c
@@ -31,6 +31,8 @@
* on centris.
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/types.h>
@@ -80,8 +82,6 @@ static unsigned int sonic_debug = SONIC_DEBUG;
static unsigned int sonic_debug = 1;
#endif
-static int sonic_version_printed;
-
/* For onboard SONIC */
#define ONBOARD_SONIC_REGISTERS 0x50F0A000
#define ONBOARD_SONIC_PROM_BASE 0x50f08000
@@ -143,8 +143,7 @@ static int macsonic_open(struct net_device* dev)
retval = request_irq(dev->irq, sonic_interrupt, 0, "sonic", dev);
if (retval) {
- printk(KERN_ERR "%s: unable to get IRQ %d.\n",
- dev->name, dev->irq);
+ netdev_err(dev, "unable to get IRQ %d\n", dev->irq);
goto err;
}
/* Under the A/UX interrupt scheme, the onboard SONIC interrupt comes
@@ -155,8 +154,7 @@ static int macsonic_open(struct net_device* dev)
retval = request_irq(IRQ_NUBUS_9, macsonic_interrupt, 0,
"sonic", dev);
if (retval) {
- printk(KERN_ERR "%s: unable to get IRQ %d.\n",
- dev->name, IRQ_NUBUS_9);
+ netdev_err(dev, "unable to get IRQ %d\n", IRQ_NUBUS_9);
goto err_irq;
}
}
@@ -277,11 +275,9 @@ static void mac_onboard_sonic_ethernet_addr(struct net_device *dev)
* If we still have what seems to be a bogus address, we'll
* look in the CAM. The top entry should be ours.
*/
- printk(KERN_WARNING "macsonic: MAC address in PROM seems "
- "to be invalid, trying CAM\n");
+ netdev_warn(dev, "MAC address in PROM seems to be invalid, trying CAM\n");
} else {
- printk(KERN_WARNING "macsonic: cannot read MAC address from "
- "PROM, trying CAM\n");
+ netdev_warn(dev, "cannot read MAC address from PROM, trying CAM\n");
}
/* This only works if MacOS has already initialized the card. */
@@ -304,8 +300,7 @@ static void mac_onboard_sonic_ethernet_addr(struct net_device *dev)
/* Still nonsense ... messed up someplace! */
- printk(KERN_WARNING "macsonic: MAC address in CAM entry 15 "
- "seems invalid, will use a random MAC\n");
+ netdev_warn(dev, "MAC address in CAM entry 15 seems invalid, will use a random MAC\n");
eth_hw_addr_random(dev);
}
@@ -318,7 +313,7 @@ static int mac_onboard_sonic_probe(struct net_device *dev)
if (!MACH_IS_MAC)
return -ENODEV;
- printk(KERN_INFO "Checking for internal Macintosh ethernet (SONIC).. ");
+ netdev_info(dev, "Checking for internal Macintosh ethernet (SONIC).. ");
/* Bogus probing, on the models which may or may not have
Ethernet (BTW, the Ethernet *is* always at the same
@@ -336,7 +331,7 @@ static int mac_onboard_sonic_probe(struct net_device *dev)
local_irq_restore(flags);
if (!card_present) {
- printk("none.\n");
+ printk("none\n");
return -ENODEV;
}
commslot = 1;
@@ -352,12 +347,10 @@ static int mac_onboard_sonic_probe(struct net_device *dev)
else
dev->irq = IRQ_NUBUS_9;
- if (!sonic_version_printed) {
- printk(KERN_INFO "%s", version);
- sonic_version_printed = 1;
- }
- printk(KERN_INFO "%s: onboard / comm-slot SONIC at 0x%08lx\n",
- dev_name(lp->device), dev->base_addr);
+ pr_info_once("%s\n", version);
+
+ netdev_info(dev, "onboard / comm-slot SONIC at 0x%08lx\n",
+ dev->base_addr);
/* The PowerBook's SONIC is 16 bit always. */
if (macintosh_config->ident == MAC_MODEL_PB520) {
@@ -388,13 +381,13 @@ static int mac_onboard_sonic_probe(struct net_device *dev)
lp->dma_bitmode = SONIC_BITMODE32;
sr = SONIC_READ(SONIC_SR);
}
- printk(KERN_INFO
- "%s: revision 0x%04x, using %d bit DMA and register offset %d\n",
- dev_name(lp->device), sr, lp->dma_bitmode?32:16, lp->reg_offset);
+ netdev_info(dev, "revision 0x%04x, using %d bit DMA and register offset %d\n",
+ sr, lp->dma_bitmode ? 32 : 16, lp->reg_offset);
#if 0 /* This is sometimes useful to find out how MacOS configured the card. */
- printk(KERN_INFO "%s: DCR: 0x%04x, DCR2: 0x%04x\n", dev_name(lp->device),
- SONIC_READ(SONIC_DCR) & 0xffff, SONIC_READ(SONIC_DCR2) & 0xffff);
+ netdev_info(dev, "DCR: 0x%04x, DCR2: 0x%04x\n",
+ SONIC_READ(SONIC_DCR) & 0xffff,
+ SONIC_READ(SONIC_DCR2) & 0xffff);
#endif
/* Software reset, then initialize control registers. */
@@ -527,7 +520,7 @@ static int mac_nubus_sonic_probe(struct net_device *dev)
dma_bitmode = SONIC_BITMODE16;
break;
default:
- printk(KERN_ERR "macsonic: WTF, id is %d\n", id);
+ netdev_err(dev, "WTF, id is %d\n", id);
return -ENODEV;
}
@@ -538,18 +531,17 @@ static int mac_nubus_sonic_probe(struct net_device *dev)
lp->dma_bitmode = dma_bitmode;
dev->irq = SLOT2IRQ(ndev->board->slot);
- if (!sonic_version_printed) {
- printk(KERN_INFO "%s", version);
- sonic_version_printed = 1;
- }
- printk(KERN_INFO "%s: %s in slot %X\n",
- dev_name(lp->device), ndev->board->name, ndev->board->slot);
- printk(KERN_INFO "%s: revision 0x%04x, using %d bit DMA and register offset %d\n",
- dev_name(lp->device), SONIC_READ(SONIC_SR), dma_bitmode?32:16, reg_offset);
+ pr_info_once("%s\n", version);
+
+ netdev_info(dev, "%s in slot %X\n",
+ ndev->board->name, ndev->board->slot);
+ netdev_info(dev, "revision 0x%04x, using %d bit DMA and register offset %d\n",
+ SONIC_READ(SONIC_SR), dma_bitmode ? 32 : 16, reg_offset);
#if 0 /* This is sometimes useful to find out how MacOS configured the card. */
- printk(KERN_INFO "%s: DCR: 0x%04x, DCR2: 0x%04x\n", dev_name(lp->device),
- SONIC_READ(SONIC_DCR) & 0xffff, SONIC_READ(SONIC_DCR2) & 0xffff);
+ netdev_info(dev, "DCR: 0x%04x, DCR2: 0x%04x\n",
+ SONIC_READ(SONIC_DCR) & 0xffff,
+ SONIC_READ(SONIC_DCR2) & 0xffff);
#endif
/* Software reset, then initialize control registers. */
@@ -601,7 +593,7 @@ found:
if (err)
goto out;
- printk("%s: MAC %pM IRQ %d\n", dev->name, dev->dev_addr, dev->irq);
+ netdev_info(dev, "MAC %pM IRQ %d\n", dev->dev_addr, dev->irq);
return 0;
diff --git a/drivers/net/ethernet/natsemi/sonic.h b/drivers/net/ethernet/natsemi/sonic.h
index 07091dd..6d31916 100644
--- a/drivers/net/ethernet/natsemi/sonic.h
+++ b/drivers/net/ethernet/natsemi/sonic.h
@@ -444,7 +444,6 @@ static inline __u16 sonic_rra_get(struct net_device* dev, int entry,
(entry * SIZEOF_SONIC_RR) + offset);
}
-static const char *version =
- "sonic.c:v0.92 20.9.98 tsbogend@alpha.franken.de\n";
+static const char *version = "v0.92 20.9.98 tsbogend@alpha.franken.de";
#endif /* SONIC_H */
^ permalink raw reply related
* Re: [net-next 00/11][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2013-10-26 4:30 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1382628458-26601-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 24 Oct 2013 08:27:27 -0700
> This series contains updates to igb, igbvf, i40e, ixgbe and ixgbevf.
Pulled, thanks a lot Jeff.
^ permalink raw reply
* Re: Hi,
From: Ben Greear @ 2013-10-26 5:04 UTC (permalink / raw)
To: John Reynolds; +Cc: netdev
In-Reply-To: <526B4FEC020000B100033DCD@mailhost1.datacore.uk.com>
On 10/25/2013 09:15 PM, John Reynolds wrote:
> Hi,
> Is there a userspace API that can be used to determine if a network interface is a 802.1Q interface, and what its vlan id and parent interface is. it appears that SOICGIFPFLAGS is not supported and netdev_priv() is only available to drivers, or do I have to resort to parsing the /proc/net/* files ?
>
> regards
The netlink API has it. You can use the 'ip' tool and parse it's text output,
though of course that is not an overly stable API.
I think the old VLAN ioctls are still in the kernel as well, so you can
use those like the 'vconfig' tool does.
http://www.candelatech.com/~greear/vlan.html
Please note that 'ip' is the way of the future and I have little interest
in actually supporting vconfig.
Thanks,
Ben
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH net-next 3/5] 6lowpan: use netdev_alloc_skb instead dev_alloc_skb
From: David Miller @ 2013-10-26 5:42 UTC (permalink / raw)
To: alex.aring
Cc: alex.bluesman.smirnov, linux-zigbee-devel, werner, dbaryshkov,
netdev
In-Reply-To: <1382647904-11311-4-git-send-email-alex.aring@gmail.com>
From: Alexander Aring <alex.aring@gmail.com>
Date: Thu, 24 Oct 2013 22:51:42 +0200
> @@ -1127,12 +1127,12 @@ lowpan_fragment_xmit(struct sk_buff *skb, u8 *head,
>
> lowpan_raw_dump_inline(__func__, "6lowpan fragment header", head, hlen);
>
> - frag = dev_alloc_skb(hlen + mlen + plen + IEEE802154_MFR_SIZE);
> + frag = netdev_alloc_skb(skb->dev, hlen + mlen +
> + plen + IEEE802154_MFR_SIZE);
Please indent this properly.
It should be something like:
frag = netdev_alloc_skb(skb->dev, hlen + mlen +
plen + IEEE802154_MFR_SIZE);
^ permalink raw reply
* Re: [PATCH RFC v2 1/4] net: mvmdio: make orion_mdio_wait_ready consistent
From: David Miller @ 2013-10-26 5:44 UTC (permalink / raw)
To: leigh; +Cc: linux-arm-kernel, thomas.petazzoni, netdev, sebastian.hesselbarth
In-Reply-To: <4955b6b331459b7b9c54350b8f0b254065d013c3.1382637156.git.leigh@solinno.co.uk>
From: Leigh Brown <leigh@solinno.co.uk>
Date: Thu, 24 Oct 2013 19:09:31 +0100
> + else
> + if (timedout)
> break;
>
Please make this:
else if (timedout)
break;
^ permalink raw reply
* Re: [PATCH RFC v2 3/4] net: mvmdio: slight optimisation of orion_mdio_write
From: David Miller @ 2013-10-26 5:45 UTC (permalink / raw)
To: leigh; +Cc: linux-arm-kernel, thomas.petazzoni, netdev, sebastian.hesselbarth
In-Reply-To: <6d044f3760cd506a325d5aab1199131ade96d632.1382637156.git.leigh@solinno.co.uk>
From: Leigh Brown <leigh@solinno.co.uk>
Date: Thu, 24 Oct 2013 19:09:33 +0100
> Make only a single call to mutex_unlock in orion_mdio_write.
>
> Signed-off-by: Leigh Brown <leigh@solinno.co.uk>
You patch does more than what you're talking about here in your
commit message. In particular you're also changing the interpretation
of the orion_mdio_wait_ready() return value by changing the test
from < 0 to != 0.
Even if that is a legitimate change:
1) You're not describing it in the commit message at all.
2) It's a logically separate change, so should go into a completely
separate patch.
^ permalink raw reply
* Re: [PATCH net-next 3/5] 6lowpan: use netdev_alloc_skb instead dev_alloc_skb
From: Joe Perches @ 2013-10-26 6:01 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20131026.014214.1636999222808937267.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Sat, 2013-10-26 at 01:42 -0400, David Miller wrote:
> From: Alexander Aring <alex.aring-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date: Thu, 24 Oct 2013 22:51:42 +0200
>
> > @@ -1127,12 +1127,12 @@ lowpan_fragment_xmit(struct sk_buff *skb, u8 *head,
> >
> > lowpan_raw_dump_inline(__func__, "6lowpan fragment header", head, hlen);
> >
> > - frag = dev_alloc_skb(hlen + mlen + plen + IEEE802154_MFR_SIZE);
> > + frag = netdev_alloc_skb(skb->dev, hlen + mlen +
> > + plen + IEEE802154_MFR_SIZE);
>
> Please indent this properly.
>
> It should be something like:
>
> frag = netdev_alloc_skb(skb->dev, hlen + mlen +
> plen + IEEE802154_MFR_SIZE);
Maybe better as:
frag = netdev_alloc_skb(skb->dev,
hlen + mlen + plen + IEEE802154_MFR_SIZE);
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
^ permalink raw reply
* Re: [PATCH 1/3] vxlan: silence one build warning
From: Zhi Yong Wu @ 2013-10-26 7:06 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, linux-kernel mlist, Zhi Yong Wu
In-Reply-To: <20131025084134.6cfa153a@samsung-9>
On Fri, Oct 25, 2013 at 11:41 PM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> On Fri, 25 Oct 2013 15:49:18 +0800
> Zhi Yong Wu <zwu.kernel@gmail.com> wrote:
>
>> From: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
>>
>> drivers/net/vxlan.c: In function ‘vxlan_sock_add’:
>> drivers/net/vxlan.c:2298:11: warning: ‘sock’ may be used uninitialized in this function [-Wmaybe-uninitialized]
>> drivers/net/vxlan.c:2275:17: note: ‘sock’ was declared here
>> LD drivers/net/built-in.o
>>
>> Signed-off-by: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
>> ---
>> drivers/net/vxlan.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
>> index 2ef5b62..e15f1af 100644
>> --- a/drivers/net/vxlan.c
>> +++ b/drivers/net/vxlan.c
>> @@ -2272,7 +2272,7 @@ static struct vxlan_sock *vxlan_socket_create(struct net *net, __be16 port,
>> {
>> struct vxlan_net *vn = net_generic(net, vxlan_net_id);
>> struct vxlan_sock *vs;
>> - struct socket *sock;
>> + struct socket *sock = NULL;
>> struct sock *sk;
>> int rc = 0;
>> unsigned int h;
>
> This only happens with certain versions of Gcc which have buggy dependency
> analysis. It doesn't happen with Gcc 4.7, think it only shows up in 4.4.
> I would rather not fix the warning this way since it risks masking later bugs if this code ever changes.
Gcc version is 4.7.2 on my box, this warning took palce.
# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
...
gcc version 4.7.2 20120921 (Red Hat 4.7.2-2) (GCC)
--
Regards,
Zhi Yong Wu
^ permalink raw reply
* [PATCH v2 2/3] sctp: remove the repeat initialize with 0
From: Wang Weidong @ 2013-10-26 8:06 UTC (permalink / raw)
To: nhorman, vyasevich; +Cc: davem, dingtianhong, linux-sctp, netdev
In-Reply-To: <1382774792-13440-1-git-send-email-wangweidong1@huawei.com>
kmem_cache_zalloc had set the allocated memory to zero. I think no need
to initialize with 0. And move the comments to the function begin.
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
---
net/sctp/sm_make_chunk.c | 29 ++++++++---------------------
1 file changed, 8 insertions(+), 21 deletions(-)
diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index d244a23..fe69032 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -1297,6 +1297,13 @@ struct sctp_chunk *sctp_make_auth(const struct sctp_association *asoc)
/* Turn an skb into a chunk.
* FIXME: Eventually move the structure directly inside the skb->cb[].
+ *
+ * sctpimpguide-05.txt Section 2.8.2
+ * M1) Each time a new DATA chunk is transmitted
+ * set the 'TSN.Missing.Report' count for that TSN to 0. The
+ * 'TSN.Missing.Report' count will be used to determine missing chunks
+ * and when to fast retransmit.
+ *
*/
struct sctp_chunk *sctp_chunkify(struct sk_buff *skb,
const struct sctp_association *asoc,
@@ -1314,29 +1321,9 @@ struct sctp_chunk *sctp_chunkify(struct sk_buff *skb,
INIT_LIST_HEAD(&retval->list);
retval->skb = skb;
retval->asoc = (struct sctp_association *)asoc;
- retval->has_tsn = 0;
- retval->has_ssn = 0;
- retval->rtt_in_progress = 0;
- retval->sent_at = 0;
retval->singleton = 1;
- retval->end_of_packet = 0;
- retval->ecn_ce_done = 0;
- retval->pdiscard = 0;
-
- /* sctpimpguide-05.txt Section 2.8.2
- * M1) Each time a new DATA chunk is transmitted
- * set the 'TSN.Missing.Report' count for that TSN to 0. The
- * 'TSN.Missing.Report' count will be used to determine missing chunks
- * and when to fast retransmit.
- */
- retval->tsn_missing_report = 0;
- retval->tsn_gap_acked = 0;
- retval->fast_retransmit = SCTP_CAN_FRTX;
- /* If this is a fragmented message, track all fragments
- * of the message (for SEND_FAILED).
- */
- retval->msg = NULL;
+ retval->fast_retransmit = SCTP_CAN_FRTX;
/* Polish the bead hole. */
INIT_LIST_HEAD(&retval->transmitted_list);
--
1.7.12
^ permalink raw reply related
* [PATCH v2 3/3] sctp: merge two if statements to one
From: Wang Weidong @ 2013-10-26 8:06 UTC (permalink / raw)
To: nhorman, vyasevich; +Cc: davem, dingtianhong, linux-sctp, netdev
In-Reply-To: <1382774792-13440-1-git-send-email-wangweidong1@huawei.com>
Two if statements do the same work, we can merge them to
one. And fix some typos. There is just code simplification,
no functional changes.
Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
---
net/sctp/auth.c | 14 +++++---------
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/net/sctp/auth.c b/net/sctp/auth.c
index 8c4fa5d..46b5977 100644
--- a/net/sctp/auth.c
+++ b/net/sctp/auth.c
@@ -539,18 +539,14 @@ struct sctp_hmac *sctp_auth_asoc_get_hmac(const struct sctp_association *asoc)
for (i = 0; i < n_elt; i++) {
id = ntohs(hmacs->hmac_ids[i]);
- /* Check the id is in the supported range */
- if (id > SCTP_AUTH_HMAC_ID_MAX) {
- id = 0;
- continue;
- }
-
- /* See is we support the id. Supported IDs have name and
- * length fields set, so that we can allocated and use
+ /* Check the id is in the supported range. And
+ * see if we support the id. Supported IDs have name and
+ * length fields set, so that we can allocate and use
* them. We can safely just check for name, for without the
* name, we can't allocate the TFM.
*/
- if (!sctp_hmac_list[id].hmac_name) {
+ if (id > SCTP_AUTH_HMAC_ID_MAX ||
+ !sctp_hmac_list[id].hmac_name) {
id = 0;
continue;
}
--
1.7.12
^ permalink raw reply related
* [PATCH v2 0/3] sctp: do some clean up and fix comments
From: Wang Weidong @ 2013-10-26 8:06 UTC (permalink / raw)
To: nhorman, vyasevich; +Cc: davem, dingtianhong, linux-sctp, netdev
This patch series includes some comments fix, merge tow if-statements,
remove the repeat initialize with 0.
v1 -> v2:
- patch1: combine two comment typos fix patches into one,
as suggested by Vlad, and add his ACK.
- patch2: add Vlad's ACK.
- patch3: line up 2 parts of 'if' statements, as suggested by Vlad.
fix some comment typos, as suggested by Sergei.
Wang Weidong (3):
sctp: fix some comments in chunk.c and associola.c
sctp: remove the repeat initialize with 0
sctp: merge two if statements to one
net/sctp/associola.c | 4 ++--
net/sctp/auth.c | 14 +++++---------
net/sctp/chunk.c | 2 +-
net/sctp/sm_make_chunk.c | 29 ++++++++---------------------
4 files changed, 16 insertions(+), 33 deletions(-)
--
1.7.12
^ permalink raw reply
* [PATCH v2 1/3] sctp: fix some comments in chunk.c and associola.c
From: Wang Weidong @ 2013-10-26 8:06 UTC (permalink / raw)
To: nhorman, vyasevich; +Cc: davem, dingtianhong, linux-sctp, netdev
In-Reply-To: <1382774792-13440-1-git-send-email-wangweidong1@huawei.com>
fix some typos
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
---
net/sctp/associola.c | 4 ++--
net/sctp/chunk.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/sctp/associola.c b/net/sctp/associola.c
index cef5099..c9b91cb 100644
--- a/net/sctp/associola.c
+++ b/net/sctp/associola.c
@@ -602,7 +602,7 @@ void sctp_assoc_rm_peer(struct sctp_association *asoc,
/* Start a T3 timer here in case it wasn't running so
* that these migrated packets have a chance to get
- * retrnasmitted.
+ * retransmitted.
*/
if (!timer_pending(&active->T3_rtx_timer))
if (!mod_timer(&active->T3_rtx_timer,
@@ -665,7 +665,7 @@ struct sctp_transport *sctp_assoc_add_peer(struct sctp_association *asoc,
/* Set the path max_retrans. */
peer->pathmaxrxt = asoc->pathmaxrxt;
- /* And the partial failure retrnas threshold */
+ /* And the partial failure retrans threshold */
peer->pf_retrans = asoc->pf_retrans;
/* Initialize the peer's SACK delay timeout based on the
diff --git a/net/sctp/chunk.c b/net/sctp/chunk.c
index 7bd5ed4..f2044fc 100644
--- a/net/sctp/chunk.c
+++ b/net/sctp/chunk.c
@@ -201,7 +201,7 @@ struct sctp_datamsg *sctp_datamsg_from_user(struct sctp_association *asoc,
max = asoc->frag_point;
/* If the the peer requested that we authenticate DATA chunks
- * we need to accound for bundling of the AUTH chunks along with
+ * we need to account for bundling of the AUTH chunks along with
* DATA.
*/
if (sctp_auth_send_cid(SCTP_CID_DATA, asoc)) {
--
1.7.12
^ permalink raw reply related
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