* Re: Latency difference between fifo and pfifo_fast
From: Stephen Hemminger @ 2011-12-07 23:49 UTC (permalink / raw)
To: John A. Sullivan III
Cc: David Laight, netdev, Rick Jones, Dave Taht, Eric Dumazet
In-Reply-To: <88e4825e-4efe-4163-bb24-299a20aab66d@jasiiieee>
=
> > Is this a shared network? TOS won't matter if it is only your
> > traffic.
> >
> > There are number of route metrics that you can tweak to that can
> > reduce TCP slow
> > start effects, like increasing the initial cwnd, etc.
> >
> It is a private network dedicated only to SAN traffic - a couple of SAN devices and some virtualization hosts - John
Therefore unless your switch is shared, playing with queueing and TOS
won't help reduce absolute latency.
You maybe able to prioritize one host or SAN over another though.
^ permalink raw reply
* [PATCH net-next 0/2] be2net: Patch series
From: Ajit Khaparde @ 2011-12-07 23:44 UTC (permalink / raw)
To: netdev, davem
Patch series against net-next
Please apply
[1/2]: update some counters to display via ethtool
[2/2]: workaround to fix a BE bug
^ permalink raw reply
* [net-next PATCH 2/2] be2net: workaround to fix a BE bug
From: Ajit Khaparde @ 2011-12-07 23:44 UTC (permalink / raw)
To: netdev, davem
For vlan tagged pkts, BE
1) calculates checksum even when CSO is not requested
2) calculates checksum wrongly for padded pkt less than 60 bytes long.
As a workaround disable TX vlan offloading in such cases.
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
---
drivers/net/ethernet/emulex/benet/be.h | 16 ++++++++++++++
drivers/net/ethernet/emulex/benet/be_main.c | 30 +++++++++++++++++++-------
2 files changed, 38 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be.h b/drivers/net/ethernet/emulex/benet/be.h
index 34f162d..c4fcea69 100644
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@ -518,6 +518,22 @@ static inline void be_vf_eth_addr_generate(struct be_adapter *adapter, u8 *mac)
memcpy(mac, adapter->netdev->dev_addr, 3);
}
+static inline u16 be_get_tx_vlan_tag(struct be_adapter *adapter,
+ struct sk_buff *skb)
+{
+ u8 vlan_prio;
+ u16 vlan_tag;
+
+ vlan_tag = vlan_tx_tag_get(skb);
+ vlan_prio = (vlan_tag & VLAN_PRIO_MASK) >> VLAN_PRIO_SHIFT;
+ /* If vlan priority provided by OS is NOT in available bmap */
+ if (!(adapter->vlan_prio_bmap & (1 << vlan_prio)))
+ vlan_tag = (vlan_tag & ~VLAN_PRIO_MASK) |
+ adapter->recommended_prio;
+
+ return vlan_tag;
+}
+
static inline bool be_multi_rxq(const struct be_adapter *adapter)
{
return adapter->num_rx_qs > 1;
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index b29c447..c5c826f 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -555,8 +555,7 @@ static inline void wrb_fill(struct be_eth_wrb *wrb, u64 addr, int len)
static void wrb_fill_hdr(struct be_adapter *adapter, struct be_eth_hdr_wrb *hdr,
struct sk_buff *skb, u32 wrb_cnt, u32 len)
{
- u8 vlan_prio = 0;
- u16 vlan_tag = 0;
+ u16 vlan_tag;
memset(hdr, 0, sizeof(*hdr));
@@ -587,12 +586,7 @@ static void wrb_fill_hdr(struct be_adapter *adapter, struct be_eth_hdr_wrb *hdr,
if (vlan_tx_tag_present(skb)) {
AMAP_SET_BITS(struct amap_eth_hdr_wrb, vlan, hdr, 1);
- vlan_tag = vlan_tx_tag_get(skb);
- vlan_prio = (vlan_tag & VLAN_PRIO_MASK) >> VLAN_PRIO_SHIFT;
- /* If vlan priority provided by OS is NOT in available bmap */
- if (!(adapter->vlan_prio_bmap & (1 << vlan_prio)))
- vlan_tag = (vlan_tag & ~VLAN_PRIO_MASK) |
- adapter->recommended_prio;
+ vlan_tag = be_get_tx_vlan_tag(adapter, skb);
AMAP_SET_BITS(struct amap_eth_hdr_wrb, vlan_tag, hdr, vlan_tag);
}
@@ -695,6 +689,25 @@ static netdev_tx_t be_xmit(struct sk_buff *skb,
u32 start = txq->head;
bool dummy_wrb, stopped = false;
+ /* For vlan tagged pkts, BE
+ * 1) calculates checksum even when CSO is not requested
+ * 2) calculates checksum wrongly for padded pkt less than
+ * 60 bytes long.
+ * As a workaround disable TX vlan offloading in such cases.
+ */
+ if (unlikely(vlan_tx_tag_present(skb) &&
+ (skb->ip_summed != CHECKSUM_PARTIAL || skb->len <= 60))) {
+ skb = skb_share_check(skb, GFP_ATOMIC);
+ if (unlikely(!skb))
+ goto tx_drop;
+
+ skb = __vlan_put_tag(skb, be_get_tx_vlan_tag(adapter, skb));
+ if (unlikely(!skb))
+ goto tx_drop;
+
+ skb->vlan_tci = 0;
+ }
+
wrb_cnt = wrb_cnt_for_skb(adapter, skb, &dummy_wrb);
copied = make_tx_wrbs(adapter, txq, skb, wrb_cnt, dummy_wrb);
@@ -722,6 +735,7 @@ static netdev_tx_t be_xmit(struct sk_buff *skb,
txq->head = start;
dev_kfree_skb_any(skb);
}
+tx_drop:
return NETDEV_TX_OK;
}
--
1.7.5.4
^ permalink raw reply related
* [net-next PATCH 1/2] be2net: update some counters to display via ethtool
From: Ajit Khaparde @ 2011-12-07 23:44 UTC (permalink / raw)
To: netdev, davem
update pmem_fifo_overflow_drop, rx_priority_pause_frames counters.
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
---
drivers/net/ethernet/emulex/benet/be_main.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 7236280..b29c447 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -316,6 +316,8 @@ static void populate_be3_stats(struct be_adapter *adapter)
struct be_drv_stats *drvs = &adapter->drv_stats;
be_dws_le_to_cpu(hw_stats, sizeof(*hw_stats));
+ drvs->pmem_fifo_overflow_drop = port_stats->pmem_fifo_overflow_drop;
+ drvs->rx_priority_pause_frames = port_stats->rx_priority_pause_frames;
drvs->rx_pause_frames = port_stats->rx_pause_frames;
drvs->rx_crc_errors = port_stats->rx_crc_errors;
drvs->rx_control_frames = port_stats->rx_control_frames;
--
1.7.5.4
^ permalink raw reply related
* Re: v6: faster tree-based sysctl implementation
From: Eric W. Biederman @ 2011-12-08 0:19 UTC (permalink / raw)
To: Lucian Adrian Grijincu
Cc: Anca Emanuel, linux-kernel, netdev, Octavian Purdila,
David S . Miller, Alexey Dobriyan, Damien Millescamps,
Stephen Rothwell
In-Reply-To: <CAPLs8y-sc7CZw2Yb11A-jTEMmTYva==XHgCqK1UmWN6_HX0rfA@mail.gmail.com>
Lucian Adrian Grijincu <lucian.grijincu@gmail.com> writes:
> On Wed, Dec 7, 2011 at 2:08 AM, Anca Emanuel <anca.emanuel@gmail.com> wrote:
>> You can ask Stephen Rothwell to include your tree in next.
>> git://github.com/luciang/linux-2.6-new-sysctl.git v6-new-sysctl-alg
>
>
> Thank you Anca, but I don't want to pollute Stephen's linux-next tree ATM.
> I'd wait until a maintainer chimes in and agrees that this approach is
> sound.
Which is my cue to say that I am behind the power curve in reviewing
this. I will see if I can get to this before the end of the week.
Doing this and getting it right is definitely something we need to do.
We do need to be careful so that the code we wind up with is not just
faster but more maintainable than what we have today.
Thanks for still pushing this,
Eric
^ permalink raw reply
* Re: [PATCH] IPVS: Modify the SH scheduler to use weights
From: Simon Horman @ 2011-12-08 0:37 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Patrick McHardy, lvs-devel, netdev, netfilter-devel,
Wensong Zhang, Julian Anastasov, Michael Maxim
In-Reply-To: <20111207113038.GA18166@1984>
On Wed, Dec 07, 2011 at 12:30:38PM +0100, Pablo Neira Ayuso wrote:
> On Wed, Dec 07, 2011 at 05:07:03PM +0900, Simon Horman wrote:
> > From: Michael Maxim <mike@okcupid.com>
> >
> > Modify the algorithm to build the source hashing hash table to add
> > extra slots for destinations with higher weight. This has the effect
> > of allowing an IPVS SH user to give more connections to hosts that
> > have been configured to have a higher weight.
> >
> > Signed-off-by: Michael Maxim <mike@okcupid.com>
> > Signed-off-by: Simon Horman <horms@verge.net.au>
> > ---
> > net/netfilter/ipvs/Kconfig | 15 +++++++++++++++
> > net/netfilter/ipvs/ip_vs_sh.c | 20 ++++++++++++++++++--
> > 2 files changed, 33 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/netfilter/ipvs/Kconfig b/net/netfilter/ipvs/Kconfig
> > index 70bd1d0..af4c0b8 100644
> > --- a/net/netfilter/ipvs/Kconfig
> > +++ b/net/netfilter/ipvs/Kconfig
> > @@ -232,6 +232,21 @@ config IP_VS_NQ
> > If you want to compile it in kernel, say Y. To compile it as a
> > module, choose M here. If unsure, say N.
> >
> > +comment 'IPVS SH scheduler'
> > +
> > +config IP_VS_SH_TAB_BITS
> > + int "IPVS source hashing table size (the Nth power of 2)"
> > + range 4 20
> > + default 8
> > + ---help---
> > + The source hashing scheduler maps source IPs to destinations
> > + stored in a hash table. This table is tiled by each destination
> > + until all slots in the table are filled. When using weights to
> > + allow destinations to receive more connections, the table is
> > + tiled an amount proportional to the weights specified. The table
> > + needs to be large enough to effectively fit all the destinations
> > + multiplied by their respective weights.
>
> Hm, does this really belong to this patch?
It seemed reasonable to me, as it is related to the main purpose of
the patch. But I'm happy to split it out into a separate patch.
>
> > +
> > comment 'IPVS application helper'
> >
> > config IP_VS_FTP
> > diff --git a/net/netfilter/ipvs/ip_vs_sh.c b/net/netfilter/ipvs/ip_vs_sh.c
> > index 33815f4..e0ca520 100644
> > --- a/net/netfilter/ipvs/ip_vs_sh.c
> > +++ b/net/netfilter/ipvs/ip_vs_sh.c
> > @@ -30,6 +30,11 @@
> > * server is dead or overloaded, the load balancer can bypass the cache
> > * server and send requests to the original server directly.
> > *
> > + * The weight destination attribute can be used to control the
> > + * distribution of connections to the destinations in servernode. The
> > + * greater the weight, the more connections the destination
> > + * will receive.
> > + *
> > */
> >
> > #define KMSG_COMPONENT "IPVS"
> > @@ -99,9 +104,11 @@ ip_vs_sh_assign(struct ip_vs_sh_bucket *tbl, struct ip_vs_service *svc)
> > struct ip_vs_sh_bucket *b;
> > struct list_head *p;
> > struct ip_vs_dest *dest;
> > + int d_count;
> >
> > b = tbl;
> > p = &svc->destinations;
> > + d_count = 0;
> > for (i=0; i<IP_VS_SH_TAB_SIZE; i++) {
> > if (list_empty(p)) {
> > b->dest = NULL;
> > @@ -113,14 +120,23 @@ ip_vs_sh_assign(struct ip_vs_sh_bucket *tbl, struct ip_vs_service *svc)
> > atomic_inc(&dest->refcnt);
> > b->dest = dest;
> >
> > - p = p->next;
> > + IP_VS_DBG_BUF(6, "assigned i: %d dest: %s weight: %d\n",
> > + i, IP_VS_DBG_ADDR(svc->af, &dest->addr),
> > + atomic_read(&dest->weight));
> > +
> > + /* Don't move to next dest until filling weight */
> > + if (++d_count >= atomic_read(&dest->weight)) {
> > + p = p->next;
> > + d_count = 0;
> > + }
> > +
> > }
> > b++;
> > }
> > +
> > return 0;
> > }
> >
> > -
>
> While at it, would you remove this unnecessary deletions/additions.
Sure.
^ permalink raw reply
* Re: [PATCH] IPVS: Modify the SH scheduler to use weights
From: Simon Horman @ 2011-12-08 0:40 UTC (permalink / raw)
To: Mike Maxim
Cc: Pablo Neira Ayuso, Patrick McHardy, lvs-devel, netdev,
netfilter-devel, Wensong Zhang, Julian Anastasov
In-Reply-To: <CAOgH2dsHepr7Dyx7pNOutFNRh5SoO-oC9mx1MLm6Ncai8Ma3rQ@mail.gmail.com>
On Wed, Dec 07, 2011 at 10:24:09AM -0500, Mike Maxim wrote:
> The reason I put that in is because the size of that table becomes
> more relevant/important if you decide to use the weights in the manner
> the patch lets you. It would be conceivable that someone might need to
> increase the size of that table to accommodate their configuration, so
> I thought it would be handy to be able to do that through the regular
> configuration system instead of editing the source.
Hi Mike,
I agree, but I think its also reasonable to consider IP_VS_SH_TAB_BITS as
a separate change.
Could you
1. Split the patch into a Kconfig patch and a ip_vs_sh.c patch
2. Remove spurious line additions from the resulting patches?
>
> On Wed, Dec 7, 2011 at 6:30 AM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > On Wed, Dec 07, 2011 at 05:07:03PM +0900, Simon Horman wrote:
> >> From: Michael Maxim <mike@okcupid.com>
> >>
> >> Modify the algorithm to build the source hashing hash table to add
> >> extra slots for destinations with higher weight. This has the effect
> >> of allowing an IPVS SH user to give more connections to hosts that
> >> have been configured to have a higher weight.
> >>
> >> Signed-off-by: Michael Maxim <mike@okcupid.com>
> >> Signed-off-by: Simon Horman <horms@verge.net.au>
> >> ---
> >> net/netfilter/ipvs/Kconfig | 15 +++++++++++++++
> >> net/netfilter/ipvs/ip_vs_sh.c | 20 ++++++++++++++++++--
> >> 2 files changed, 33 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/net/netfilter/ipvs/Kconfig b/net/netfilter/ipvs/Kconfig
> >> index 70bd1d0..af4c0b8 100644
> >> --- a/net/netfilter/ipvs/Kconfig
> >> +++ b/net/netfilter/ipvs/Kconfig
> >> @@ -232,6 +232,21 @@ config IP_VS_NQ
> >> If you want to compile it in kernel, say Y. To compile it as a
> >> module, choose M here. If unsure, say N.
> >>
> >> +comment 'IPVS SH scheduler'
> >> +
> >> +config IP_VS_SH_TAB_BITS
> >> + int "IPVS source hashing table size (the Nth power of 2)"
> >> + range 4 20
> >> + default 8
> >> + ---help---
> >> + The source hashing scheduler maps source IPs to destinations
> >> + stored in a hash table. This table is tiled by each destination
> >> + until all slots in the table are filled. When using weights to
> >> + allow destinations to receive more connections, the table is
> >> + tiled an amount proportional to the weights specified. The table
> >> + needs to be large enough to effectively fit all the destinations
> >> + multiplied by their respective weights.
> >
> > Hm, does this really belong to this patch?
> >
> >> +
> >> comment 'IPVS application helper'
> >>
> >> config IP_VS_FTP
> >> diff --git a/net/netfilter/ipvs/ip_vs_sh.c b/net/netfilter/ipvs/ip_vs_sh.c
> >> index 33815f4..e0ca520 100644
> >> --- a/net/netfilter/ipvs/ip_vs_sh.c
> >> +++ b/net/netfilter/ipvs/ip_vs_sh.c
> >> @@ -30,6 +30,11 @@
> >> * server is dead or overloaded, the load balancer can bypass the cache
> >> * server and send requests to the original server directly.
> >> *
> >> + * The weight destination attribute can be used to control the
> >> + * distribution of connections to the destinations in servernode. The
> >> + * greater the weight, the more connections the destination
> >> + * will receive.
> >> + *
> >> */
> >>
> >> #define KMSG_COMPONENT "IPVS"
> >> @@ -99,9 +104,11 @@ ip_vs_sh_assign(struct ip_vs_sh_bucket *tbl, struct ip_vs_service *svc)
> >> struct ip_vs_sh_bucket *b;
> >> struct list_head *p;
> >> struct ip_vs_dest *dest;
> >> + int d_count;
> >>
> >> b = tbl;
> >> p = &svc->destinations;
> >> + d_count = 0;
> >> for (i=0; i<IP_VS_SH_TAB_SIZE; i++) {
> >> if (list_empty(p)) {
> >> b->dest = NULL;
> >> @@ -113,14 +120,23 @@ ip_vs_sh_assign(struct ip_vs_sh_bucket *tbl, struct ip_vs_service *svc)
> >> atomic_inc(&dest->refcnt);
> >> b->dest = dest;
> >>
> >> - p = p->next;
> >> + IP_VS_DBG_BUF(6, "assigned i: %d dest: %s weight: %d\n",
> >> + i, IP_VS_DBG_ADDR(svc->af, &dest->addr),
> >> + atomic_read(&dest->weight));
> >> +
> >> + /* Don't move to next dest until filling weight */
> >> + if (++d_count >= atomic_read(&dest->weight)) {
> >> + p = p->next;
> >> + d_count = 0;
> >> + }
> >> +
> >> }
> >> b++;
> >> }
> >> +
> >> return 0;
> >> }
> >>
> >> -
> >
> > While at it, would you remove this unnecessary deletions/additions.
> >
> > Thanks!
> --
> To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] IPVS: Modify the SH scheduler to use weights
From: Pablo Neira Ayuso @ 2011-12-08 0:49 UTC (permalink / raw)
To: Mike Maxim
Cc: Simon Horman, Patrick McHardy, lvs-devel, netdev, netfilter-devel,
Wensong Zhang, Julian Anastasov
In-Reply-To: <CAOgH2dsHepr7Dyx7pNOutFNRh5SoO-oC9mx1MLm6Ncai8Ma3rQ@mail.gmail.com>
On Wed, Dec 07, 2011 at 10:24:09AM -0500, Mike Maxim wrote:
> The reason I put that in is because the size of that table becomes
> more relevant/important if you decide to use the weights in the manner
> the patch lets you. It would be conceivable that someone might need to
> increase the size of that table to accommodate their configuration, so
> I thought it would be handy to be able to do that through the regular
> configuration system instead of editing the source.
That explains that chunk.
Would you mind resubmitting the patch including this description in the
patch and removing the unnecessary line deletion / addition?
Thanks!
^ permalink raw reply
* Re: [PATCH] ipv6: Fix for adding multicast route for loopback device automatically.
From: Li Wei @ 2011-12-08 0:58 UTC (permalink / raw)
To: David Miller; +Cc: netdev, yoshfuji
In-Reply-To: <20111207.150615.181825066035193136.davem@davemloft.net>
David Miller wrote:
> From: Li Wei <lw@cn.fujitsu.com>
> Date: Wed, 07 Dec 2011 15:23:45 +0800
>
>> There is no obvious reason to add a default multicast route for loopback
>> devices, otherwise there would be a route entry whose dst.error set to
>> -ENETUNREACH that would blocking all multicast packets.
>>
>> Signed-off-by: Li Wei <lw@cn.fujitsu.com>
>
> I still do not understand the purpose of this change, what problems
> does the current behavior cause?
Hi, David, thank you for your comment.
The problem is that the resulting routing table depends on the sequence
of interface's initialization and in some situation, that would block all
muticast packets. Suppose there are two interfaces on my computer
(lo and eth0), if we initailize 'lo' before 'eth0', the resuting routing
table(for multicast) would be
# ip -6 route show | grep ff00::
unreachable ff00::/8 dev lo metric 256 error -101
ff00::/8 dev eth0 metric 256
When sending multicasting packets, routing subsystem will return the first
route entry which with a error set to -101(ENETUNREACH).
I know the kernel will set the default ipv6 address for 'lo' when it is up
and won't set the default multicast route for it, but there is no reason to
stop 'init' program from setting address for 'lo', and that is exactly what
systemd did.
I am sure there is something wrong with kernel or systemd, currently I preferred
kernel caused this problem.
>
> And can you be sure that by making this change, you are not breaking
> something, somewhere, that depends upon the current behavior?
>
>
I can't see there is any reason to set a default multicast route for loopback device
*automatically*.
Thanks,
Wei
^ permalink raw reply
* Re: [PATCH] IPVS: Modify the SH scheduler to use weights
From: Simon Horman @ 2011-12-08 1:11 UTC (permalink / raw)
To: Mike Maxim
Cc: Pablo Neira Ayuso, Patrick McHardy, lvs-devel, netdev,
netfilter-devel, Wensong Zhang, Julian Anastasov
In-Reply-To: <20111208004008.GD4586@verge.net.au>
On Thu, Dec 08, 2011 at 09:40:09AM +0900, Simon Horman wrote:
> On Wed, Dec 07, 2011 at 10:24:09AM -0500, Mike Maxim wrote:
> > The reason I put that in is because the size of that table becomes
> > more relevant/important if you decide to use the weights in the manner
> > the patch lets you. It would be conceivable that someone might need to
> > increase the size of that table to accommodate their configuration, so
> > I thought it would be handy to be able to do that through the regular
> > configuration system instead of editing the source.
>
> Hi Mike,
>
> I agree, but I think its also reasonable to consider IP_VS_SH_TAB_BITS as
> a separate change.
>
> Could you
>
> 1. Split the patch into a Kconfig patch and a ip_vs_sh.c patch
> 2. Remove spurious line additions from the resulting patches?
Scratch that, please follow Pablo's request.
^ permalink raw reply
* Urgent Part-Time Workers Needed (Position: FINANACIAL COORDINATOR IN CANADA FOR CHINA STEEL COMPANY)
From: China Steel Corporation (CSC) @ 2011-12-08 1:13 UTC (permalink / raw)
--
Hello:
This is to inform you that our company China Steel Corporation (CSC)
are
in urgent need for a financial coordinator in your region and this is a
part time job and it pays very well.
If you are interested kindly get back to us on :
chinasteelcorporationfirm@w.cn with the details below for more
information
to resume with us.
1. Full Names:
2. Full Address: (Including city, state and zip code)
3. Telephone:
4. Occupation:
Thanks for your interest.
Thank You,
Sincerely Yours,
Chang
^ permalink raw reply
* Re: [PATCH net-next] remove an outdated reference to T/TCP
From: Yuchung Cheng @ 2011-12-08 2:00 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, rick.jones2, netdev
In-Reply-To: <1323248287.2690.41.camel@edumazet-laptop>
On Wed, Dec 7, 2011 at 12:58 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mardi 06 décembre 2011 à 15:00 -0800, Yuchung Cheng a écrit :
>
>> I am fine keeping the comment as is. This does remind me to put more
>> comments on this part of the code in our upcoming Fast Open patch :)
>
> This sounds great.
>
> Is TFO patch using inetpeer cache to store cookies ?
>
> (I ask this because TFO paper I read mentions linux-2.6.34, I presume
> you couldnt use inetpeer at that time since it was IPv4 only)
Very interesting! I didn't know inetpeer cache earlier so we implement
own. duh! I will certainly look into it. Thanks for this tip.
From the surface, it does not seem too difficult to extend inetpeer for IPv6?
Yuchung
^ permalink raw reply
* Re: [Patch V2 ] net: doc: cleanup Documentation/networking/scaling.txt
From: Shan Wei @ 2011-12-08 2:03 UTC (permalink / raw)
To: David Miller
Cc: rdunlap, willemb, benjamin.poirier, therbert, linux-doc, netdev
In-Reply-To: <20111207.134055.2237590951177376531.davem@davemloft.net>
David Miller said, at 2011/12/8 2:40:
> I don't know if it's the encoding you use or something else but you
> must fix this before submitting any more patches.
Indeed, used default encoding of GB2312, now change it to UTF-8
according to email-clients.txt and resubmit this patch.
[PATCH v3] net: doc: cleanup Documentation/networking/scaling.txt
1) Fix some typos.
2) Change mode of the punctuation from full to half, eg.’,“ .
So that the punctuation can be read at console.
Signed-off-by: Shan Wei <shanwei88@gmail.com>
---
Documentation/networking/scaling.txt | 26 +++++++++++++-------------
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/Documentation/networking/scaling.txt b/Documentation/networking/scaling.txt
index a177de2..1215fcc 100644
--- a/Documentation/networking/scaling.txt
+++ b/Documentation/networking/scaling.txt
@@ -26,7 +26,7 @@ queues to distribute processing among CPUs. The NIC distributes packets by
applying a filter to each packet that assigns it to one of a small number
of logical flows. Packets for each flow are steered to a separate receive
queue, which in turn can be processed by separate CPUs. This mechanism is
-generally known as “Receive-side Scaling” (RSS). The goal of RSS and
+generally known as "Receive-side Scaling" (RSS). The goal of RSS and
the other scaling techniques is to increase performance uniformly.
Multi-queue distribution can also be used for traffic prioritization, but
that is not the focus of these techniques.
@@ -42,7 +42,7 @@ indirection table and reading the corresponding value.
Some advanced NICs allow steering packets to queues based on
programmable filters. For example, webserver bound TCP port 80 packets
-can be directed to their own receive queue. Such “n-tuple” filters can
+can be directed to their own receive queue. Such "n-tuple" filters can
be configured from ethtool (--config-ntuple).
==== RSS Configuration
@@ -104,7 +104,7 @@ RSS. Being in software, it is necessarily called later in the datapath.
Whereas RSS selects the queue and hence CPU that will run the hardware
interrupt handler, RPS selects the CPU to perform protocol processing
above the interrupt handler. This is accomplished by placing the packet
-on the desired CPU’s backlog queue and waking up the CPU for processing.
+on the desired CPU's backlog queue and waking up the CPU for processing.
RPS has some advantages over RSS: 1) it can be used with any NIC,
2) software filters can easily be added to hash over new protocols,
3) it does not increase hardware device interrupt rate (although it does
@@ -116,20 +116,20 @@ netif_receive_skb(). These call the get_rps_cpu() function, which
selects the queue that should process a packet.
The first step in determining the target CPU for RPS is to calculate a
-flow hash over the packet’s addresses or ports (2-tuple or 4-tuple hash
+flow hash over the packet's addresses or ports (2-tuple or 4-tuple hash
depending on the protocol). This serves as a consistent hash of the
associated flow of the packet. The hash is either provided by hardware
or will be computed in the stack. Capable hardware can pass the hash in
the receive descriptor for the packet; this would usually be the same
hash used for RSS (e.g. computed Toeplitz hash). The hash is saved in
skb->rx_hash and can be used elsewhere in the stack as a hash of the
-packet’s flow.
+packet's flow.
Each receive hardware queue has an associated list of CPUs to which
RPS may enqueue packets for processing. For each received packet,
an index into the list is computed from the flow hash modulo the size
of the list. The indexed CPU is the target for processing the packet,
-and the packet is queued to the tail of that CPU’s backlog queue. At
+and the packet is queued to the tail of that CPU's backlog queue. At
the end of the bottom half routine, IPIs are sent to any CPUs for which
packets have been queued to their backlog queue. The IPI wakes backlog
processing on the remote CPU, and any queued packets are then processed
@@ -208,7 +208,7 @@ The counter in rps_dev_flow_table values records the length of the current
CPU's backlog when a packet in this flow was last enqueued. Each backlog
queue has a head counter that is incremented on dequeue. A tail counter
is computed as head counter + queue length. In other words, the counter
-in rps_dev_flow_table[i] records the last element in flow i that has
+in rps_dev_flow[i] records the last element in flow i that has
been enqueued onto the currently designated CPU for flow i (of course,
entry i is actually selected by hash and multiple flows may hash to the
same entry i).
@@ -218,13 +218,13 @@ CPU for packet processing (from get_rps_cpu()) the rps_sock_flow table
and the rps_dev_flow table of the queue that the packet was received on
are compared. If the desired CPU for the flow (found in the
rps_sock_flow table) matches the current CPU (found in the rps_dev_flow
-table), the packet is enqueued onto that CPU’s backlog. If they differ,
+table), the packet is enqueued onto that CPU's backlog. If they differ,
the current CPU is updated to match the desired CPU if one of the
following is true:
- The current CPU's queue head counter >= the recorded tail counter
value in rps_dev_flow[i]
-- The current CPU is unset (equal to NR_CPUS)
+- The current CPU is unset (equal to RPS_NO_CPU)
- The current CPU is offline
After this check, the packet is sent to the (possibly updated) current
@@ -235,7 +235,7 @@ CPU.
==== RFS Configuration
-RFS is only available if the kconfig symbol CONFIG_RFS is enabled (on
+RFS is only available if the kconfig symbol CONFIG_RPS is enabled (on
by default for SMP). The functionality remains disabled until explicitly
configured. The number of entries in the global flow table is set through:
@@ -258,7 +258,7 @@ For a single queue device, the rps_flow_cnt value for the single queue
would normally be configured to the same value as rps_sock_flow_entries.
For a multi-queue device, the rps_flow_cnt for each queue might be
configured as rps_sock_flow_entries / N, where N is the number of
-queues. So for instance, if rps_flow_entries is set to 32768 and there
+queues. So for instance, if rps_sock_flow_entries is set to 32768 and there
are 16 configured receive queues, rps_flow_cnt for each queue might be
configured as 2048.
@@ -272,7 +272,7 @@ the application thread consuming the packets of each flow is running.
Accelerated RFS should perform better than RFS since packets are sent
directly to a CPU local to the thread consuming the data. The target CPU
will either be the same CPU where the application runs, or at least a CPU
-which is local to the application thread’s CPU in the cache hierarchy.
+which is local to the application thread's CPU in the cache hierarchy.
To enable accelerated RFS, the networking stack calls the
ndo_rx_flow_steer driver function to communicate the desired hardware
@@ -285,7 +285,7 @@ The hardware queue for a flow is derived from the CPU recorded in
rps_dev_flow_table. The stack consults a CPU to hardware queue map which
is maintained by the NIC driver. This is an auto-generated reverse map of
the IRQ affinity table shown by /proc/interrupts. Drivers can use
-functions in the cpu_rmap (“CPU affinity reverse map”) kernel library
+functions in the cpu_rmap ("CPU affinity reverse map") kernel library
to populate the map. For each CPU, the corresponding queue in the map is
set to be one whose processing CPU is closest in cache locality.
--
1.7.1
^ permalink raw reply related
* Re: Latency difference between fifo and pfifo_fast
From: John A. Sullivan III @ 2011-12-08 3:20 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David Laight, netdev, Rick Jones, Dave Taht, Eric Dumazet
In-Reply-To: <20111207154907.462846cb@nehalam.linuxnetplumber.net>
----- Original Message -----
> From: "Stephen Hemminger" <shemminger@vyatta.com>
> To: "John A. Sullivan III" <jsullivan@opensourcedevel.com>
> Cc: "David Laight" <David.Laight@ACULAB.COM>, netdev@vger.kernel.org, "Rick Jones" <rick.jones2@hp.com>, "Dave Taht"
> <dave.taht@gmail.com>, "Eric Dumazet" <eric.dumazet@gmail.com>
> Sent: Wednesday, December 7, 2011 6:49:07 PM
> Subject: Re: Latency difference between fifo and pfifo_fast
>
> =
> > > Is this a shared network? TOS won't matter if it is only your
> > > traffic.
> > >
> > > There are number of route metrics that you can tweak to that can
> > > reduce TCP slow
> > > start effects, like increasing the initial cwnd, etc.
> > >
> > It is a private network dedicated only to SAN traffic - a couple of
> > SAN devices and some virtualization hosts - John
>
> Therefore unless your switch is shared, playing with queueing and TOS
> won't help reduce absolute latency.
> You maybe able to prioritize one host or SAN over another though.
>
That's why I was wondering if we should switch to fifo from pfifo_fast since there is no prioritization of one host or SAN over another. Thanks - John
^ permalink raw reply
* (unknown),
From: Master Card E-mail Promotion @ 2011-12-08 1:55 UTC (permalink / raw)
Master card No: 5148 6547 8940 6543
REGISTRATION NO: 9027640
INSURANCE NO: MSTC006
TAX CLEARANCE NO: 28456
Your company or your personal e-mail address, has brought you an
unexpected luck,a lump sums pay out of £6,000,600.00, SIX MILLION, SIX
HUNDRED THOUSAND POUNDS. Equivalent to,($10,464,000 USD),Ten Million, four
hundred and sixty four thousand US Dollars.Do email the above Claims
Administrator,at once with all the claims requirements,below.To avoid
unnecessary delay.
1.Full Name:2.Address:3. Nationality:4. Age:5.Occupation:6.Phone:7.State
of Origin:.Country:
Claims Administrator
Name: Mr.Leonard Jesse Jr
E-mail;leonard.jjr02@hotmail.com
^ permalink raw reply
* Re: [PATCH] ipip, sit: copy parms.name after register_netdevice
From: Ted Feng @ 2011-12-08 3:35 UTC (permalink / raw)
To: David S. Miller; +Cc: Jiri Pirko, Josh Boyer, netdev, linux-kernel
In-Reply-To: <20111206173220.GA28763@kroah.com>
From: Ted Feng <artisdom@gmail.com>
Same fix as 731abb9cb2 for ipip and sit tunnel.
Commit 1c5cae815d removed an explicit call to dev_alloc_name in
ipip_tunnel_locate and ipip6_tunnel_locate, because register_netdevice
will now create a valid name. However the tunnel keeps a copy of the
name in the private parms structure.
This shows up if you do a simple tunnel add, followed by a tunnel show:
$ sudo ip tunnel add mode ipip remote 10.2.20.211
$ ip tunnel
tunl0: ip/ip remote any local any ttl inherit nopmtudisc
tunl%d: ip/ip remote 10.2.20.211 local any ttl inherit
$ sudo ip tunnel add mode sit remote 10.2.20.212
$ ip tunnel
sit0: ipv6/ip remote any local any ttl 64 nopmtudisc 6rd-prefix 2002::/16
sit%d: ioctl 89f8 failed: No such device
sit%d: ipv6/ip remote 10.2.20.212 local any ttl inherit
Fix this by copying the name back after register_netdevice has
successfully returned.
Cc: stable@vger.kernel.org
Signed-off-by: Ted Feng <artisdom@gmail.com>
---
net/ipv4/ipip.c | 7 ++++++-
net/ipv6/sit.c | 7 ++++++-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c
index 065effd..0b2e732 100644
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -285,6 +285,8 @@ static struct ip_tunnel *
ipip_tunnel_locate(struct net *net,
if (register_netdevice(dev) < 0)
goto failed_free;
+ strcpy(nt->parms.name, dev->name);
+
dev_hold(dev);
ipip_tunnel_link(ipn, nt);
return nt;
@@ -759,7 +761,6 @@ static int ipip_tunnel_init(struct net_device *dev)
struct ip_tunnel *tunnel = netdev_priv(dev);
tunnel->dev = dev;
- strcpy(tunnel->parms.name, dev->name);
memcpy(dev->dev_addr, &tunnel->parms.iph.saddr, 4);
memcpy(dev->broadcast, &tunnel->parms.iph.daddr, 4);
@@ -825,6 +826,7 @@ static void ipip_destroy_tunnels(struct ipip_net
*ipn, struct list_head *head)
static int __net_init ipip_init_net(struct net *net)
{
struct ipip_net *ipn = net_generic(net, ipip_net_id);
+ struct ip_tunnel *t;
int err;
ipn->tunnels[0] = ipn->tunnels_wc;
@@ -848,6 +850,9 @@ static int __net_init ipip_init_net(struct net *net)
if ((err = register_netdev(ipn->fb_tunnel_dev)))
goto err_reg_dev;
+ t = netdev_priv(ipn->fb_tunnel_dev);
+
+ strcpy(t->parms.name, ipn->fb_tunnel_dev->name);
return 0;
err_reg_dev:
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index a7a1860..96f3623 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -263,6 +263,8 @@ static struct ip_tunnel
*ipip6_tunnel_locate(struct net *net,
if (register_netdevice(dev) < 0)
goto failed_free;
+ strcpy(nt->parms.name, dev->name);
+
dev_hold(dev);
ipip6_tunnel_link(sitn, nt);
@@ -1144,7 +1146,6 @@ static int ipip6_tunnel_init(struct net_device *dev)
struct ip_tunnel *tunnel = netdev_priv(dev);
tunnel->dev = dev;
- strcpy(tunnel->parms.name, dev->name);
memcpy(dev->dev_addr, &tunnel->parms.iph.saddr, 4);
memcpy(dev->broadcast, &tunnel->parms.iph.daddr, 4);
@@ -1207,6 +1208,7 @@ static void __net_exit
sit_destroy_tunnels(struct sit_net *sitn, struct list_hea
static int __net_init sit_init_net(struct net *net)
{
struct sit_net *sitn = net_generic(net, sit_net_id);
+ struct ip_tunnel *t;
int err;
sitn->tunnels[0] = sitn->tunnels_wc;
@@ -1231,6 +1233,9 @@ static int __net_init sit_init_net(struct net *net)
if ((err = register_netdev(sitn->fb_tunnel_dev)))
goto err_reg_dev;
+ t = netdev_priv(sitn->fb_tunnel_dev);
+
+ strcpy(t->parms.name, sitn->fb_tunnel_dev->name);
return 0;
err_reg_dev:
^ permalink raw reply related
* Re: [Patch V2 ] net: doc: cleanup Documentation/networking/scaling.txt
From: Ben Hutchings @ 2011-12-08 4:01 UTC (permalink / raw)
To: Shan Wei
Cc: David Miller, rdunlap, willemb, benjamin.poirier, therbert,
linux-doc, netdev
In-Reply-To: <4EE01B0B.2050900@gmail.com>
On Thu, 2011-12-08 at 10:03 +0800, Shan Wei wrote:
> David Miller said, at 2011/12/8 2:40:
>
> > I don't know if it's the encoding you use or something else but you
> > must fix this before submitting any more patches.
>
>
> Indeed, used default encoding of GB2312, now change it to UTF-8
> according to email-clients.txt and resubmit this patch.
>
>
> [PATCH v3] net: doc: cleanup Documentation/networking/scaling.txt
>
> 1) Fix some typos.
> 2) Change mode of the punctuation from full to half, eg.’,“ .
> So that the punctuation can be read at console.
[...]
UTF-8 is the standard character encoding under Linux and those quotes
will be displayed correctly on most Linux terminals today. If you must
set your terminal to some other encoding you can use e.g.:
recode UTF-8 < Documentation/networking/scaling.txt | less
(Be sure to use redirection, otherwise recode will modify the file.)
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] ipip, sit: copy parms.name after register_netdevice
From: Stephen Hemminger @ 2011-12-08 4:16 UTC (permalink / raw)
To: Ted Feng; +Cc: David S. Miller, Jiri Pirko, Josh Boyer, netdev, linux-kernel
In-Reply-To: <CAM7b5hyXkRTUwnE-NwXEff-34WjRfMSBDf2itMVhdJGi4XoA=g@mail.gmail.com>
On Thu, 8 Dec 2011 11:35:15 +0800
Ted Feng <artisdom@gmail.com> wrote:
> From: Ted Feng <artisdom@gmail.com>
> Same fix as 731abb9cb2 for ipip and sit tunnel.
> Commit 1c5cae815d removed an explicit call to dev_alloc_name in
> ipip_tunnel_locate and ipip6_tunnel_locate, because register_netdevice
> will now create a valid name. However the tunnel keeps a copy of the
> name in the private parms structure.
>
> This shows up if you do a simple tunnel add, followed by a tunnel show:
>
Ok, but keeping a private copy is not a good idea, since tunnel
can be renamed.
ip li set dev tun0 name tunnel-of-love
^ permalink raw reply
* Re: [PATCH RFC] virtio_net: fix refill related races
From: Rusty Russell @ 2011-12-08 4:37 UTC (permalink / raw)
To: Michael S. Tsirkin, Amit Shah
Cc: netdev, virtualization, linux-kernel, Michael S. Tsirkin
In-Reply-To: <20111207152120.GA23417@redhat.com>
On Wed, 7 Dec 2011 17:21:22 +0200, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> Fix theoretical races related to refill work:
> 1. After napi is disabled by ndo_stop, refill work
> can run and re-enable it.
> 2. Refill can reschedule itself, if this happens
> it can run after cancel_delayed_work_sync,
> and will access device after it is destroyed.
>
> As a solution, add flags to track napi state and
> to disable refill, and toggle them on start, stop
> and remove; check these flags on refill.
Why isn't a "dont-readd" flag sufficient?
Cheers,
Rusty.
^ permalink raw reply
* Re: [PATCH] ipip, sit: copy parms.name after register_netdevice
From: David Miller @ 2011-12-08 4:56 UTC (permalink / raw)
To: artisdom; +Cc: jpirko, jwboyer, netdev, linux-kernel
In-Reply-To: <CAM7b5hyXkRTUwnE-NwXEff-34WjRfMSBDf2itMVhdJGi4XoA=g@mail.gmail.com>
From: Ted Feng <artisdom@gmail.com>
Date: Thu, 8 Dec 2011 11:35:15 +0800
> @@ -285,6 +285,8 @@ static struct ip_tunnel *
> ipip_tunnel_locate(struct net *net,
Your patches are corrupted by your email client and unusable.
^ permalink raw reply
* Re: [net-next PATCH 2/2] be2net: workaround to fix a BE bug
From: David Miller @ 2011-12-08 5:00 UTC (permalink / raw)
To: ajit.khaparde; +Cc: netdev
In-Reply-To: <20111207234424.GA2385@akhaparde-VBox>
From: Ajit Khaparde <ajit.khaparde@Emulex.Com>
Date: Wed, 7 Dec 2011 17:44:24 -0600
> For vlan tagged pkts, BE
> 1) calculates checksum even when CSO is not requested
> 2) calculates checksum wrongly for padded pkt less than 60 bytes long.
> As a workaround disable TX vlan offloading in such cases.
...
> + /* For vlan tagged pkts, BE
> + * 1) calculates checksum even when CSO is not requested
> + * 2) calculates checksum wrongly for padded pkt less than
> + * 60 bytes long.
> + * As a workaround disable TX vlan offloading in such cases.
> + */
This description either belongs in the commit message, or this
comment, but not both.
> + if (unlikely(vlan_tx_tag_present(skb) &&
> + (skb->ip_summed != CHECKSUM_PARTIAL || skb->len <= 60))) {
Poorly formatted, the second line openning first non-space character
needs to line up precisely after the first column after the if() statements
openning parenthesis.
If you cannot do this yourself by hand, use something like emacs's
C-mode to do it automatically for you when you hit TAB on that
second line.
^ permalink raw reply
* Re: [net-next PATCH 2/2] be2net: workaround to fix a BE bug
From: Joe Perches @ 2011-12-08 5:07 UTC (permalink / raw)
To: David Miller; +Cc: ajit.khaparde, netdev
In-Reply-To: <20111208.000044.1859009201427703594.davem@davemloft.net>
On Thu, 2011-12-08 at 00:00 -0500, David Miller wrote:
> From: Ajit Khaparde <ajit.khaparde@Emulex.Com>
> > + if (unlikely(vlan_tx_tag_present(skb) &&
> > + (skb->ip_summed != CHECKSUM_PARTIAL || skb->len <= 60))) {
> Poorly formatted, the second line opening first non-space character
> needs to line up precisely after the first column after the if() statements
> opening parenthesis.
In this case I believe you mean after the unlikely(
if (unlikely(vlan_tx_tag_present(skb) &&
(skb->ip_summed != CHECKSUM_PARTIAL || skb->len <= 60))) {
^ permalink raw reply
* Re: [PATCH] add netpoll support for 802.1q vlans
From: David Miller @ 2011-12-08 5:07 UTC (permalink / raw)
To: bcrl; +Cc: netdev
In-Reply-To: <20111207010424.GA16496@kvack.org>
From: Benjamin LaHaise <bcrl@kvack.org>
Date: Tue, 6 Dec 2011 20:04:24 -0500
> Add netpoll support to 802.1q vlan devices. Based on the netpoll support
> in the bridging code. Tested on a forced_eth device with netconsole.
>
> Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Bridging doesn't try to invoke a downstream netpoll operation at all,
and neither should you.
Also, please format your subject line correctly so I don't have to edit
it when applying your patch. You need to add an appropriate, lowercase,
subsystem prefix after the [PATCH] tag otherwise people scanning the
shortlog in GIT can't figure out what area your patch is in.
In this situation "vlan: " might be appropriate.
^ permalink raw reply
* Re: [net-next PATCH 2/2] be2net: workaround to fix a BE bug
From: David Miller @ 2011-12-08 5:09 UTC (permalink / raw)
To: joe; +Cc: ajit.khaparde, netdev
In-Reply-To: <1323320840.1762.61.camel@joe2Laptop>
From: Joe Perches <joe@perches.com>
Date: Wed, 07 Dec 2011 21:07:20 -0800
> On Thu, 2011-12-08 at 00:00 -0500, David Miller wrote:
>> From: Ajit Khaparde <ajit.khaparde@Emulex.Com>
>> > + if (unlikely(vlan_tx_tag_present(skb) &&
>> > + (skb->ip_summed != CHECKSUM_PARTIAL || skb->len <= 60))) {
>> Poorly formatted, the second line opening first non-space character
>> needs to line up precisely after the first column after the if() statements
>> opening parenthesis.
>
> In this case I believe you mean after the unlikely(
>
> if (unlikely(vlan_tx_tag_present(skb) &&
> (skb->ip_summed != CHECKSUM_PARTIAL || skb->len <= 60))) {
Right.
^ permalink raw reply
* [net-next PATCH] net: netprio_cgroup: make net_prio_subsys static
From: John Fastabend @ 2011-12-08 5:17 UTC (permalink / raw)
To: davem, nhorman; +Cc: netdev
net_prio_subsys can be made static this removes the sparse
warning it was throwing.
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
---
net/core/netprio_cgroup.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/core/netprio_cgroup.c b/net/core/netprio_cgroup.c
index 3a9fd48..ea16c8f 100644
--- a/net/core/netprio_cgroup.c
+++ b/net/core/netprio_cgroup.c
@@ -28,7 +28,7 @@ static struct cgroup_subsys_state *cgrp_create(struct cgroup_subsys *ss,
static void cgrp_destroy(struct cgroup_subsys *ss, struct cgroup *cgrp);
static int cgrp_populate(struct cgroup_subsys *ss, struct cgroup *cgrp);
-struct cgroup_subsys net_prio_subsys = {
+static struct cgroup_subsys net_prio_subsys = {
.name = "net_prio",
.create = cgrp_create,
.destroy = cgrp_destroy,
^ 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