* Re: [PATCH] ppp: add 64 bit stats
From: David Miller @ 2012-07-22 21:54 UTC (permalink / raw)
To: kgroeneveld; +Cc: netdev
In-Reply-To: <1342988397-3077-1-git-send-email-kgroeneveld@gmail.com>
From: Kevin Groeneveld <kgroeneveld@gmail.com>
Date: Sun, 22 Jul 2012 16:19:56 -0400
> Add 64 bit stats to ppp driver. The 64 bit stats include tx_bytes,
> rx_bytes, tx_packets and rx_packets. Other stats are still 32 bit.
> The 64 bit stats can be retrieved via the ndo_get_stats operation. The
> SIOCGPPPSTATS ioctl is still 32 bit stats only.
>
> Signed-off-by: Kevin Groeneveld <kgroeneveld@gmail.com>
I don't see this as being very practical nor justified.
^ permalink raw reply
* Re: [PATCH] net: Fix references to out-of-scope variables in put_cmsg_compat()
From: David Miller @ 2012-07-22 21:54 UTC (permalink / raw)
To: jj; +Cc: netdev, linux-kernel
In-Reply-To: <alpine.LNX.2.00.1207222335200.31033@swampdragon.chaosbits.net>
From: Jesper Juhl <jj@chaosbits.net>
Date: Sun, 22 Jul 2012 23:37:20 +0200 (CEST)
> In net/compat.c::put_cmsg_compat() we may assign 'data' the address of
> either the 'ctv' or 'cts' local variables inside the 'if
> (!COMPAT_USE_64BIT_TIME)' branch.
>
> Those variables go out of scope at the end of the 'if' statement, so
> when we use 'data' further down in 'copy_to_user(CMSG_COMPAT_DATA(cm),
> data, cmlen - sizeof(struct compat_cmsghdr))' there's no telling what
> it may be refering to - not good.
>
> Fix the problem by simply giving 'ctv' and 'cts' function scope.
>
> Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [net-next 00/13][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2012-07-22 21:53 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1342993193.23226.0.camel@jtkirshe-mobl>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Sun, 22 Jul 2012 14:39:53 -0700
> On Sun, 2012-07-22 at 12:37 -0700, David Miller wrote:
>> From: David Miller <davem@davemloft.net>
>> Date: Sun, 22 Jul 2012 12:24:05 -0700 (PDT)
>>
>> > From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>> > Date: Sat, 21 Jul 2012 16:08:49 -0700
>> >
>> >> This series contains updates to ixgbe and ixgbevf.
>> >>
>> >> The following are changes since commit
>> 186e868786f97c8026f0a81400b451ace306b3a4:
>> >> forcedeth: spin_unlock_irq in interrupt handler fix
>> >> and are available in the git repository at:
>> >> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next
>> master
>> >
>> > Pulled, thanks Jeff.
>>
>> Can you guys actually build test this stuff?
>
> I did, but it appears I did not have PCI_IOV enabled. That was my bad,
> sorry.
If you're not doing "allmodconfig" builds, there are by definition
parts you are not testing. It's the first thing I do with any change
I apply.
^ permalink raw reply
* Re: [PATCH RFC] tcp: use seqlock for all cached tcp_metrics
From: David Miller @ 2012-07-22 21:50 UTC (permalink / raw)
To: ja; +Cc: netdev
In-Reply-To: <alpine.LFD.2.00.1207222314230.2458@ja.ssi.bg>
From: Julian Anastasov <ja@ssi.bg>
Date: Sun, 22 Jul 2012 23:34:38 +0300 (EEST)
> So, I can just send patch (or 2) for the tcpm_stamp and
> tcp_tw_remember_stamp problems, now or after 2 weeks?
You can send it now.
^ permalink raw reply
* Re: [net-next 00/13][pull request] Intel Wired LAN Driver Updates
From: Jeff Kirsher @ 2012-07-22 21:39 UTC (permalink / raw)
To: David Miller; +Cc: netdev, gospo, sassmann
In-Reply-To: <20120722.123733.1898891964192153293.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 768 bytes --]
On Sun, 2012-07-22 at 12:37 -0700, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Sun, 22 Jul 2012 12:24:05 -0700 (PDT)
>
> > From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > Date: Sat, 21 Jul 2012 16:08:49 -0700
> >
> >> This series contains updates to ixgbe and ixgbevf.
> >>
> >> The following are changes since commit
> 186e868786f97c8026f0a81400b451ace306b3a4:
> >> forcedeth: spin_unlock_irq in interrupt handler fix
> >> and are available in the git repository at:
> >> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next
> master
> >
> > Pulled, thanks Jeff.
>
> Can you guys actually build test this stuff?
I did, but it appears I did not have PCI_IOV enabled. That was my bad,
sorry.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] net: Fix references to out-of-scope variables in put_cmsg_compat()
From: Jesper Juhl @ 2012-07-22 21:37 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-kernel
In net/compat.c::put_cmsg_compat() we may assign 'data' the address of
either the 'ctv' or 'cts' local variables inside the 'if
(!COMPAT_USE_64BIT_TIME)' branch.
Those variables go out of scope at the end of the 'if' statement, so
when we use 'data' further down in 'copy_to_user(CMSG_COMPAT_DATA(cm),
data, cmlen - sizeof(struct compat_cmsghdr))' there's no telling what
it may be refering to - not good.
Fix the problem by simply giving 'ctv' and 'cts' function scope.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
net/compat.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/compat.c b/net/compat.c
index 1b96281..74ed1d7 100644
--- a/net/compat.c
+++ b/net/compat.c
@@ -221,6 +221,8 @@ int put_cmsg_compat(struct msghdr *kmsg, int level, int type, int len, void *dat
{
struct compat_cmsghdr __user *cm = (struct compat_cmsghdr __user *) kmsg->msg_control;
struct compat_cmsghdr cmhdr;
+ struct compat_timeval ctv;
+ struct compat_timespec cts[3];
int cmlen;
if (cm == NULL || kmsg->msg_controllen < sizeof(*cm)) {
@@ -229,8 +231,6 @@ int put_cmsg_compat(struct msghdr *kmsg, int level, int type, int len, void *dat
}
if (!COMPAT_USE_64BIT_TIME) {
- struct compat_timeval ctv;
- struct compat_timespec cts[3];
if (level == SOL_SOCKET && type == SCM_TIMESTAMP) {
struct timeval *tv = (struct timeval *)data;
ctv.tv_sec = tv->tv_sec;
--
1.7.11.2
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* Re: [PULL] vhost-net changes for net/3.6
From: Nicholas A. Bellinger @ 2012-07-22 20:34 UTC (permalink / raw)
To: David Miller
Cc: mst, netdev, linux-kernel, asias, pbonzini, stefanha, stefanha,
wuzhy, Greg KH
In-Reply-To: <20120722.121942.2002727319293471163.davem@davemloft.net>
Hi DaveM,
On Sun, 2012-07-22 at 12:19 -0700, David Miller wrote:
> From: "Michael S. Tsirkin" <mst@redhat.com>
> Date: Sun, 22 Jul 2012 01:54:36 +0300
>
> > The following changes since commit 186e868786f97c8026f0a81400b451ace306b3a4:
> >
> > forcedeth: spin_unlock_irq in interrupt handler fix (2012-07-20 16:18:36 -0700)
> >
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost-net-next
> >
> > for you to fetch changes up to 163049aefdc04323a2d17ec9f2862027b43b0502:
> >
> > vhost: make vhost work queue visible (2012-07-22 01:22:23 +0300)
>
> Pulled, thanks.
So target-pending/for-next-merge will need to be rebased once these bits
hit mainline for the tcm_vhost initial merge commit..
Just curious when your planning on sending out a -rc1 PULL request for
net-next..?
--nab
^ permalink raw reply
* Re: [PATCH RFC] tcp: use seqlock for all cached tcp_metrics
From: Julian Anastasov @ 2012-07-22 20:34 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20120722.123246.864281319907290494.davem@davemloft.net>
Hello,
On Sun, 22 Jul 2012, David Miller wrote:
> From: Julian Anastasov <ja@ssi.bg>
> Date: Sun, 22 Jul 2012 12:44:28 +0300
>
> > The ability to reclaim existing cache entries
> > requires metrics to be accessed with additional seqlock.
> > fastopen_cache tried to provide such locking for its values
> > but there is always the risk to access reclaimed entry.
>
> I basically claim that accidental use of reclaimed entries
> is completely harmless for everything other than fastopen.
>
> Therefore I do not advocate adding the new overhead and complexity for
> the non-fastopen cases. It should be a completely free, lockless, and
> synchornization free cache. If we read crap metrics, so be it, maybe
> the network dynamics changed to the same amount, and we would never
> know the different. Therefore, it doesn't really matter if we read
> crap values for these measurements.
OK, it seems I didn't understand you fully in previous
email. So, I can just send patch (or 2) for the tcpm_stamp and
tcp_tw_remember_stamp problems, now or after 2 weeks?
> Thanks.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* [PATCH] ppp: add 64 bit stats
From: Kevin Groeneveld @ 2012-07-22 20:19 UTC (permalink / raw)
To: netdev; +Cc: Kevin Groeneveld
Add 64 bit stats to ppp driver. The 64 bit stats include tx_bytes,
rx_bytes, tx_packets and rx_packets. Other stats are still 32 bit.
The 64 bit stats can be retrieved via the ndo_get_stats operation. The
SIOCGPPPSTATS ioctl is still 32 bit stats only.
Signed-off-by: Kevin Groeneveld <kgroeneveld@gmail.com>
---
drivers/net/ppp/ppp_generic.c | 110 +++++++++++++++++++++++++++++++++++------
1 file changed, 95 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
index 5c05572..210238c 100644
--- a/drivers/net/ppp/ppp_generic.c
+++ b/drivers/net/ppp/ppp_generic.c
@@ -94,6 +94,19 @@ struct ppp_file {
#define PF_TO_CHANNEL(pf) PF_TO_X(pf, struct channel)
/*
+ * Data structure to hold primary network stats for which
+ * we want to use 64 bit storage. Other network stats
+ * are stored in dev->stats of the ppp strucute.
+ */
+struct ppp_link_stats {
+ struct u64_stats_sync syncp;
+ u64 tx_bytes;
+ u64 tx_packets;
+ u64 rx_bytes;
+ u64 rx_packets;
+};
+
+/*
* Data structure describing one ppp unit.
* A ppp unit corresponds to a ppp network interface device
* and represents a multilink bundle.
@@ -136,6 +149,7 @@ struct ppp {
unsigned pass_len, active_len;
#endif /* CONFIG_PPP_FILTER */
struct net *ppp_net; /* the net we belong to */
+ struct ppp_link_stats __percpu *stats; /* 64 bit network stats */
};
/*
@@ -1021,9 +1035,45 @@ ppp_net_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
return err;
}
+struct rtnl_link_stats64*
+ppp_get_stats64(struct net_device *dev, struct rtnl_link_stats64 *tot)
+{
+ struct ppp *ppp = netdev_priv(dev);
+ int cpu;
+
+ for_each_possible_cpu(cpu) {
+ struct ppp_link_stats *stats = per_cpu_ptr(ppp->stats, cpu);
+ unsigned int start;
+ u64 rx_packets, rx_bytes, tx_packets, tx_bytes;
+
+ do {
+ start = u64_stats_fetch_begin_bh(&stats->syncp);
+ rx_packets = stats->rx_packets;
+ tx_packets = stats->tx_packets;
+ rx_bytes = stats->rx_bytes;
+ tx_bytes = stats->tx_bytes;
+
+ } while (u64_stats_fetch_retry_bh(&stats->syncp, start));
+
+ tot->rx_packets += rx_packets;
+ tot->tx_packets += tx_packets;
+ tot->rx_bytes += rx_bytes;
+ tot->tx_bytes += tx_bytes;
+ }
+
+ tot->rx_errors = dev->stats.rx_errors;
+ tot->tx_errors = dev->stats.tx_errors;
+ tot->rx_dropped = dev->stats.rx_dropped;
+ tot->tx_dropped = dev->stats.tx_dropped;
+ tot->rx_length_errors = dev->stats.rx_length_errors;
+
+ return tot;
+}
+
static const struct net_device_ops ppp_netdev_ops = {
- .ndo_start_xmit = ppp_start_xmit,
- .ndo_do_ioctl = ppp_net_ioctl,
+ .ndo_start_xmit = ppp_start_xmit,
+ .ndo_do_ioctl = ppp_net_ioctl,
+ .ndo_get_stats64 = ppp_get_stats64,
};
static void ppp_setup(struct net_device *dev)
@@ -1130,6 +1180,7 @@ ppp_send_frame(struct ppp *ppp, struct sk_buff *skb)
struct sk_buff *new_skb;
int len;
unsigned char *cp;
+ struct ppp_link_stats *stats = this_cpu_ptr(ppp->stats);
if (proto < 0x8000) {
#ifdef CONFIG_PPP_FILTER
@@ -1157,8 +1208,10 @@ ppp_send_frame(struct ppp *ppp, struct sk_buff *skb)
#endif /* CONFIG_PPP_FILTER */
}
- ++ppp->dev->stats.tx_packets;
- ppp->dev->stats.tx_bytes += skb->len - 2;
+ u64_stats_update_begin(&stats->syncp);
+ ++stats->tx_packets;
+ stats->tx_bytes += skb->len - 2;
+ u64_stats_update_end(&stats->syncp);
switch (proto) {
case PPP_IP:
@@ -1673,6 +1726,7 @@ ppp_receive_nonmp_frame(struct ppp *ppp, struct sk_buff *skb)
{
struct sk_buff *ns;
int proto, len, npi;
+ struct ppp_link_stats *stats = this_cpu_ptr(ppp->stats);
/*
* Decompress the frame, if compressed.
@@ -1745,8 +1799,10 @@ ppp_receive_nonmp_frame(struct ppp *ppp, struct sk_buff *skb)
break;
}
- ++ppp->dev->stats.rx_packets;
- ppp->dev->stats.rx_bytes += skb->len - 2;
+ u64_stats_update_begin(&stats->syncp);
+ ++stats->rx_packets;
+ stats->rx_bytes += skb->len - 2;
+ u64_stats_update_end(&stats->syncp);
npi = proto_to_npindex(proto);
if (npi < 0) {
@@ -2568,14 +2624,32 @@ static void
ppp_get_stats(struct ppp *ppp, struct ppp_stats *st)
{
struct slcompress *vj = ppp->vj;
+ int cpu;
memset(st, 0, sizeof(*st));
- st->p.ppp_ipackets = ppp->dev->stats.rx_packets;
+
+ for_each_possible_cpu(cpu) {
+ struct ppp_link_stats *stats = per_cpu_ptr(ppp->stats, cpu);
+ unsigned int start;
+ u64 rx_packets, rx_bytes, tx_packets, tx_bytes;
+
+ do {
+ start = u64_stats_fetch_begin_bh(&stats->syncp);
+ rx_packets = stats->rx_packets;
+ tx_packets = stats->tx_packets;
+ rx_bytes = stats->rx_bytes;
+ tx_bytes = stats->tx_bytes;
+
+ } while (u64_stats_fetch_retry_bh(&stats->syncp, start));
+
+ st->p.ppp_ipackets += rx_packets;
+ st->p.ppp_opackets += tx_packets;
+ st->p.ppp_ibytes += rx_bytes;
+ st->p.ppp_obytes += tx_bytes;
+ }
+
st->p.ppp_ierrors = ppp->dev->stats.rx_errors;
- st->p.ppp_ibytes = ppp->dev->stats.rx_bytes;
- st->p.ppp_opackets = ppp->dev->stats.tx_packets;
st->p.ppp_oerrors = ppp->dev->stats.tx_errors;
- st->p.ppp_obytes = ppp->dev->stats.tx_bytes;
if (!vj)
return;
st->vj.vjs_packets = vj->sls_o_compressed + vj->sls_o_uncompressed;
@@ -2627,6 +2701,9 @@ ppp_create_interface(struct net *net, int unit, int *retp)
ppp->minseq = -1;
skb_queue_head_init(&ppp->mrq);
#endif /* CONFIG_PPP_MULTILINK */
+ ppp->stats = alloc_percpu(struct ppp_link_stats);
+ if (ppp->stats == NULL)
+ goto out2;
/*
* drum roll: don't forget to set
@@ -2640,12 +2717,12 @@ ppp_create_interface(struct net *net, int unit, int *retp)
unit = unit_get(&pn->units_idr, ppp);
if (unit < 0) {
ret = unit;
- goto out2;
+ goto out3;
}
} else {
ret = -EEXIST;
if (unit_find(&pn->units_idr, unit))
- goto out2; /* unit already exists */
+ goto out3; /* unit already exists */
/*
* if caller need a specified unit number
* lets try to satisfy him, otherwise --
@@ -2657,7 +2734,7 @@ ppp_create_interface(struct net *net, int unit, int *retp)
*/
unit = unit_set(&pn->units_idr, ppp, unit);
if (unit < 0)
- goto out2;
+ goto out3;
}
/* Initialize the new ppp unit */
@@ -2669,7 +2746,7 @@ ppp_create_interface(struct net *net, int unit, int *retp)
unit_put(&pn->units_idr, unit);
netdev_err(ppp->dev, "PPP: couldn't register device %s (%d)\n",
dev->name, ret);
- goto out2;
+ goto out3;
}
ppp->ppp_net = net;
@@ -2680,8 +2757,10 @@ ppp_create_interface(struct net *net, int unit, int *retp)
*retp = 0;
return ppp;
-out2:
+out3:
mutex_unlock(&pn->all_ppp_mutex);
+ free_percpu(ppp->stats);
+out2:
free_netdev(dev);
out1:
*retp = ret;
@@ -2765,6 +2844,7 @@ static void ppp_destroy_interface(struct ppp *ppp)
kfree_skb(ppp->xmit_pending);
+ free_percpu(ppp->stats);
free_netdev(ppp->dev);
}
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v3 0/2] net: ethernet: davinci_emac: fixups + pm_runtime
From: David Miller @ 2012-07-22 19:46 UTC (permalink / raw)
To: mgreer; +Cc: netdev, linux-omap, linux-arm-kernel
In-Reply-To: <1342833562-3435-1-git-send-email-mgreer@animalcreek.com>
From: "Mark A. Greer" <mgreer@animalcreek.com>
Date: Fri, 20 Jul 2012 18:19:20 -0700
> From: "Mark A. Greer" <mgreer@animalcreek.com>
>
> This series fixes a compile error in, and adds pm_runtime support
> to, the davinci_emac driver.
>
> To test on a davinci platform, you will need another patch just
> submitted to netdev:
>
> http://marc.info/?l=linux-netdev&m=134282758408187&w=2
>
> Mark A. Greer (2):
> net: ethernet: davinci_emac: Remove unnecessary #include
> net: ethernet: davinci_emac: add pm_runtime support
All applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] sctp: Make "Invalid Stream Identifier" ERROR follows SACK when bundling
From: David Miller @ 2012-07-22 19:45 UTC (permalink / raw)
To: xufengzhang.main; +Cc: vyasevich, sri, linux-sctp, netdev, linux-kernel
In-Reply-To: <1342677450-21810-1-git-send-email-xufengzhang.main@gmail.com>
From: <xufengzhang.main@gmail.com>
Date: Thu, 19 Jul 2012 13:57:30 +0800
> When "Invalid Stream Identifier" ERROR happens after process the
> received DATA chunks, this ERROR chunk is enqueued into outqueue
> before SACK chunk, so when bundling ERROR chunk with SACK chunk,
> the ERROR chunk is always placed first in the packet because of
> the chunk's position in the outqueue.
> This violates sctp specification:
> RFC 4960 6.5. Stream Identifier and Stream Sequence Number
> ...The endpoint may bundle the ERROR chunk in the same
> packet as the SACK as long as the ERROR follows the SACK.
> So we must place SACK first when bundling "Invalid Stream Identifier"
> ERROR and SACK in one packet.
> Although we can do that by enqueue SACK chunk into outqueue before
> ERROR chunk, it will violate the side-effect interpreter processing.
> It's easy to do this job when dequeue chunks from the outqueue,
> by this way, we introduce a flag 'has_isi_err' which indicate
> whether or not the "Invalid Stream Identifier" ERROR happens.
>
> Signed-off-by: Xufeng Zhang <xufeng.zhang@windriver.com>
Can some SCTP experts please review this?
^ permalink raw reply
* Re: [net-next PATCH v1] net: netprio_cgroup: rework update socket logic
From: David Miller @ 2012-07-22 19:44 UTC (permalink / raw)
To: nhorman; +Cc: john.r.fastabend, netdev, eric.dumazet, gaofeng, lizefan
In-Reply-To: <20120721171854.GA6099@neilslaptop.think-freely.org>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Sat, 21 Jul 2012 13:18:55 -0400
> On Sat, Jul 21, 2012 at 10:02:03AM -0700, John Fastabend wrote:
>> On 7/20/2012 7:00 PM, Neil Horman wrote:
>> >On Fri, Jul 20, 2012 at 01:39:25PM -0700, John Fastabend wrote:
>> >>Instead of updating the sk_cgrp_prioidx struct field on every send
>> >>this only updates the field when a task is moved via cgroup
>> >>infrastructure.
>> >>
>> >>This allows sockets that may be used by a kernel worker thread
>> >>to be managed. For example in the iscsi case today a user can
>> >>put iscsid in a netprio cgroup and control traffic will be sent
>> >>with the correct sk_cgrp_prioidx value set but as soon as data
>> >>is sent the kernel worker thread isssues a send and sk_cgrp_prioidx
>> >>is updated with the kernel worker threads value which is the
>> >>default case.
>> >>
>> >>It seems more correct to only update the field when the user
>> >>explicitly sets it via control group infrastructure. This allows
>> >>the users to manage sockets that may be used with other threads.
>> >>
>> >>Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>> >I like the idea, but IIRC last time we tried this I think it caused problems
>> >with processes that shared sockets. That is to say, if you have a parent and
>> >child process that dup an socket descriptior, and put them in separate cgroups,
>> >you get unpredictable results, as the socket gets assigned a priority based on
>> >the last processed that moved cgroups.
>> >
>> >Neil
>> >
>>
>> Shared sockets creates strange behavior as it exists today. If a dup
>> of the socket fd is created the private data is still shared right. So
>> in this case the sk_cgrp_prioidx value is going to get updated by both
>> threads and then it is a race to see what it happens to be set to in
>> the xmit path.
>>
>> With this patch at least the behavior is deterministic. Without it
>> I can create the above scenario but have no way to determine what the
>> skb priority will actually be set to.
>>
>> .John
>>
> Ok, I can buy that. Lets give this a try:
>
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
>
Applied.
^ permalink raw reply
* Re: [PATCH] net-next: minor cleanups for bonding documentation
From: David Miller @ 2012-07-22 19:44 UTC (permalink / raw)
To: fubar; +Cc: raj, netdev, andy
In-Reply-To: <6272.1342829308@death.nxdomain>
From: Jay Vosburgh <fubar@us.ibm.com>
Date: Fri, 20 Jul 2012 17:08:28 -0700
> Rick Jones <raj@tardy.cup.hp.com> wrote:
>
>>From: Rick Jones <rick.jones2@hp.com>
>>
>>The section titled "Configuring Bonding for Maximum Throughput" is
>>actually section twelve not thirteen, and there are a couple of words
>>spelled incorrectly.
>>
>>Signed-off-by: Rick Jones <rick.jones2@hp.com>
>
> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH 00/16] Remove the ipv4 routing cache
From: David Miller @ 2012-07-22 19:42 UTC (permalink / raw)
To: subramanian.vijay; +Cc: netdev
In-Reply-To: <CAGK4HS_ZqH+std9Edbia7i1tdpLxpdsMD83fcTQPnNZbnX4zPA@mail.gmail.com>
From: Vijay Subramanian <subramanian.vijay@gmail.com>
Date: Sun, 22 Jul 2012 00:47:27 -0700
> I have been running your routing removal patches for the past 3 days
> (upgraded yesterday to latest set including the 17th patch you sent in
> response to Eric's comment) and have not seen any issues (crashes
> etc).
Thanks for testing.
> Apart from time spent in fib_table_lookup(), it seems time is also
> spent in check_leaf(). I assume this is expected behavior.
> Here are 2 sample perf outputs (I have appended the kbench outputs to
> each file)
Yes, the two biggest hogs will be fib_table_lookup() and check_leaf().
check_leaf() is expensive largely because that's where we write the
fib_result block, which is a structure on the fib_lookup() caller's
stack.
Your perf traces roughly approximate mine.
Thanks.
^ permalink raw reply
* Re: [PATCHv3 0/6] tun zerocopy support
From: David Miller @ 2012-07-22 19:40 UTC (permalink / raw)
To: mst; +Cc: jasowang, eric.dumazet, netdev, linux-kernel, ebiederm,
Ian.Campbell
In-Reply-To: <20120721220534.GA22912@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Sun, 22 Jul 2012 01:05:34 +0300
> I agree a small win in CPU use is nothing to write home about,
> I don't yet understand why the win is so small - macvtap has zero copy
> supported for a while and it has exactly same issues.
> I hope adding tun zerocopy support upstream will help us
> make progress faster and find the bottleneck, so far not many people use
> macvtap so zero copy mode there didn't make progress.
>
> I do know why local performance regresses with zero copy enabled:
> instead of plain copy to user we got get user pages and then memcpy.
> We'll need some logic here to detect this and turn off zero copy.
>
> The core patches will also be helpful for Ian's more ambitious work.
>
> Overall I think it's a step in the right direction and it's easier to
> work if core parts are upstream, but if you think we need to wait
> until the gains are more significant, I understand that too.
Ok, I've applied this series, let's see what happens.
^ permalink raw reply
* Re: [net-next 00/13][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2012-07-22 19:37 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <20120722.122405.1220712908232591030.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Sun, 22 Jul 2012 12:24:05 -0700 (PDT)
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Sat, 21 Jul 2012 16:08:49 -0700
>
>> This series contains updates to ixgbe and ixgbevf.
>>
>> The following are changes since commit 186e868786f97c8026f0a81400b451ace306b3a4:
>> forcedeth: spin_unlock_irq in interrupt handler fix
>> and are available in the git repository at:
>> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
>
> Pulled, thanks Jeff.
Can you guys actually build test this stuff?
====================
[PATCH] ixgbe: Fix build with PCI_IOV enabled.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index 47b2ce7..4fea871 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -236,7 +236,7 @@ void ixgbe_disable_sriov(struct ixgbe_adapter *adapter)
if (ixgbe_vfs_are_assigned(adapter)) {
e_dev_warn("Unloading driver while VFs are assigned - VFs will not be deallocated\n");
return;
-
+ }
/* disable iov and allow time for transactions to clear */
pci_disable_sriov(adapter->pdev);
#endif
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH net-next 0/4] Tx time stamp advertising for four drivers
From: David Miller @ 2012-07-22 19:33 UTC (permalink / raw)
To: richardcochran; +Cc: netdev
In-Reply-To: <cover.1342976654.git.richardcochran@gmail.com>
From: Richard Cochran <richardcochran@gmail.com>
Date: Sun, 22 Jul 2012 19:15:38 +0200
> This series updates the ethtool code for four drivers that recently
> add the skb_tx_timestamp hook. Since these drivers now support
> software transmit time stamps, let us also advertise this via ethtool.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH RFC] tcp: use seqlock for all cached tcp_metrics
From: David Miller @ 2012-07-22 19:32 UTC (permalink / raw)
To: ja; +Cc: netdev
In-Reply-To: <1342950268-2380-1-git-send-email-ja@ssi.bg>
From: Julian Anastasov <ja@ssi.bg>
Date: Sun, 22 Jul 2012 12:44:28 +0300
> The ability to reclaim existing cache entries
> requires metrics to be accessed with additional seqlock.
> fastopen_cache tried to provide such locking for its values
> but there is always the risk to access reclaimed entry.
I basically claim that accidental use of reclaimed entries
is completely harmless for everything other than fastopen.
Therefore I do not advocate adding the new overhead and complexity for
the non-fastopen cases. It should be a completely free, lockless, and
synchornization free cache. If we read crap metrics, so be it, maybe
the network dynamics changed to the same amount, and we would never
know the different. Therefore, it doesn't really matter if we read
crap values for these measurements.
Thanks.
^ permalink raw reply
* Re: [PATCH] rtnl: Add #ifdef CONFIG_RPS around num_rx_queues reference
From: David Miller @ 2012-07-22 19:28 UTC (permalink / raw)
To: mgreer; +Cc: netdev, jiri
In-Reply-To: <1342827313-2827-1-git-send-email-mgreer@animalcreek.com>
From: "Mark A. Greer" <mgreer@animalcreek.com>
Date: Fri, 20 Jul 2012 16:35:13 -0700
> From: "Mark A. Greer" <mgreer@animalcreek.com>
>
> Commit 76ff5cc91935c51fcf1a6a99ffa28b97a6e7a884
> (rtnl: allow to specify number of rx and tx queues
> on device creation) added a reference to the net_device
> structure's 'num_rx_queues' member in
>
> net/core/rtnetlink.c:rtnl_fill_ifinfo()
>
> However, the definition for 'num_rx_queues' is surrounded
> by an '#ifdef CONFIG_RPS' while the new reference to it is
> not. This causes a compile error when CONFIG_RPS is not
> defined.
>
> Fix the compile error by surrounding the new reference to
> 'num_rx_queues' by an '#ifdef CONFIG_RPS'.
>
> CC: Jiri Pirko <jiri@resnulli.us>
> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Applied, thanks Mark.
^ permalink raw reply
* Re: [patch net-next] rtnl: do not include num_rx_queues into msg when CONFIG_RPS is not set
From: David Miller @ 2012-07-22 19:27 UTC (permalink / raw)
To: jiri; +Cc: netdev, sfr
In-Reply-To: <1342942002-26731-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Sun, 22 Jul 2012 09:26:42 +0200
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Jiri, I've been patiently waiting for you to ACK Mark A. Greear's
patch fixing this bug, did you not see it at all?
http://patchwork.ozlabs.org/patch/172393/
I'm just going to apply it since you're not watching for fixes
for code you've changed.
^ permalink raw reply
* Re: [net-next 00/13][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2012-07-22 19:24 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1342912142-11130-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Sat, 21 Jul 2012 16:08:49 -0700
> This series contains updates to ixgbe and ixgbevf.
>
> The following are changes since commit 186e868786f97c8026f0a81400b451ace306b3a4:
> forcedeth: spin_unlock_irq in interrupt handler fix
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PULL] vhost-net changes for net/3.6
From: David Miller @ 2012-07-22 19:19 UTC (permalink / raw)
To: mst
Cc: netdev, linux-kernel, asias, nab, nab, pbonzini, stefanha,
stefanha, wuzhy
In-Reply-To: <20120721225436.GA23519@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Sun, 22 Jul 2012 01:54:36 +0300
> The following changes since commit 186e868786f97c8026f0a81400b451ace306b3a4:
>
> forcedeth: spin_unlock_irq in interrupt handler fix (2012-07-20 16:18:36 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost-net-next
>
> for you to fetch changes up to 163049aefdc04323a2d17ec9f2862027b43b0502:
>
> vhost: make vhost work queue visible (2012-07-22 01:22:23 +0300)
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH] wimax: fix printk format warnings
From: David Miller @ 2012-07-22 19:18 UTC (permalink / raw)
To: rdunlap; +Cc: netdev, geert, inaky.perez-gonzalez, linux-wimax, wimax, akpm
In-Reply-To: <500B170B.4000000@xenotime.net>
From: Randy Dunlap <rdunlap@xenotime.net>
Date: Sat, 21 Jul 2012 13:54:35 -0700
> From: Randy Dunlap <rdunlap@xenotime.net>
>
> Fix printk format warnings in drivers/net/wimax/i2400m:
>
> drivers/net/wimax/i2400m/control.c: warning: format '%zu' expects argument of type 'size_t', but argument 4 has type 'ssize_t' [-Wformat]
> drivers/net/wimax/i2400m/control.c: warning: format '%zu' expects argument of type 'size_t', but argument 5 has type 'ssize_t' [-Wformat]
> drivers/net/wimax/i2400m/usb-fw.c: warning: format '%zu' expects argument of type 'size_t', but argument 4 has type 'ssize_t' [-Wformat]
>
> I don't see these warnings on x86. The warnings that are quoted above
> are from Geert's kernel build reports.
>
> Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Applied, thanks Randy.
^ permalink raw reply
* Re: [PATCH v6] sctp: Implement quick failover draft from tsvwg
From: Neil Horman <nhorman@tuxdriver.com> @ 2012-07-22 19:18 UTC (permalink / raw)
To: David Miller, vyasevich; +Cc: netdev, sri, linux-sctp, joe
In-Reply-To: <20120722.121409.377271257112948379.davem@davemloft.net>
Thanks all!
David Miller <davem@davemloft.net> wrote:
>From: Vlad Yasevich <vyasevich@gmail.com>
>Date: Sun, 22 Jul 2012 14:18:12 -0400
>
>> Neil Horman <nhorman@tuxdriver.com> wrote:
>>
>>>I've seen several attempts recently made to do quick failover of sctp
>>>transports
>>>by reducing various retransmit timers and counters. While its
>possible
>>>to
>>>implement a faster failover on multihomed sctp associations, its not
>>>particularly robust, in that it can lead to unneeded retransmits, as
>>>well as
>>>false connection failures due to intermittent latency on a network.
>>>
>>>Instead, lets implement the new ietf quick failover draft found here:
>>>http://tools.ietf.org/html/draft-nishida-tsvwg-sctp-failover-05
>>>
>>>This will let the sctp stack identify transports that have had a
>small
>>>number of
>>>errors, and avoid using them quickly until their reliability can be
>>>re-established. I've tested this out on two virt guests connected
>via
>>>multiple
>>>isolated virt networks and believe its in compliance with the above
>>>draft and
>>>works well.
>>>
>>>Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> ...
>> Acked-by: Vlad Yasevich <vyasevich@gmail.com>
>
>Applied, thanks everyone.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
^ permalink raw reply
* Re: [PATCH v6] sctp: Implement quick failover draft from tsvwg
From: David Miller @ 2012-07-22 19:14 UTC (permalink / raw)
To: vyasevich; +Cc: nhorman, netdev, sri, linux-sctp, joe
In-Reply-To: <2e6ee3f1-ea4f-4c13-b27b-1f2291fdb0c0@email.android.com>
From: Vlad Yasevich <vyasevich@gmail.com>
Date: Sun, 22 Jul 2012 14:18:12 -0400
> Neil Horman <nhorman@tuxdriver.com> wrote:
>
>>I've seen several attempts recently made to do quick failover of sctp
>>transports
>>by reducing various retransmit timers and counters. While its possible
>>to
>>implement a faster failover on multihomed sctp associations, its not
>>particularly robust, in that it can lead to unneeded retransmits, as
>>well as
>>false connection failures due to intermittent latency on a network.
>>
>>Instead, lets implement the new ietf quick failover draft found here:
>>http://tools.ietf.org/html/draft-nishida-tsvwg-sctp-failover-05
>>
>>This will let the sctp stack identify transports that have had a small
>>number of
>>errors, and avoid using them quickly until their reliability can be
>>re-established. I've tested this out on two virt guests connected via
>>multiple
>>isolated virt networks and believe its in compliance with the above
>>draft and
>>works well.
>>
>>Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
...
> Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Applied, thanks everyone.
^ 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