* 0% cpu usasge after fresh boot or net restart but 10% CPU if kernel flush route cache
From: cold cold @ 2010-01-26 16:58 UTC (permalink / raw)
To: netdev
HI,
i have expiriance some CPU usage spikes up to 10% on each four cpus
after the first kernel route cache flush.
After mashine start first 20 min CPU is 0%si 300Mbits/s full duplex
and arount 100k pps forwarded traffic, without any firewall, just
plain routing.
route -n |wc -l
34
ip route show cache | wc -l
2140842
cat /proc/sys/net/ipv4/route/secret_interval
600
cat /proc/sys/net/ipv4/route/max_size
33554432
after kernel flush i got 10% on all CPUs for 5-6 mins. It's not from
rebuilding route cashe becouse after
fresh boot or network restrat there is no CPU usage until kernel flush
route cache.
I try to play with rhash_entries= 300000 to 2000000 same result.
Network Card: Ethernet controller: Intel Corporation 82576 Gigabit
Network Connection
CPU: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz
RAM: 4G
Kernel: vanilla 2.6.32.4
^ permalink raw reply
* Re: [PATCH 1/2] e1000: Fix DMA mapping error handling on TX
From: Roel Kluin @ 2010-01-26 15:59 UTC (permalink / raw)
To: Jeff Kirsher, davem
Cc: Yi Zou, e1000-devel, Bruce Allan, Jesse Brandeburg, John Ronciak,
Anton Blanchard, netdev
In-Reply-To: <9929d2391001231958n3f8d5165yaeed9ec1e0d7121a@mail.gmail.com>
>>> This patch does not apply to the current e1000 driver in net-2.6, much
>>> of this patch has already been corrected (applied) by Roel Kluin
>>> recent patch.
>>
>> Sorry I was basing off net-next. I just compared it to my fix and looks like
>> the patch in net-2.6 has an off by one error doesn't it?
>
> This was discussed during our code review of Roel's patch, and it was
> found that there was not an issue. But I will review the code again
> to ensure that there is not "an off by one error". Thanks for looking
> at this.
He is right, as also reported by Juha Leppanen:
> Before your patch I suppose the logic disregarding the signed/unsigned error was :
> 1) if count==0, no unmapping/freeing inside while loop
> 2) if count>0, do 'count' loops unmapping/freeing
>
> After your patch the logic is :
> 1) if count==0, no unmapping/freeing inside while loop
> 1) if count==1, no unmapping/freeing inside while loop
> 2) if count>1, do 'count-1' loops unmapping/freeing
> Can tx_ring->count be zero? I hope not.
His suggested fix works:
> dma_error:
> dev_err(&pdev->dev, "TX DMA map failed\n");
> buffer_info->dma = 0;
> - if (count)
> - count--;
>
> while (count--) {
> if (i==0)
> - i += tx_ring->count;
> + i = tx_ring->count;
> i--;
> buffer_info = &tx_ring->buffer_info[i];
> e1000_unmap_and_free_tx_resource(adapter, buffer_info);
> }
>
> return 0;
> }
This affects the patches:
[PATCH] e1000: Fix tests of unsigned in e1000_tx_map()
and the other patch in the same thread.
Do you want me to send a delta patch?
Roel
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH 1/2] IPv6: conntrack: Use protocol-related initialization routine to initial queues of IPv6 connection track
From: Patrick McHardy @ 2010-01-26 15:46 UTC (permalink / raw)
To: David Miller; +Cc: shanwei, yasuyuki.kozakai, netfilter-devel, netdev
In-Reply-To: <20100126.051147.256313206.davem@davemloft.net>
David Miller wrote:
> From: Patrick McHardy <kaber@trash.net>
> Date: Tue, 26 Jan 2010 13:46:46 +0100
>
>> Oops, sorry. Not sure why I missed this, I've successfully
>> tested that change multiple times.
>
> This situation is error prone, and I don't blame you for not catching
> it, because these common ipv6 fragmentation functions are assuming
> things about the layout of the first few struct members of the
> container in which the top level data structure lives.
>
> What should happen is that when such an assumption exists, it should
> be explicitly codified.
>
> Just like how we embed struct sock_common in both struct socket
> and in the TCP time-wait minisockets.
I'll see if I can come up with something to catch this kind of mistake
in the future.
>
> Anyways, meanwhile I'll apply the fix. And yes I know it needs
> to go to stable too... :-)
Thanks :)
^ permalink raw reply
* Re: Network QoS support in applications
From: Steven Blake @ 2010-01-26 15:29 UTC (permalink / raw)
To: David Miller; +Cc: kalle.valo, kaber, netdev, linux-wireless
In-Reply-To: <20100126.041610.226004766.davem@davemloft.net>
On Tue, 26 Jan 2010 04:16:10 -0800 (PST), David Miller
<davem@davemloft.net>
wrote:
> From: Kalle Valo <kalle.valo@iki.fi>
> Date: Tue, 26 Jan 2010 13:51:55 +0200
>
>> Let's take a bittorrent client as an example. The traffic it generates
>> is not important and it doesn't matter if bittorrent packets have
>> lower priority compared to other streams. What SO_PRIORITY value
>> should all bittorrent clients to use to mark their packets as low
>> priority (for example background class from IEEE 802.1d Annex G).
>
> This is a local policy decision.
>
> There is no universal way of doing any of this, really.
You are correct. However, RFC 4594 is an attempt to get applications and
network operators on the same page. There is no harm done if apps set DSCP
values in accordance with this RFC.
Regarding Bittorrent priority, see LEDBAT
http://www.ietf.org/dyn/wg/charter/ledbat-charter.html.
Regards,
// Steve
^ permalink raw reply
* [PATCH net-next-2.6] net: use helpers to access mc list
From: Jiri Pirko @ 2010-01-26 14:57 UTC (permalink / raw)
To: netdev; +Cc: davem
This patch introduces the similar helpers as those already done for uc list.
However multicast lists are no list_head lists but "mademanually". The three
macros added by this patch will make the transition of mc_list to list_head
smooth.
>From now on, drivers can (and should) use "netdev_for_each_mc_addr" to iterate
over the addresses with iterator of type "struct netdev_hw_addr". Also macros
"netdev_mc_count" and "netdev_mc_empty" to read list's length. This is the state
which should be reached in all drivers.
Temporary macro "netdev_for_each_mc_addr" works in the ugly way, I'm aware, but
it will be replaced. It uses iterator stored in "struct net_device". In every
iteration, it copies addr from the list to "struct netdev_hw_addr" instance
(also stored in "struct net_device"). Driver reads address stored in this
structure. All is protected by addr_list_lock held by a caller.
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 93a32a5..e470b22 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -268,6 +268,18 @@ struct netdev_hw_addr_list {
#define netdev_for_each_uc_addr(ha, dev) \
list_for_each_entry(ha, &dev->uc.list, list)
+#define netdev_mc_count(dev) ((dev)->mc_count)
+#define netdev_mc_empty(dev) (netdev_mc_count(dev) == 0)
+
+/* This is ugly, but only temporary. */
+#define netdev_for_each_mc_addr(ha, dev) \
+ for ((dev)->tmp_mc_iter = (dev)->mc_list, \
+ netdev_tmp_mc_addr_cpy(dev), \
+ ha = &dev->tmp_mc_ha; \
+ (dev)->tmp_mc_iter; \
+ (dev)->tmp_mc_iter = (dev)->tmp_mc_iter->next, \
+ netdev_tmp_mc_addr_cpy(dev))
+
struct hh_cache {
struct hh_cache *hh_next; /* Next entry */
atomic_t hh_refcnt; /* number of users */
@@ -820,6 +832,8 @@ struct net_device {
mac addresses */
int uc_promisc;
spinlock_t addr_list_lock;
+ struct netdev_hw_addr tmp_mc_ha;
+ struct dev_addr_list *tmp_mc_iter;
struct dev_addr_list *mc_list; /* Multicast mac addresses */
int mc_count; /* Number of installed mcasts */
unsigned int promiscuity;
@@ -953,6 +967,15 @@ struct net_device {
#define NETDEV_ALIGN 32
+/* Used and to be used by netdev_for_each_mc_addr. This will disappear. */
+static inline void netdev_tmp_mc_addr_cpy(struct net_device *dev)
+{
+ if (dev->tmp_mc_iter)
+ memcpy(dev->tmp_mc_ha.addr,
+ dev->tmp_mc_iter->da_addr,
+ MAX_ADDR_LEN);
+}
+
static inline
struct netdev_queue *netdev_get_tx_queue(const struct net_device *dev,
unsigned int index)
^ permalink raw reply related
* Re: Network QoS support in applications
From: Rémi Denis-Courmont @ 2010-01-26 14:43 UTC (permalink / raw)
To: netdev, linux-wireless
In-Reply-To: <87my01m0zm.fsf@purkki.valot.fi>
On Tue, 26 Jan 2010 15:47:41 +0200, Kalle Valo <kalle.valo@iki.fi> wrote:
> But that's just because of mistakes with DiffServ and other QoS
> "frameworks". They didn't bother to specify how applications should
> use these. And what matters here IMHO.
TOS lets the application specify whether they want low-delay (interactive
low bandwidth traffic), high bandwidth (bulk traffic), high reliability or
low cost. It's surely vague, but anything "uniform" solution is bound to be
vague. Some applications *do* set those fields, or provide options to set
them up. And contrary to SO_PRIORITY, it *can* be made to work for
non-local queues, if the applications are trusted.
I am afraid it's too late for anything more uniform at the socket API
level. Even fewer developers would bother to support Linux>=2.6.3x-specific
options, than TOS/TCLASS.
--
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis
^ permalink raw reply
* Re: [PATCH] starfire: Clean up properly if firmware loading fails
From: Ben Hutchings @ 2010-01-26 14:40 UTC (permalink / raw)
To: Michael
Cc: Andrew Morton, netdev, bugzilla-daemon, bugme-daemon, Alan Cox,
stable, David S. Miller
In-Reply-To: <4B5E82CB.6040001@moffatt.org.nz>
On Tue, 2010-01-26 at 18:51 +1300, Michael wrote:
[...]
> I will have to find a cleverer way to copy over the new firmware libs
> for future compiles. The 'make install' seems to copy firmware objects
> into the compiling system's /lib/firmware/ directory without
> distinguishing the kernel version. So I can't easily tell which ones I'm
> supposed to be copying into the nfs export.
[...]
You should be setting INSTALL_MOD_PATH.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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: Network QoS support in applications
From: Kalle Valo @ 2010-01-26 14:27 UTC (permalink / raw)
To: Dunc
Cc: David Miller, kaber-dcUjhNyLwpNeoWH0uzbU5w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4B5EF5DF.2070005-9b9L1Hpe0sBAfugRpC6u6w@public.gmane.org>
Dunc <dunc-9b9L1Hpe0sBAfugRpC6u6w@public.gmane.org> writes:
> If applications set the QoS values, the who's to stop someone (for
> example) writing a bittorrent client that marks all packets for the
> highest priority as if they were VoIP or something?
Nobody. That would a bug in the application which should be fixed.
Badly behaving applications can disrupt the network, with or without
QoS support. So no need to blame QoS for this.
And if the network doesn't want to trust applications, it's free to do
so. Nothing prevents that. And based on the discussion so far, the
networks already ignore QoS classifations coming from other network
realms.
> At this point all the good work done in the applications is useless
> and the network admin is going to have to not trust the QoS values
> and then attempt to classify traffic by themselves, so it was all a
> waste of time.
Because of one badly behaving application? I think that's a bit
extreme. If QoS API brings benefits to the user (for example in this
case bittorrent giving bandwith to more important streams), most
probably applications try to get it right.
> It's probably better to just always leave it up to the network devices IMHO.
If we are happy with the current situation, sure, no need to do
anything. But if we want to improve network services, we need to start
to do something about this.
I want to emphasise that we shouldn't look at this just from the core
network point of view, but with a broader look. We have now different
network technologies and devices where Linux is used. We should not
just look at this from a point where a Linux workstation (or router)
is connected with a fast access to Internet. For example, I want to
have my ssh terminal connection higher priority compared to emails
downloading background on a slow cellular network.
--
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Network QoS support in applications
From: Dunc @ 2010-01-26 14:02 UTC (permalink / raw)
To: Kalle Valo; +Cc: David Miller, kaber, netdev, linux-wireless
In-Reply-To: <87my01m0zm.fsf@purkki.valot.fi>
> And you are perfectly right, as always. My choise of using the word
> "universal" was bad. With word "universal" I meant to use same network
> QoS API with different network technologies: ethernet, wi-fi,
> bluetooth etc.
>
> But we don't need to solve everything in one go, instead we can make
> small steps. The first step is to start pushing applications to
> classify their streams. That's the enabler to get some sort of QoS
> support, at least to inside kernel and to the next hop. With luck, in
> future it might get more widely used.
>
> I was hoping to base the classification on some standard, but there
> doesn't really seem to be one which would specify a complete solution.
> But that's ok, we can always create a de facto standard :)
>
> I'm curious how other operation systems handle this? Or is it a
> similar situation, nobody just doesn't use QoS for anything?
>
If applications set the QoS values, the who's to stop someone (for
example) writing a bittorrent client that marks all packets for the
highest priority as if they were VoIP or something? At this point all
the good work done in the applications is useless and the network admin
is going to have to not trust the QoS values and then attempt to
classify traffic by themselves, so it was all a waste of time.
It's probably better to just always leave it up to the network devices IMHO.
Cheers,
Dunc
^ permalink raw reply
* [PATCH net-next-2.6] can: deny filterlist access on non-CAN interfaces
From: Oliver Hartkopp @ 2010-01-26 13:51 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List
In commit 20dd3850bcf860561496827b711fa10fecf6e787 "can: Speed up CAN frame
receiption by using ml_priv" the formerly used hlist of receiver lists for
each CAN netdevice has been replaced.
The hlist content ensured only CAN netdevices to be accessed by the
can_rx_(un)register() functions which accidently dropped away together with
the hlist receiver implementation.
This patch re-introduces the check for CAN netdevices in can_rx_(un)register().
Signed-off-by: Oliver Hartkopp <oliver@hartkopp.net>
---
diff --git a/net/can/af_can.c b/net/can/af_can.c
index bc18b08..702be5a 100644
--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -415,6 +415,9 @@ int can_rx_register(struct net_device *dev, canid_t can_id, canid_t mask,
/* insert new receiver (dev,canid,mask) -> (func,data) */
+ if (dev && dev->type != ARPHRD_CAN)
+ return -ENODEV;
+
r = kmem_cache_alloc(rcv_cache, GFP_KERNEL);
if (!r)
return -ENOMEM;
@@ -478,6 +481,9 @@ void can_rx_unregister(struct net_device *dev, canid_t can_id, canid_t mask,
struct hlist_node *next;
struct dev_rcv_lists *d;
+ if (dev && dev->type != ARPHRD_CAN)
+ return;
+
spin_lock(&can_rcvlists_lock);
d = find_dev_rcv_lists(dev);
^ permalink raw reply related
* Re: Network QoS support in applications
From: Kalle Valo @ 2010-01-26 13:47 UTC (permalink / raw)
To: David Miller
Cc: kaber-dcUjhNyLwpNeoWH0uzbU5w, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100126.050645.184040277.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> writes:
> From: Kalle Valo <kalle.valo-X3B1VOXEql0@public.gmane.org>
> Date: Tue, 26 Jan 2010 14:56:50 +0200
>
>> In my opinion we already now need a universal solution for the user
>> space applications to classify their streams. Having a local solution
>> doesn't get us far, people don't want to configure their laptops or
>> phones, they just want to use them :)
>
> And similarly your organization's administartion doesn't want to
> prioritize bittorrent traffic a specific fixed way just because your
> application sets some bits in the TOS field of it's packets.
>
> Prioritization policies have no meaning outside of your local realm,
> and that's just a fact of life.
Yes, that's what I have understood.
> So what typically happens is that applications do nothing.
But that's just because of mistakes with DiffServ and other QoS
"frameworks". They didn't bother to specify how applications should
use these. And what matters here IMHO.
> And machines on the ingress to a network realm change the TOS based
> field upon classification decisions made by parsing the packet by the
> router/firewall/whatever.
>
> The packet gets QoS treatment within the realm, but completely
> determined by local policy within that realm.
>
> And then on egress from the realm the TOS field has absolutely
> no meaning at all to the next network segment.
And you are perfectly right, as always. My choise of using the word
"universal" was bad. With word "universal" I meant to use same network
QoS API with different network technologies: ethernet, wi-fi,
bluetooth etc.
But we don't need to solve everything in one go, instead we can make
small steps. The first step is to start pushing applications to
classify their streams. That's the enabler to get some sort of QoS
support, at least to inside kernel and to the next hop. With luck, in
future it might get more widely used.
I was hoping to base the classification on some standard, but there
doesn't really seem to be one which would specify a complete solution.
But that's ok, we can always create a de facto standard :)
I'm curious how other operation systems handle this? Or is it a
similar situation, nobody just doesn't use QoS for anything?
--
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: drivers/net/ariadne.c:165: error: 'set_multicast_list' undeclared here (not in a function)
From: David Miller @ 2010-01-26 13:18 UTC (permalink / raw)
To: geert; +Cc: adobriyan, linux-next, netdev, linux-kernel
In-Reply-To: <10f740e81001260057h37f3494dvefa3a37b2e1453a5@mail.gmail.com>
From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Tue, 26 Jan 2010 09:57:05 +0100
> http://kisskb.ellerman.id.au/kisskb/buildresult/2076964/
>
> drivers/net/ariadne.c:165: error: 'set_multicast_list' undeclared here
> (not in a function)
>
> Seems to be broken by:
I'll fix this with the patch below.
Alexey, please go through at least drivers/net and look at the
other stale references to these HAVE_* macros.
For example I still see a bunch of HAVE_POLL_CONTROLLER stuff.
Thanks.
ariadne: Fix build.
References removed HAVE_MULTICAST.
Reporeted-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/ariadne.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ariadne.c b/drivers/net/ariadne.c
index c35af3e..e2c2024 100644
--- a/drivers/net/ariadne.c
+++ b/drivers/net/ariadne.c
@@ -123,9 +123,7 @@ static void ariadne_reset(struct net_device *dev);
static irqreturn_t ariadne_interrupt(int irq, void *data);
static int ariadne_close(struct net_device *dev);
static struct net_device_stats *ariadne_get_stats(struct net_device *dev);
-#ifdef HAVE_MULTICAST
static void set_multicast_list(struct net_device *dev);
-#endif
static void memcpyw(volatile u_short *dest, u_short *src, int len)
--
1.6.6.1
^ permalink raw reply related
* Re: [PATCH 1/2] IPv6: conntrack: Use protocol-related initialization routine to initial queues of IPv6 connection track
From: David Miller @ 2010-01-26 13:11 UTC (permalink / raw)
To: kaber; +Cc: shanwei, yasuyuki.kozakai, netfilter-devel, netdev
In-Reply-To: <4B5EE436.3040204@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Tue, 26 Jan 2010 13:46:46 +0100
> Oops, sorry. Not sure why I missed this, I've successfully
> tested that change multiple times.
This situation is error prone, and I don't blame you for not catching
it, because these common ipv6 fragmentation functions are assuming
things about the layout of the first few struct members of the
container in which the top level data structure lives.
What should happen is that when such an assumption exists, it should
be explicitly codified.
Just like how we embed struct sock_common in both struct socket
and in the TCP time-wait minisockets.
Anyways, meanwhile I'll apply the fix. And yes I know it needs
to go to stable too... :-)
^ permalink raw reply
* Re: Network QoS support in applications
From: Henning Rogge @ 2010-01-26 13:06 UTC (permalink / raw)
To: Kalle Valo
Cc: David Miller, kaber-dcUjhNyLwpNeoWH0uzbU5w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <87wrz5m3cd.fsf-ySPBbPOLdCfMApvqMRVM/A@public.gmane.org>
[-- Attachment #1: Type: Text/Plain, Size: 1059 bytes --]
On Tue January 26 2010 13:56:50 Kalle Valo wrote:
> So the idea is that the three left most bits (Class Selector
> Codepoints from DiffServ RFC 2474) would contain these values from
> IEEE 802.1d-2004 Annex G:
>
> 0 best effort
> 1 background
> 2 (spare)
> 3 excellent effort
> 4 controlled load
> 5 video
> 6 voice
> 7 network control
>
> What do people think of this?
The IETF is discussing about a traffic priority below "best effort" for bulk
traffic at the moment. Something you use to fill up links if your can but drop it
if you are not sure. So it might be a good idea to make "best efford" not zero.
Henning Rogge
--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-263, Fax +49 228 9435 685
mailto:henning.rogge-FCsFpRLaMoKatNDF+KUbs4QuADTiUCJX@public.gmane.org http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Network QoS support in applications
From: David Miller @ 2010-01-26 13:06 UTC (permalink / raw)
To: kalle.valo; +Cc: kaber, netdev, linux-wireless
In-Reply-To: <87wrz5m3cd.fsf@purkki.valot.fi>
From: Kalle Valo <kalle.valo@iki.fi>
Date: Tue, 26 Jan 2010 14:56:50 +0200
> In my opinion we already now need a universal solution for the user
> space applications to classify their streams. Having a local solution
> doesn't get us far, people don't want to configure their laptops or
> phones, they just want to use them :)
And similarly your organization's administartion doesn't want to
prioritize bittorrent traffic a specific fixed way just because your
application sets some bits in the TOS field of it's packets.
Prioritization policies have no meaning outside of your local realm,
and that's just a fact of life.
So what typically happens is that applications do nothing.
And machines on the ingress to a network realm change the TOS based
field upon classification decisions made by parsing the packet by the
router/firewall/whatever.
The packet gets QoS treatment within the realm, but completely
determined by local policy within that realm.
And then on egress from the realm the TOS field has absolutely
no meaning at all to the next network segment.
^ permalink raw reply
* Re: Network QoS support in applications
From: Kalle Valo @ 2010-01-26 12:56 UTC (permalink / raw)
To: David Miller; +Cc: kaber, netdev, linux-wireless
In-Reply-To: <20100126.041610.226004766.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Kalle Valo <kalle.valo@iki.fi>
> Date: Tue, 26 Jan 2010 13:51:55 +0200
>
>> Let's take a bittorrent client as an example. The traffic it generates
>> is not important and it doesn't matter if bittorrent packets have
>> lower priority compared to other streams. What SO_PRIORITY value
>> should all bittorrent clients to use to mark their packets as low
>> priority (for example background class from IEEE 802.1d Annex G).
>
> This is a local policy decision.
>
> There is no universal way of doing any of this, really.
In my opinion we already now need a universal solution for the user
space applications to classify their streams. Having a local solution
doesn't get us far, people don't want to configure their laptops or
phones, they just want to use them :)
Having a well defined API for this makes it easier for everyone. Also
proprietary applications, like skype, can make use of QoS.
It doesn't matter how we map these internally in kernel, but the
interface to user space needs to be documented and maintained. I'm
willing to work on this, but we first need a concensus for the method.
I'm leaning towards using IPv4 DS/TOS and IPv6 Traffic Class fields
using IEEE 802.1d values. That way, with luck, the class of the packet
is visible even more than one hop. In fact cfg80211/mac80211 is
already doing this for IPv4:
/* Given a data frame determine the 802.1p/1d tag to use. */
unsigned int cfg80211_classify8021d(struct sk_buff *skb)
{
unsigned int dscp;
/* skb->priority values from 256->263 are magic values to
* directly indicate a specific 802.1d priority. This is used
* to allow 802.1d priority to be passed directly in from VLAN
* tags, etc.
*/
if (skb->priority >= 256 && skb->priority <= 263)
return skb->priority - 256;
switch (skb->protocol) {
case htons(ETH_P_IP):
dscp = ip_hdr(skb)->tos & 0xfc;
break;
default:
return 0;
}
return dscp >> 5;
}
http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=blob;f=net/wireless/util.c;h=be2ab8c59e3a9806425b2b958d87dfe50d80111d;hb=HEAD#l598
So the idea is that the three left most bits (Class Selector
Codepoints from DiffServ RFC 2474) would contain these values from
IEEE 802.1d-2004 Annex G:
0 best effort
1 background
2 (spare)
3 excellent effort
4 controlled load
5 video
6 voice
7 network control
What do people think of this?
Feel free to flame, it was -20 C (-4 F) this morning. I would need
some warmth here :)
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 1/2] IPv6: conntrack: Use protocol-related initialization routine to initial queues of IPv6 connection track
From: Yasuyuki KOZAKAI @ 2010-01-26 12:56 UTC (permalink / raw)
To: shanwei; +Cc: kaber, davem, yasuyuki.kozakai, netfilter-devel, netdev
In-Reply-To: <4B5E53EE.9010703@cn.fujitsu.com>
Patches looks good to me. But nf_ct_frag_match in the this patch
is added by [PATCH 2/2]. Subject mistake ?
-- Yasuyuki Kozakai
From: Shan Wei <shanwei@cn.fujitsu.com>
Date: Tue, 26 Jan 2010 10:31:10 +0800
>
> IPv6 connection track and IPv6 stack separately use a different queue to
> manage received fragments. The former uses nf_ct_frag6_queue structure,
> the latter uses frag_queue structure.
>
> When creating new queue for IPv6 connection track, ip6_frag_init()
> that belongs to IPv6 stack is called to initial nf_ct_frag6_queue structure.
> This broken the saddr&daddr member in nf_ct_frag6_queue, and then hash value
> generated by nf_hashfn() is not equal with that generated by fq_find().
> So, a new received fragment can't be inserted to right queue.
>
> The patch fixes the bug with protocol-related initialization routine.
> The patch-set have been tested.
>
>
> Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
> ---
> include/net/ipv6.h | 1 -
> net/ipv6/netfilter/nf_conntrack_reasm.c | 13 ++++++++++++-
> net/ipv6/reassembly.c | 3 +--
> 3 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/include/net/ipv6.h b/include/net/ipv6.h
> index cbd768b..a7112da 100644
> --- a/include/net/ipv6.h
> +++ b/include/net/ipv6.h
> @@ -364,7 +364,6 @@ struct ip6_create_arg {
> struct in6_addr *dst;
> };
>
> -void ip6_frag_init(struct inet_frag_queue *q, void *a);
>
> static inline int ipv6_addr_any(const struct in6_addr *a)
> {
> diff --git a/net/ipv6/netfilter/nf_conntrack_reasm.c b/net/ipv6/netfilter/nf_conntrack_reasm.c
> index 66b6161..4a61d14 100644
> --- a/net/ipv6/netfilter/nf_conntrack_reasm.c
> +++ b/net/ipv6/netfilter/nf_conntrack_reasm.c
> @@ -146,6 +146,17 @@ static void nf_ct_frag6_evictor(void)
> local_bh_enable();
> }
>
> +static void nf_ct_queue_init(struct inet_frag_queue *q, void *a)
> +{
> + struct nf_ct_frag6_queue *fq;
> + struct ip6_create_arg *arg = a;
> +
> + fq = container_of(q, struct nf_ct_frag6_queue, q);
> + fq->id = arg->id;
> + ipv6_addr_copy(&fq->saddr, arg->src);
> + ipv6_addr_copy(&fq->daddr, arg->dst);
> +}
> +
> static int nf_ct_frag_match(struct inet_frag_queue *q, void *a)
> {
> struct nf_ct_frag6_queue *fq;
> @@ -672,7 +683,7 @@ void nf_ct_frag6_output(unsigned int hooknum, struct sk_buff *skb,
> int nf_ct_frag6_init(void)
> {
> nf_frags.hashfn = nf_hashfn;
> - nf_frags.constructor = ip6_frag_init;
> + nf_frags.constructor = nf_ct_frag_init;
> nf_frags.destructor = NULL;
> nf_frags.skb_free = nf_skb_free;
> nf_frags.qsize = sizeof(struct nf_ct_frag6_queue);
> diff --git a/net/ipv6/reassembly.c b/net/ipv6/reassembly.c
> index 2fa4355..9f9b6a2 100644
> --- a/net/ipv6/reassembly.c
> +++ b/net/ipv6/reassembly.c
> @@ -157,7 +157,7 @@ static inline void frag_kfree_skb(struct netns_frags *nf,
> kfree_skb(skb);
> }
>
> -void ip6_frag_init(struct inet_frag_queue *q, void *a)
> +static void ip6_frag_init(struct inet_frag_queue *q, void *a)
> {
> struct frag_queue *fq = container_of(q, struct frag_queue, q);
> struct ip6_create_arg *arg = a;
> @@ -167,7 +167,6 @@ void ip6_frag_init(struct inet_frag_queue *q, void *a)
> ipv6_addr_copy(&fq->saddr, arg->src);
> ipv6_addr_copy(&fq->daddr, arg->dst);
> }
> -EXPORT_SYMBOL(ip6_frag_init);
>
> /* Destruction primitives. */
>
> --
> 1.6.3.3
>
> --
> 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 1/2] IPv6: conntrack: Use protocol-related initialization routine to initial queues of IPv6 connection track
From: Patrick McHardy @ 2010-01-26 12:46 UTC (permalink / raw)
To: Shan Wei; +Cc: David Miller, yasuyuki.kozakai, netfilter-devel, netdev
In-Reply-To: <4B5EE2C6.6010802@cn.fujitsu.com>
Shan Wei wrote:
> David Miller wrote, at 01/26/2010 03:32 PM:
>> From: Shan Wei <shanwei@cn.fujitsu.com>
>> Date: Tue, 26 Jan 2010 10:31:10 +0800
>>
>>> IPv6 connection track and IPv6 stack separately use a different queue to
>>> manage received fragments. The former uses nf_ct_frag6_queue structure,
>>> the latter uses frag_queue structure.
>>>
>>> When creating new queue for IPv6 connection track, ip6_frag_init()
>>> that belongs to IPv6 stack is called to initial nf_ct_frag6_queue structure.
>>> This broken the saddr&daddr member in nf_ct_frag6_queue, and then hash value
>>> generated by nf_hashfn() is not equal with that generated by fq_find().
>>> So, a new received fragment can't be inserted to right queue.
>>>
>>> The patch fixes the bug with protocol-related initialization routine.
>>> The patch-set have been tested.
>>>
>>> Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
>> This breakage was recently introduced by:
>>
>> commit 0b5ccb2ee250136dd7385b1c7da28417d0d4d32d
>> Author: Patrick McHardy <kaber@trash.net>
>> Date: Tue Dec 15 16:59:18 2009 +0100
>>
>> ipv6: reassembly: use seperate reassembly queues for conntrack and local delivery
>
> Yes, this patch adds user member to frag_queue structure，but not to nf_ct_frag6_queue structure.
Oops, sorry. Not sure why I missed this, I've successfully
tested that change multiple times.
> Please ignore the patch-set.
> Can you apply the following patch(bug-fix) to your net-tree?
>
> --
> [PATCH]IPv6: conntrack: Add member of user to nf_ct_frag6_queue structure
>
> The commit 0b5ccb2(title:ipv6: reassembly: use seperate reassembly queues for
> conntrack and local delivery) has broken the saddr&&daddr member of
> nf_ct_frag6_queue when creating new queue. And then hash value
> generated by nf_hashfn() was not equal with that generated by fq_find().
> So, a new received fragment can't be inserted to right queue.
>
> The patch fixes the bug with adding member of user to nf_ct_frag6_queue structure.
>
> Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
Acked-by: Patrick McHardy <kaber@trash.net>
--
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 1/2] IPv6: conntrack: Use protocol-related initialization routine to initial queues of IPv6 connection track
From: Shan Wei @ 2010-01-26 12:40 UTC (permalink / raw)
To: David Miller; +Cc: kaber, yasuyuki.kozakai, netfilter-devel, netdev
In-Reply-To: <20100125.233254.35824860.davem@davemloft.net>
David Miller wrote, at 01/26/2010 03:32 PM:
> From: Shan Wei <shanwei@cn.fujitsu.com>
> Date: Tue, 26 Jan 2010 10:31:10 +0800
>
>> IPv6 connection track and IPv6 stack separately use a different queue to
>> manage received fragments. The former uses nf_ct_frag6_queue structure,
>> the latter uses frag_queue structure.
>>
>> When creating new queue for IPv6 connection track, ip6_frag_init()
>> that belongs to IPv6 stack is called to initial nf_ct_frag6_queue structure.
>> This broken the saddr&daddr member in nf_ct_frag6_queue, and then hash value
>> generated by nf_hashfn() is not equal with that generated by fq_find().
>> So, a new received fragment can't be inserted to right queue.
>>
>> The patch fixes the bug with protocol-related initialization routine.
>> The patch-set have been tested.
>>
>> Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
>
> This breakage was recently introduced by:
>
> commit 0b5ccb2ee250136dd7385b1c7da28417d0d4d32d
> Author: Patrick McHardy <kaber@trash.net>
> Date: Tue Dec 15 16:59:18 2009 +0100
>
> ipv6: reassembly: use seperate reassembly queues for conntrack and local delivery
Yes, this patch adds user member to frag_queue structure，but not to nf_ct_frag6_queue structure.
Please ignore the patch-set.
Can you apply the following patch(bug-fix) to your net-tree?
--
[PATCH]IPv6: conntrack: Add member of user to nf_ct_frag6_queue structure
The commit 0b5ccb2(title:ipv6: reassembly: use seperate reassembly queues for
conntrack and local delivery) has broken the saddr&&daddr member of
nf_ct_frag6_queue when creating new queue. And then hash value
generated by nf_hashfn() was not equal with that generated by fq_find().
So, a new received fragment can't be inserted to right queue.
The patch fixes the bug with adding member of user to nf_ct_frag6_queue structure.
Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
---
net/ipv6/netfilter/nf_conntrack_reasm.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/ipv6/netfilter/nf_conntrack_reasm.c b/net/ipv6/netfilter/nf_conntrack_reasm.c
index 312c20a..624a548 100644
--- a/net/ipv6/netfilter/nf_conntrack_reasm.c
+++ b/net/ipv6/netfilter/nf_conntrack_reasm.c
@@ -63,6 +63,7 @@ struct nf_ct_frag6_queue
struct inet_frag_queue q;
__be32 id; /* fragment id */
+ u32 user;
struct in6_addr saddr;
struct in6_addr daddr;
--
1.6.3.3
--
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 related
* Re: [PATCH 0/11] Update support for MPC512x
From: Wolfram Sang @ 2010-01-26 12:16 UTC (permalink / raw)
To: Anatolij Gustschin
Cc: John Rigby, dzu, netdev, linux-usb, Grant Likely, linuxppc-dev,
linux-mtd, linux-i2c, rtc-linux, Dan Williams
In-Reply-To: <20100126090633.74257b1a@wker>
[-- Attachment #1: Type: text/plain, Size: 671 bytes --]
> No, I don't have a git tree for this now, sorry.
No problem, I set one up at:
git://git.pengutronix.de/git/wsa/linux-2.6.git
It is based on 2.6.33-rc5 and contains the newest patches for FEC and I2C. (I
will pick up the patches as they show up on the lists, so this tree will be
rebased!)
This tree includes all MPC5121-patches and the two USB-patches from Anton. I
haven't actually tested them yet, but they all applied cleanly, at least.
Testing will come soon...
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Network QoS support in applications
From: David Miller @ 2010-01-26 12:16 UTC (permalink / raw)
To: kalle.valo-X3B1VOXEql0
Cc: kaber-dcUjhNyLwpNeoWH0uzbU5w, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <877hr5nkx0.fsf-ySPBbPOLdCfMApvqMRVM/A@public.gmane.org>
From: Kalle Valo <kalle.valo-X3B1VOXEql0@public.gmane.org>
Date: Tue, 26 Jan 2010 13:51:55 +0200
> Let's take a bittorrent client as an example. The traffic it generates
> is not important and it doesn't matter if bittorrent packets have
> lower priority compared to other streams. What SO_PRIORITY value
> should all bittorrent clients to use to mark their packets as low
> priority (for example background class from IEEE 802.1d Annex G).
This is a local policy decision.
There is no universal way of doing any of this, really.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Network QoS support in applications
From: Patrick McHardy @ 2010-01-26 11:59 UTC (permalink / raw)
To: Kalle Valo
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <877hr5nkx0.fsf-ySPBbPOLdCfMApvqMRVM/A@public.gmane.org>
Kalle Valo wrote:
> Patrick McHardy <kaber-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org> writes:
>
>>> Solution 2: SO_PRIORITY with values 256-263
>> You can actually encode any class handle in SO_PRIORITY, all classful
>> qdiscs support classification based on this.
>
> But what values should I use in an application? There seems to n+1
> different ways to do it, but they all would be specific to my own
> setup.
In case of classful qdisc classification, the values need to
match the class handles.
> I'm after a universal solution, so that there is no need to modify
> applications every time. I would assume that we have a set of rules
> for this. If not, we definitely need one.
Classful qdisc configuration is done by the administrator, so
there is no universal solution.
> Let's take a bittorrent client as an example. The traffic it generates
> is not important and it doesn't matter if bittorrent packets have
> lower priority compared to other streams. What SO_PRIORITY value
> should all bittorrent clients to use to mark their packets as low
> priority (for example background class from IEEE 802.1d Annex G).
>
> Another example is a VoIP application. The packets need to have as low
> delay as possible, so they need to be prioritised very high (for
> example voice class from 802.1d). What value should such application
> use?
If the device is using the default pfifo_fast qdisc, you
can use values 6 and 7 to map to band 0 (highest priority),
0 and 8-15 to map to band 1 and 1-3 and 5 to map to band 2.
For manually set up qdisc hierarchies you need to ask the
user to specify a priority (or class handle) value.
> Or should applications use something else than SO_PRIORITY?
>
> Any help is greatly welcomed here :)
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Network QoS support in applications
From: Kalle Valo @ 2010-01-26 11:51 UTC (permalink / raw)
To: Patrick McHardy
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4B5ED254.7010104-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
Patrick McHardy <kaber-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org> writes:
>> Solution 2: SO_PRIORITY with values 256-263
>
> You can actually encode any class handle in SO_PRIORITY, all classful
> qdiscs support classification based on this.
But what values should I use in an application? There seems to n+1
different ways to do it, but they all would be specific to my own
setup.
I'm after a universal solution, so that there is no need to modify
applications every time. I would assume that we have a set of rules
for this. If not, we definitely need one.
Let's take a bittorrent client as an example. The traffic it generates
is not important and it doesn't matter if bittorrent packets have
lower priority compared to other streams. What SO_PRIORITY value
should all bittorrent clients to use to mark their packets as low
priority (for example background class from IEEE 802.1d Annex G).
Another example is a VoIP application. The packets need to have as low
delay as possible, so they need to be prioritised very high (for
example voice class from 802.1d). What value should such application
use?
Or should applications use something else than SO_PRIORITY?
Any help is greatly welcomed here :)
--
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Network QoS support in applications
From: Patrick McHardy @ 2010-01-26 11:30 UTC (permalink / raw)
To: Kalle Valo
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <87k4v5nuej.fsf-ySPBbPOLdCfMApvqMRVM/A@public.gmane.org>
Kalle Valo wrote:
> Hello,
>
> I have been trying to understand how applications should use network
> QoS. My interest have been mostly from wireless perspective,
> especially how to utilise WMM and U-APSD properly, but naturally this
> applicable to all networks.
>
> I have done some research about this, but I haven't managed to get
> anywhere. For example, from my point of view DiffServ is just one big
> mess and I can't see how in practise it can help applications.
>
> I wrote a small wiki page to sum up my findings:
>
> http://wireless.kernel.org/en/developers/Documentation/qos
>
> I would like to clear up all this by and I'm willing to write a
> document for application developers about network QoS. But I need help
> to understand what's the proper way to mark different QoS
> prioritities.
>
> In the wiki page I have tried to come up with different possible
> solutions (copied below), but I'm sure there are even more ways.
>
> Please comment. I would like to get some understanding about this.
>
>
> ----------------------------------------------------------------------
> Solution 1: SO_PRIORITY with values 0-7
>
> Easy, applications need to just use setsockopt() and be done with it.
> It's unknown how widely supported values 0-7 are and the exact meaning
> of them, but at least they make sense (0 default, 1 lowest priority
> and 7 highest priority). The problem is that the priority is used only
> in the first link, rest of the route is not able to benefit from the
> classification.
>
> Pros:
>
> * easy for applications
> * works with both IPv4 and IPv6
>
> Cons:
>
> * only visible in in the first L2 link, not visible to upper
> layers (IP)
> * no well defined meaning for the priority values
>
> Solution 2: SO_PRIORITY with values 256-263
You can actually encode any class handle in SO_PRIORITY, all classful
qdiscs support classification based on this.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Netlink usage question (for bonding comm with userspace)
From: Patrick McHardy @ 2010-01-26 11:25 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: netdev
In-Reply-To: <15914.1264466901@death.nxdomain.ibm.com>
Jay Vosburgh wrote:
> Could any netlink gurus comment on my questions? I'm hoping to
> figure out the right way to do what I need without working up patches
> that end up being excellent examples of the wrong way. I've looked
> through the kernel, and it's almost a cases of too many choices (private
> netlink, rtnetlink, connector, genetlink) to sort through.
>
> Background: I'm working on a bonding mode that involves two-way
> communication between bonding itself and a user-space daemon, and I'm
> trying to determine the best way to utilize netlink for this project
> with an eye towards forwards compatibility with future expansion (e.g.,
> general bonding setup via netlink). For purposes of discussion, the
> communication requires that bonding-specific requests, responses and
> asynchronous events flow in both directions.
>
> I could, for this project, use a netlink_kernel_create and
> socket(AF_NETLINK) pair to perform the communication (presumably adding
> a NETLINK_BONDING or the like to <linux/netlink.h>).
>
> That, however, wouldn't dovetail with moving control of bonding
> into iproute2 ("ip link add link bond0 type bond mode whatever"), and it
> seems suboptimal to have two independent netlink gizmos in bonding. I'm
> not planning to implement full bonding control via netlink at this time,
> but I don't want to do anything that would cause difficulty for doing so
> in the future.
I actually have an 75% finished patchset for rtnl_link support.
> I've done some prototyping with working through the existing
> rtnetlink infrastructure, adding an RTNLGRP_BONDING, AF_BONDING, etc,
> vaguely paralleling how the bridge code is architected. What's unclear
> to me is how to insert the bonding-specific request / response message
> types into the rtnetlink infrastructure, or, indeed, if this is simply
> not the right way to go about this.
>
> So, in summary:
>
> For user / kernel communications via netlink: private socket,
> add to rtnetlink API, or something else (connector, genetlink, ...)?
>
> Is having private socket netlink and rtnetlink in the same
> module a reasonable methodology?
It depends. If your requests and responses can be expressed as
device configuration and state changes then you could include them
in the bonding specific part of an rtnetlink message. Otherwise
you should use a private netlink family or genetlink.
> If rtnetlink is suitable, basic "do this" or "don't do this"
> thoughts? The various HOWTOs google finds for me concentrate on the
> mechanisms, less so on interface selection / design.
>
> Thoughts?
>
> -J
>
> ---
> -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
> --
> 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
>
^ 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