* Re: [RFC PATCH] dont create cached routes from ARP requests
From: Ulrich Weber @ 2010-09-24 15:38 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Ulrich Weber, David Miller, netdev
In-Reply-To: <1285342083.2503.252.camel@edumazet-laptop>
Yes, as I wrote before my Cable ISP is flooding me with
ARP requests from 10.0.0.0/8, which get a route
via the primary PPP link.
I know thats not a common setup but why do that
kind of routes have to be cached ? :)
steps to reproduce:
server:
ip route add 1.0.0.0/8 dev dummy0
client:
ip route add 1.0.0.0/8 dev eth0
nmap --min-rate 500 -sP 1.0.0.0/8
On 09/24/2010 05:28 PM, Eric Dumazet wrote:
> Le vendredi 24 septembre 2010 à 17:00 +0200, Ulrich Weber a écrit :
>> Hi Eric,
>>
>> please find the output in the attached text file.
>>
>> Neighbor garbage collection wont't work because all
>> neighbor records are bound to cached routes.
>>
>> Forced route garbaged collections returns without freeing
>> any routes, probably because the route threshold is quite high
>> with 65536 compared to the small neighbor threshold of 1024,
>> resulting in a fixed amount of 1024 cached routes...
>>
>> Instead of running the garbage collection we could flush the route
>> cache completely if the neighbor cache overflows.
>> But why do we have to cache that routes in first place ?
>> See the previous patch which skips caching for that kind of routes.
>
> What are the packets you receive ? A flood of ARP answers ?
>
> a "tcpdump -X" of a few packets would help to understand.
>
>
>
--
Ulrich Weber | uweber@astaro.com | Software Engineer
Astaro GmbH & Co. KG | www.astaro.com | Phone +49-721-25516-0 | Fax –200
An der RaumFabrik 33a | 76227 Karlsruhe | Germany
^ permalink raw reply
* Re: [RFC PATCH] dont create cached routes from ARP requests
From: Eric Dumazet @ 2010-09-24 15:34 UTC (permalink / raw)
To: Ulrich Weber; +Cc: Ulrich Weber, David Miller, netdev
In-Reply-To: <1285342083.2503.252.camel@edumazet-laptop>
Le vendredi 24 septembre 2010 à 17:28 +0200, Eric Dumazet a écrit :
> What are the packets you receive ? A flood of ARP answers ?
>
> a "tcpdump -X" of a few packets would help to understand.
>
>
Also please report
grep . `find /proc/sys -name arp_accept`
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/2] net: Allow changing number of RX queues after device allocation
From: Tom Herbert @ 2010-09-24 15:34 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Eric Dumazet, David Miller, netdev, linux-net-drivers
In-Reply-To: <1285331081.2257.3.camel@achroite.uk.solarflarecom.com>
Looks good to me.
>> All functions in this file use a single line.
>>
>> > -static int rx_queue_register_kobjects(struct net_device *net)
>> > +int
>> > +net_rx_queue_update_kobjects(struct net_device *net, int old_num, int new_num)
>>
>> ->
>>
>> int net_rx_queue_update_kobjects(struct net_device *net, int old, int new)
>
> Why should I rename variables to fit a function signature on one line?
>
Maybe split the line within the parameter list, this would be more
consistent with other function declarations.
^ permalink raw reply
* Re: [RFC PATCH] dont create cached routes from ARP requests
From: Eric Dumazet @ 2010-09-24 15:28 UTC (permalink / raw)
To: Ulrich Weber; +Cc: Ulrich Weber, David Miller, netdev
In-Reply-To: <4C9CBCFC.6080300@gmail.com>
Le vendredi 24 septembre 2010 à 17:00 +0200, Ulrich Weber a écrit :
> Hi Eric,
>
> please find the output in the attached text file.
>
> Neighbor garbage collection wont't work because all
> neighbor records are bound to cached routes.
>
> Forced route garbaged collections returns without freeing
> any routes, probably because the route threshold is quite high
> with 65536 compared to the small neighbor threshold of 1024,
> resulting in a fixed amount of 1024 cached routes...
>
> Instead of running the garbage collection we could flush the route
> cache completely if the neighbor cache overflows.
> But why do we have to cache that routes in first place ?
> See the previous patch which skips caching for that kind of routes.
What are the packets you receive ? A flood of ARP answers ?
a "tcpdump -X" of a few packets would help to understand.
^ permalink raw reply
* Re: [RFC PATCH] dont create cached routes from ARP requests
From: Ulrich Weber @ 2010-09-24 15:00 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Ulrich Weber, David Miller, netdev
In-Reply-To: <1285254302.2509.47.camel@edumazet-laptop>
[-- Attachment #1: Type: text/plain, Size: 653 bytes --]
Hi Eric,
please find the output in the attached text file.
Neighbor garbage collection wont't work because all
neighbor records are bound to cached routes.
Forced route garbaged collections returns without freeing
any routes, probably because the route threshold is quite high
with 65536 compared to the small neighbor threshold of 1024,
resulting in a fixed amount of 1024 cached routes...
Instead of running the garbage collection we could flush the route
cache completely if the neighbor cache overflows.
But why do we have to cache that routes in first place ?
See the previous patch which skips caching for that kind of routes.
Cheers
Ulrich
[-- Attachment #2: cache_debug.txt --]
[-- Type: text/plain, Size: 8009 bytes --]
/proc/sys/net/ipv4/route/error_burst:1250
/proc/sys/net/ipv4/route/error_cost:250
/proc/sys/net/ipv4/route/gc_elasticity:8
/proc/sys/net/ipv4/route/gc_interval:60
/proc/sys/net/ipv4/route/gc_min_interval:0
/proc/sys/net/ipv4/route/gc_min_interval_ms:500
/proc/sys/net/ipv4/route/gc_thresh:65536
/proc/sys/net/ipv4/route/gc_timeout:300
/proc/sys/net/ipv4/route/max_size:1048576
/proc/sys/net/ipv4/route/min_adv_mss:256
/proc/sys/net/ipv4/route/min_pmtu:552
/proc/sys/net/ipv4/route/mtu_expires:600
/proc/sys/net/ipv4/route/redirect_load:5
/proc/sys/net/ipv4/route/redirect_number:9
/proc/sys/net/ipv4/route/redirect_silence:5120
/proc/sys/net/ipv4/neigh/default/gc_interval:30
/proc/sys/net/ipv4/neigh/default/gc_stale_time:60
/proc/sys/net/ipv4/neigh/default/gc_thresh1:128
/proc/sys/net/ipv4/neigh/default/gc_thresh2:512
/proc/sys/net/ipv4/neigh/default/gc_thresh3:1024
net-next:
rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|
entries| in_hit|in_slow_|in_slow_|in_no_ro| in_brd|in_marti|in_marti| out_hit|out_slow|out_slow|gc_total|gc_ignor|gc_goal_|gc_dst_o|in_hlist|out_hlis|
| | tot| mc| ute| | an_dst| an_src| | _tot| _mc| | ed| miss| verflow| _search|t_search|
10| 255| 2| 1| 0| 0| 0| 0| 128| 17| 2| 0| 0| 0| 0| 15| 3|
199| 1| 189| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0|
433| 190| 234| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0|
433| 424| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 1| 0|
433| 235| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0|
533| 119| 100| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 1| 0|
533| 219| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0|
533| 219| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0|
551| 406| 18| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0|
551| 424| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0|
551| 424| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0|
973| 1| 422| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 9| 0|
973| 423| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0|
973| 423| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0|
1030| 357| 68| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0|
1030| 413| 11| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0|
1030| 413| 11| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0|
1030| 124| 300| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0|
1030| 124| 300| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0|
1030| 125| 300| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0|
next-next with forced rt_garbage_collect
rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|
entries| in_hit|in_slow_|in_slow_|in_no_ro| in_brd|in_marti|in_marti| out_hit|out_slow|out_slow|gc_total|gc_ignor|gc_goal_|gc_dst_o|in_hlist|out_hlis|
| | tot| mc| ute| | an_dst| an_src| | _tot| _mc| | ed| miss| verflow| _search|t_search|
8| 43| 2| 0| 0| 0| 0| 0| 129| 20| 3| 0| 0| 0| 0| 1| 1|
138| 1| 130| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0|
431| 131| 293| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 3| 0|
431| 424| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 3| 0|
431| 294| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 3| 0|
531| 120| 100| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0|
531| 220| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0|
531| 220| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0|
550| 405| 19| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 3| 0|
550| 424| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 3| 0|
550| 424| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 3| 0|
972| 1| 422| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 1| 0|
972| 423| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 1| 0|
972| 423| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 1| 0|
1029| 358| 66| 0| 0| 0| 0| 0| 0| 0| 0| 9| 0| 0| 0| 1| 0|
1029| 415| 9| 0| 0| 0| 0| 0| 0| 0| 0| 9| 0| 0| 0| 1| 0|
1029| 415| 9| 0| 0| 0| 0| 0| 0| 0| 0| 9| 0| 0| 0| 1| 0|
1029| 122| 302| 0| 0| 0| 0| 0| 0| 0| 0| 302| 0| 0| 0| 2| 0|
1029| 122| 302| 0| 0| 0| 0| 0| 0| 0| 0| 302| 0| 0| 0| 2| 0|
1029| 122| 302| 0| 0| 0| 0| 0| 0| 0| 0| 302| 0| 0| 0| 2| 0|
^ permalink raw reply
* Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support
From: Alan Cox @ 2010-09-24 14:57 UTC (permalink / raw)
To: Richard Cochran
Cc: john stultz, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
netdev-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, Christoph Lameter,
David Miller, Krzysztof Halasa, Peter Zijlstra, Rodolfo Giometti,
Thomas Gleixner
In-Reply-To: <20100924135001.GB3113-7KxsofuKt4IfAd9E5cN8NEzG7cXyKsk/@public.gmane.org>
> > Instead, I think having the id hanging off the class driver is much
> > better, as it allows mapping the actual hardware to the id more clearly.
> >
> > So I'd drop the "timesource" listing. And maybe change "id" to
> > "clock_id" so its a little more clear what the id is for.
>
> Okay, I will drop /sys/class/timesource (hope Alan Cox agrees :)
It makes sense to hang anything off the physical id
> I threw it out there mostly for the sake of discussion. I imagined
> that there could be other properties in that directory, like time
> scale (TAI, UTC, etc). But it seems like we don't really need anything
> in that direction.
They can still hang off the physical device. Thats really a detail
> > interrupts are awfully frequent, so systems concerned with power-saving
> > and deep idles probably would like something that could be done at a
> > more coarse interval.
>
> We could always make the pulse rate programmable, for power-saving
> applications.
I would expect the kernel drivers to be responsible for
- Turning off when they can
- Picking rates that are power optimal for the requirement
The latter is a bit interesting as I don't see anything in any of the
timer APIs to express accuracy (a problem we have in kernel too).
Historically it simply hasn't mattered.
^ permalink raw reply
* Re: [PATCH 1/2] Phonet: Implement Pipe Controller to support Nokia Slim Modems
From: Kumar SANGHVI @ 2010-09-24 14:20 UTC (permalink / raw)
To: Eric Dumazet
Cc: remi.denis-courmont@nokia.com, davem@davemloft.net,
netdev@vger.kernel.org, STEricsson_nomadik_linux,
Sudeep DIVAKARAN, Gulshan KARMANI, Linus WALLEIJ
In-Reply-To: <1285336333.2503.153.camel@edumazet-laptop>
Hi Eric,
On Fri, Sep 24, 2010 at 15:52:13 +0200, Eric Dumazet wrote:
> Le vendredi 24 septembre 2010 à 17:53 +0530, Kumar A Sanghvi a écrit :
>
> > +static int pipe_get_flow_info(struct sock *sk, struct sk_buff *skb,
> > + u8 *pref_rx_fc, u8 *req_tx_fc)
> > +{
> > + struct pnpipehdr *hdr = pnp_hdr(skb);
> > + u8 n_sb;
> > +
> > + if (!pskb_may_pull(skb, sizeof(*hdr) + 4))
> > + return -EINVAL;
>
> This is wrong.
>
> pskb_may_pull() might change skb->data, so you should do
>
> {
> struct pnpipehdr *hdr;
> u8 n_sb;
>
> if (!pskb_may_pull(skb, sizeof(*hdr) + 4))
> return -EINVAL;
>
> hdr = pnp_hdr(skb);
>
Thanks for pointing this out.
I will correct this and post a v2 version of patch.
I will also post a fix for similar problem which now I noticed, based on
your above comment, in pipe_rcv_status function in net/phonet/pep.c
Best regards,
Kumar.
^ permalink raw reply
* Re: [PATCH 7/8] net: Allow setting the network namespace by fd
From: jamal @ 2010-09-24 14:16 UTC (permalink / raw)
To: David Lamparter
Cc: Eric W. Biederman, linux-kernel, Linux Containers, netdev,
netfilter-devel, linux-fsdevel
In-Reply-To: <20100924140943.GB1551619@jupiter.n2.diac24.net>
On Fri, 2010-09-24 at 16:09 +0200, David Lamparter wrote:
> I understood your point. What I'm saying is that that functional graph
> you're describing is too simplistic do be a workable model. Your graph
> allows for what you're trying to do, yes. But your graph is not modeling
> the reality.
How about we put this specific point to rest by agreeing to
disagree? ;->
> Err... I'm migrating netdevs to assign them to namespaces to allow them
> to use them? Setup, basically. Either way a device move only happens as
> result of some administrative action; be it creating a new namespace or
> changing the physical/logical network setup.
>
Ok, different need. You have a much more basic requirement than i do.
> wtf is a "remote" namespace?
>
A namespace that is remotely located on another machine/hardware ;->
> Can you please describe your application that requires moving possibly
> several network devices together with "their" routes to a different
> namespace?
scaling and availability are the driving requirements.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 7/8] net: Allow setting the network namespace by fd
From: David Lamparter @ 2010-09-24 14:09 UTC (permalink / raw)
To: jamal
Cc: David Lamparter, Eric W. Biederman, linux-kernel,
Linux Containers, netdev, netfilter-devel, linux-fsdevel
In-Reply-To: <1285335173.13976.693.camel@bigi>
On Fri, Sep 24, 2010 at 09:32:53AM -0400, jamal wrote:
> On Fri, 2010-09-24 at 14:57 +0200, David Lamparter wrote:
> > No. While you sure could associate routes with devices, they don't
> > *functionally* reside on top of network devices. They reside on top of
> > the entire IP configuration,
>
> I think i am not clearly making my point. There are data dependencies;
> If you were to move routes, youd need everything that routes depend on.
> IOW, if i was to draw a functional graph, routes would appear on top
> of netdevs (I dont care what other functional blocks you put in between
> or sideways to them).
I understood your point. What I'm saying is that that functional graph
you're describing is too simplistic do be a workable model. Your graph
allows for what you're trying to do, yes. But your graph is not modeling
the reality.
> > The routes depend on your BGP view, and
> > if your set of interfaces (and peers) changes, your routes will change.
> > Your bgpd will, either way, need to set up new peerings and redo best
> > path evaluations.
>
> Worst case scenario, yes. I am beginning to get a feeling we are trying
> to achieve different goals maybe? Why are you even migrating netdevs?
Err... I'm migrating netdevs to assign them to namespaces to allow them
to use them? Setup, basically. Either way a device move only happens as
result of some administrative action; be it creating a new namespace or
changing the physical/logical network setup.
> > (On an unrelated note, how often are you planning to move stuff between
> > namespaces? I don't expect to be moving stuff except on configuration
> > events...)
>
> Triggering on config events is useful and it is likely the only
> possibility if you assumed the other namespace is remote.
wtf is a "remote" namespace?
> But if could
> send a single command to migrate several things in the kernel (in my
> case to recover state to a different ns), then that is much simpler and
> uses the least resources (memory, cpu, bandwidth). I admit it is very
> hard to do in most cases where the underlying dependencies are evolving
> and synchronizing via user space is the best approach. The example
> of route table i pointed to is simple.
> Besides that: dynamic state created in the kernel that doesnt have to be
> recreated by the next arriving 100K packets helps to improve recovery.
Can you please describe your application that requires moving possibly
several network devices together with "their" routes to a different
namespace?
-David
^ permalink raw reply
* Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support
From: Alan Cox @ 2010-09-24 14:07 UTC (permalink / raw)
To: Alan Cox
Cc: John Stultz, Rodolfo Giometti, Arnd Bergmann, Peter Zijlstra,
linux-api, devicetree-discuss, linux-kernel, David Miller,
Thomas Gleixner, netdev, Christoph Lameter, linuxppc-dev,
Richard Cochran, linux-arm-kernel, Krzysztof Halasa
In-Reply-To: <20100924150246.0e6064b6@lxorguk.ukuu.org.uk>
> You can't do that avoiding as you might like because the behaviour of
> file handle numbering is defined by the standards. Hence the "f*"
> versions of the calls (and of lots of other stuff)
>
> Whether you add new syscalls or do the fd passing using flags and hide
> the ugly bits in glibc is another question.
To add an example of what I mean you might end up defining "CLOCK_FD" to
indicate to use the fd in the struct, but given syscalls are trivial
codewise and would end up as
fclock_foo(int fd, blah)
{
clock = fd_to_clock(fd);
if (error)
return error
clock_do_foo(clock, blah);
clock_put(clock);
}
and
clock_foo(int posixid, blah)
{
clock = posix_to_clock(posixid)
...
rest same
}
as wrappers it seems hardly worth adding ugly hacks
^ permalink raw reply
* Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support
From: Alan Cox @ 2010-09-24 14:02 UTC (permalink / raw)
To: Richard Cochran
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
netdev-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, Christoph Lameter,
David Miller, John Stultz, Krzysztof Halasa, Peter Zijlstra,
Rodolfo Giometti, Thomas Gleixner
In-Reply-To: <20100924131407.GA3113-7KxsofuKt4IfAd9E5cN8NEzG7cXyKsk/@public.gmane.org>
On Fri, 24 Sep 2010 15:14:07 +0200
Richard Cochran <richardcochran-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thu, Sep 23, 2010 at 09:36:54PM +0100, Alan Cox wrote:
> > Drop the clockid_t and swap it for a file handle like a proper Unix or
> > Linux interface. The rest is much the same
> >
> > fd = open /sys/class/timesource/[whatever]
> >
> > various queries you may want to do to check the name etc
> >
> > fclock_adjtime(fd, ...)
>
> Okay, but lets extend the story:
>
> clock_getttime(fd, ...);
>
> clock_settime(fd, ...);
>
> timer_create(fd, ...);
>
> Can you agree to that as well?
>
> (We would need to ensure that 'fd' avoids the range 0 to MAX_CLOCKS).
You can't do that avoiding as you might like because the behaviour of
file handle numbering is defined by the standards. Hence the "f*"
versions of the calls (and of lots of other stuff)
Whether you add new syscalls or do the fd passing using flags and hide
the ugly bits in glibc is another question.
^ permalink raw reply
* Re: [PATCH 1/2] Phonet: Implement Pipe Controller to support Nokia Slim Modems
From: Eric Dumazet @ 2010-09-24 13:52 UTC (permalink / raw)
To: Kumar A Sanghvi
Cc: remi.denis-courmont, davem, netdev, STEricsson_nomadik_linux,
sudeep.divakaran, gulshan.karmani, Linus Walleij
In-Reply-To: <1285330996-27076-2-git-send-email-kumar.sanghvi@stericsson.com>
Le vendredi 24 septembre 2010 à 17:53 +0530, Kumar A Sanghvi a écrit :
> +static int pipe_get_flow_info(struct sock *sk, struct sk_buff *skb,
> + u8 *pref_rx_fc, u8 *req_tx_fc)
> +{
> + struct pnpipehdr *hdr = pnp_hdr(skb);
> + u8 n_sb;
> +
> + if (!pskb_may_pull(skb, sizeof(*hdr) + 4))
> + return -EINVAL;
This is wrong.
pskb_may_pull() might change skb->data, so you should do
{
struct pnpipehdr *hdr;
u8 n_sb;
if (!pskb_may_pull(skb, sizeof(*hdr) + 4))
return -EINVAL;
hdr = pnp_hdr(skb);
...
^ permalink raw reply
* Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support
From: Richard Cochran @ 2010-09-24 13:50 UTC (permalink / raw)
To: john stultz
Cc: Rodolfo Giometti, Peter Zijlstra,
linux-api-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Thomas Gleixner,
netdev-u79uwXL29TY76Z2rM5mHXA, Christoph Lameter,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, David Miller,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Krzysztof Halasa
In-Reply-To: <1285270733.2587.46.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
On Thu, Sep 23, 2010 at 12:38:53PM -0700, john stultz wrote:
> On Thu, 2010-09-23 at 19:30 +0200, Richard Cochran wrote:
> > /sys/class/timesource/<name>/id
> > /sys/class/ptp/ptp_clock_X/id
> >
> So yea, I'm not a fan of the "timesource" sysfs interface. One, I think
> the name is poor (posix_clocks or something a little more specific would
> be an improvement), and second, I don't like the dictionary interface,
> where one looks up the clock by name.
>
> Instead, I think having the id hanging off the class driver is much
> better, as it allows mapping the actual hardware to the id more clearly.
>
> So I'd drop the "timesource" listing. And maybe change "id" to
> "clock_id" so its a little more clear what the id is for.
Okay, I will drop /sys/class/timesource (hope Alan Cox agrees :)
I threw it out there mostly for the sake of discussion. I imagined
that there could be other properties in that directory, like time
scale (TAI, UTC, etc). But it seems like we don't really need anything
in that direction.
> > 3.3 Synchronizing the Linux System Time
> > ========================================
> >
> > One could offer a PHC as a combined clock source and clock event
> > device. The advantage of this approach would be that it obviates
> > the need for synchronization when the PHC is selected as the system
> > timer. However, some PHCs, namely the PHY based clocks, cannot be
> > used in this way.
>
> Again, I'd scratch this.
Okay, I only wanted to preempt the question which people are asking
all the time: why can't it work with the system clock transparently?
> > Instead, the patch set provides a way to offer a Pulse Per Second
> > (PPS) event from the PHC to the Linux PPS subsystem. A user space
> > application can read the PPS events and tune the system clock, just
> > like when using other external time sources like radio clocks or
> > GPS.
>
> Forgive me for a bit of a tangent here:
> So while I think this PPS method is a neat idea, I'm a little curious
> how much of a difference the PPS method for syncing the clock would be
> over just a simple reading of the two clocks and correcting the offset.
>
> It seems much of it depends on the read latency of the PTP hardware vs
> the interrupt latency. Also the PTP clock granularity would effect the
> read accuracy (like on the RTC, you don't really know how close to the
> second boundary you are).
>
> Have you done any such measurements between the two methods?
I have not yet tested how well the PPS method works, but I expect at
least as good results as when using a GPS.
> I just
> wonder if it would actually be something noticeable, and if its not, how
> much lighter this patch-set would be without the PPS connection.
As you say, the problem with just reading two clocks at nearly the
same time is that you have two uncertain operations. If you use a PPS,
then there is only one clock to read, and that clock is the system
clock, which hopefully is not too slow to read!
In addition, PHY reads can sleep, and that surely won't work. Even with
MAC PHCs, reading outside of interrupt context makes you vulnerable to
other interrupts.
> Again, this isn't super critical, just trying to make sure we don't end
> up adding a bunch of code that doesn't end up being used.
The PPS hooks are really only just a few lines of code.
The great advantage of a PPS approach over and ad-hoc "read two clocks
and compare", is that, with a steady, known sample rate, you can
analyze and predict your control loop behavior. There is lots of
literature available on how to do it. IMHO, that is the big weakness
of the timecompare.c stuff used in the current IGB driver.
> Also PPS
> interrupts are awfully frequent, so systems concerned with power-saving
> and deep idles probably would like something that could be done at a
> more coarse interval.
We could always make the pulse rate programmable, for power-saving
applications.
> > 4.1 Supported Hardware Clocks
> > ==============================
> >
> > + Standard Linux system timer
> > This driver exports the standard Linux timer as a PTP clock.
> > Although this duplicates CLOCK_REALTIME, the code serves as a
> > simple example for driver development and lets people who without
> > special hardware try the new API.
>
> Still not a fan of this one, figure the app should handle the special
> case where there are no PTP clocks and just use CLOCK_REALTIME rather
> then funneling CLOCK_REALTIME through the PTP interface.
It is really just as an example and for people who want to test driver
the API. It can surely be removed before the final version...
Thanks for your comments,
Richard
^ permalink raw reply
* Re: [ABI REVIEW][PATCH 0/8] Namespace file descriptors
From: Daniel Lezcano @ 2010-09-24 13:49 UTC (permalink / raw)
To: Andrew Lutomirski
Cc: Eric W. Biederman, Sukadev Bhattiprolu, Pavel Emelyanov,
Pavel Emelyanov, Ulrich Drepper, netdev, Jonathan Corbet,
linux-kernel, Jan Engelhardt, linux-fsdevel, netfilter-devel,
Michael Kerrisk, Linux Containers, Ben Greear, Linus Torvalds,
David Miller, Al Viro
In-Reply-To: <4C9CA16F.3000505@mit.edu>
On 09/24/2010 03:02 PM, Andrew Lutomirski wrote:
> Eric W. Biederman wrote:
>> Introduce file for manipulating namespaces and related syscalls.
>> files:
>> /proc/self/ns/<nstype>
>>
>> syscalls:
>> int setns(unsigned long nstype, int fd);
>> socketat(int nsfd, int family, int type, int protocol);
>>
>
> How does security work? Are there different kinds of fd that give (say) pin-the-namespace permission, socketat permission, and setns permission?
AFAICS, socketat, setns and "set netns by fd" only accept fd from
/proc/<pid>/ns/<ns>.
setns does :
file = proc_ns_fget(fd);
if (IS_ERR(file))
return PTR_ERR(file);
proc_ns_fget checks if (file->f_op != &ns_file_operations)
socketat and get_net_ns_by_fd:
net = get_net_ns_by_fd(fd);
this one calls proc_ns_fget.
We have the guarantee here, the fd is resulting from an open of the file
with the right permissions.
Another way to pin the namespace, would be to mount --bind
/proc/<pid>/ns/<ns> but we have to be root to do that ...
^ permalink raw reply
* Re: [PATCH 7/8] net: Allow setting the network namespace by fd
From: Daniel Lezcano @ 2010-09-24 13:46 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Pavel Emelyanov, Ulrich Drepper, netdev-u79uwXL29TY76Z2rM5mHXA,
Jonathan Corbet, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Jan Engelhardt, Linux Containers, Al Viro,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA, Michael Kerrisk,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA, Ben Greear,
Sukadev Bhattiprolu, Linus Torvalds, David Miller,
Pavel Emelyanov
In-Reply-To: <m1hbhgq1v1.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
On 09/23/2010 10:51 AM, Eric W. Biederman wrote:
>
> Take advantage of the new abstraction and allow network devices
> to be placed in any network namespace that we have a fd to talk
> about.
>
> Signed-off-by: Eric W. Biederman<ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
> ---
[ ... ]
> +struct net *get_net_ns_by_fd(int fd)
> +{
> + struct proc_inode *ei;
> + struct file *file;
> + struct net *net;
> +
> + file = NULL;
> + net = ERR_PTR(-EINVAL);
> + file = proc_ns_fget(fd);
> + if (!fd)
> + goto out;
> + return ERR_PTR(-EINVAL);
> +
> + ei = PROC_I(file->f_dentry->d_inode);
> + if (ei->ns_ops !=&netns_operations)
> + goto out;
Is this check necessary here ? proc_ns_fget checks "file->f_op !=
&ns_file_operations", no ?
^ permalink raw reply
* Re: [PATCH 7/8] net: Allow setting the network namespace by fd
From: jamal @ 2010-09-24 13:32 UTC (permalink / raw)
To: David Lamparter
Cc: Eric W. Biederman, linux-kernel, Linux Containers, netdev,
netfilter-devel, linux-fsdevel
In-Reply-To: <20100924125704.GA1551619@jupiter.n2.diac24.net>
On Fri, 2010-09-24 at 14:57 +0200, David Lamparter wrote:
> No. While you sure could associate routes with devices, they don't
> *functionally* reside on top of network devices. They reside on top of
> the entire IP configuration,
I think i am not clearly making my point. There are data dependencies;
If you were to move routes, youd need everything that routes depend on.
IOW, if i was to draw a functional graph, routes would appear on top
of netdevs (I dont care what other functional blocks you put in between
or sideways to them).
> and in case of BGP they even reside on top
> of your set of peerings and their data.
> Even if you could "move" routes together with a network device, the
> result would be utter nonsense.
You could argue that moving a netdevice where some of its fundamental
properties such as an ifindex change is utter nonsense. But you can
work around it.
> The routes depend on your BGP view, and
> if your set of interfaces (and peers) changes, your routes will change.
> Your bgpd will, either way, need to set up new peerings and redo best
> path evaluations.
Worst case scenario, yes. I am beginning to get a feeling we are trying
to achieve different goals maybe? Why are you even migrating netdevs?
> (On an unrelated note, how often are you planning to move stuff between
> namespaces? I don't expect to be moving stuff except on configuration
> events...)
Triggering on config events is useful and it is likely the only
possibility if you assumed the other namespace is remote. But if could
send a single command to migrate several things in the kernel (in my
case to recover state to a different ns), then that is much simpler and
uses the least resources (memory, cpu, bandwidth). I admit it is very
hard to do in most cases where the underlying dependencies are evolving
and synchronizing via user space is the best approach. The example
of route table i pointed to is simple.
Besides that: dynamic state created in the kernel that doesnt have to be
recreated by the next arriving 100K packets helps to improve recovery.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support
From: Richard Cochran @ 2010-09-24 13:14 UTC (permalink / raw)
To: Alan Cox
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
netdev-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, Christoph Lameter,
David Miller, John Stultz, Krzysztof Halasa, Peter Zijlstra,
Rodolfo Giometti, Thomas Gleixner
In-Reply-To: <20100923213654.0c64b047-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>
On Thu, Sep 23, 2010 at 09:36:54PM +0100, Alan Cox wrote:
> Drop the clockid_t and swap it for a file handle like a proper Unix or
> Linux interface. The rest is much the same
>
> fd = open /sys/class/timesource/[whatever]
>
> various queries you may want to do to check the name etc
>
> fclock_adjtime(fd, ...)
Okay, but lets extend the story:
clock_getttime(fd, ...);
clock_settime(fd, ...);
timer_create(fd, ...);
Can you agree to that as well?
(We would need to ensure that 'fd' avoids the range 0 to MAX_CLOCKS).
Richard
^ permalink raw reply
* Re: [ABI REVIEW][PATCH 0/8] Namespace file descriptors
From: Andrew Lutomirski @ 2010-09-24 13:02 UTC (permalink / raw)
To: Eric W. Biederman
Cc: linux-kernel, Linux Containers, netdev, netfilter-devel,
linux-fsdevel, jamal, Daniel Lezcano, Linus Torvalds,
Michael Kerrisk, Ulrich Drepper, Al Viro, David Miller,
Serge E. Hallyn, Pavel Emelyanov, Pavel Emelyanov, Ben Greear,
Matt Helsley, Jonathan Corbet, Sukadev Bhattiprolu,
Jan Engelhardt, Patrick McHardy
In-Reply-To: <m1ocborgq7.fsf@fess.ebiederm.org>
Eric W. Biederman wrote:
> Introduce file for manipulating namespaces and related syscalls.
> files:
> /proc/self/ns/<nstype>
>
> syscalls:
> int setns(unsigned long nstype, int fd);
> socketat(int nsfd, int family, int type, int protocol);
>
How does security work? Are there different kinds of fd that give (say) pin-the-namespace permission, socketat permission, and setns permission?
--Andy
> Netlink attribute:
> IFLA_NS_FD int fd.
>
> Name space file descriptors address three specific problems that
> can make namespaces hard to work with.
> - Namespaces require a dedicated process to pin them in memory.
> - It is not possible to use a namespace unless you are the child of the
> original creator.
> - Namespaces don't have names that userspace can use to talk about them.
>
> Opening of the /proc/self/ns/<nstype> files return a file descriptor
> that can be used to talk about a specific namespace, and to keep the
> specified namespace alive.
>
> /proc/self/ns/<nstype> can be bind mounted as:
> mount --bind /proc/self/ns/net /some/filesystem/path
> to keep the namespace alive as long as the mount exists.
>
> setns() as a companion to unshare allows changing the namespace
> of the current process, being able to unshare the namespace is
> a requirement.
>
> There are two primary envisioned uses for this functionality.
> o ``Entering'' an existing container.
> o Allowing multiple network namespaces to be in use at once on
> the same machine, without requiring elaborate infrastructure.
>
> Overall this received positive reviews on the containers list but this
> needs a wider review of the ABI as this is pretty fundamental kernel
> functionality.
>
>
> I have left out the pid namespaces bits for the moment because the pid
> namespace still needs work before it is safe to unshare, and my concern
> at the moment is ensuring the system calls seem reasonable.
>
> Eric W. Biederman (8):
> ns: proc files for namespace naming policy.
> ns: Introduce the setns syscall
> ns proc: Add support for the network namespace.
> ns proc: Add support for the uts namespace
> ns proc: Add support for the ipc namespace
> ns proc: Add support for the mount namespace
> net: Allow setting the network namespace by fd
> net: Implement socketat.
>
> ---
> fs/namespace.c | 57 +++++++++++++
> fs/proc/Makefile | 1 +
> fs/proc/base.c | 22 +++---
> fs/proc/inode.c | 7 ++
> fs/proc/internal.h | 18 ++++
> fs/proc/namespaces.c | 193 +++++++++++++++++++++++++++++++++++++++++++
> include/linux/if_link.h | 1 +
> include/linux/proc_fs.h | 20 +++++
> include/net/net_namespace.h | 1 +
> ipc/namespace.c | 31 +++++++
> kernel/nsproxy.c | 39 +++++++++
> kernel/utsname.c | 32 +++++++
> net/core/net_namespace.c | 56 +++++++++++++
> net/core/rtnetlink.c | 4 +-
> net/socket.c | 26 ++++++-
> 15 files changed, 494 insertions(+), 14 deletions(-)
>
^ permalink raw reply
* Re: [PATCH 7/8] net: Allow setting the network namespace by fd
From: David Lamparter @ 2010-09-24 12:57 UTC (permalink / raw)
To: jamal
Cc: David Lamparter, Eric W. Biederman, linux-kernel,
Linux Containers, netdev, netfilter-devel, linux-fsdevel
In-Reply-To: <1285329084.13976.661.camel@bigi>
On Fri, Sep 24, 2010 at 07:51:24AM -0400, jamal wrote:
> > migrating route table entries makes no sense because
> > a) they refer to devices and configuration that does not exist in the
> > target namespace; they only make sense within their netns context
> > b) they are purely virtual and you get the same result from deleting and
> > recreating them.
> >
> > Network devices are special because they may have something attached to
> > them, be it hardware or some daemon.
>
> Routes functionally reside on top of netdevices, point to nexthop
> neighbors across these netdevices etc. Underlying assumption is you take
> care of that dependency when migrating.
> We are talking about FIB entries here not the route cache; moving a few
> pointers within the kernel is a hell lot faster than recreating a subset
> of BGP entries from user space.
No. While you sure could associate routes with devices, they don't
*functionally* reside on top of network devices. They reside on top of
the entire IP configuration, and in case of BGP they even reside on top
of your set of peerings and their data.
Even if you could "move" routes together with a network device, the
result would be utter nonsense. The routes depend on your BGP view, and
if your set of interfaces (and peers) changes, your routes will change.
Your bgpd will, either way, need to set up new peerings and redo best
path evaluations.
(On an unrelated note, how often are you planning to move stuff between
namespaces? I don't expect to be moving stuff except on configuration
events...)
-David
^ permalink raw reply
* [PATCH 1/2] Phonet: Implement Pipe Controller to support Nokia Slim Modems
From: Kumar A Sanghvi @ 2010-09-24 12:23 UTC (permalink / raw)
To: remi.denis-courmont, davem, netdev
Cc: STEricsson_nomadik_linux, sudeep.divakaran, gulshan.karmani,
Kumar Sanghvi, Linus Walleij
In-Reply-To: <1285330996-27076-1-git-send-email-kumar.sanghvi@stericsson.com>
From: Kumar Sanghvi <kumar.sanghvi@stericsson.com>
Phonet stack assumes the presence of Pipe Controller, either in Modem or
on Application Processing Engine user-space for the Pipe data.
Nokia Slim Modems like WG2.5 used in ST-Ericsson U8500 platform do not
implement Pipe controller in them.
This patch adds Pipe Controller implemenation to Phonet stack to support
Pipe data over Phonet stack for Nokia Slim Modems.
Signed-off-by: Kumar Sanghvi <kumar.sanghvi@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@stericsson.com>
---
include/linux/phonet.h | 5 +
include/net/phonet/pep.h | 21 +++
net/phonet/Kconfig | 11 ++
net/phonet/pep.c | 447 +++++++++++++++++++++++++++++++++++++++++++++-
4 files changed, 478 insertions(+), 6 deletions(-)
diff --git a/include/linux/phonet.h b/include/linux/phonet.h
index 85e14a8..96f5625 100644
--- a/include/linux/phonet.h
+++ b/include/linux/phonet.h
@@ -36,6 +36,11 @@
/* Socket options for SOL_PNPIPE level */
#define PNPIPE_ENCAP 1
#define PNPIPE_IFINDEX 2
+#define PNPIPE_CREATE 3
+#define PNPIPE_ENABLE 4
+#define PNPIPE_DISABLE 5
+#define PNPIPE_DESTROY 6
+#define PNPIPE_INQ 7
#define PNADDR_ANY 0
#define PNADDR_BROADCAST 0xFC
diff --git a/include/net/phonet/pep.h b/include/net/phonet/pep.h
index 37f23dc..def6cfa 100644
--- a/include/net/phonet/pep.h
+++ b/include/net/phonet/pep.h
@@ -45,6 +45,10 @@ struct pep_sock {
u8 tx_fc; /* TX flow control */
u8 init_enable; /* auto-enable at creation */
u8 aligned;
+#ifdef CONFIG_PHONET_PIPECTRLR
+ u16 remote_pep;
+ u8 pipe_state;
+#endif
};
static inline struct pep_sock *pep_sk(struct sock *sk)
@@ -165,4 +169,21 @@ enum {
PEP_IND_READY,
};
+#ifdef CONFIG_PHONET_PIPECTRLR
+#define PNS_PEP_CONNECT_UTID 0x02
+#define PNS_PIPE_CREATED_IND_UTID 0x04
+#define PNS_PIPE_ENABLE_UTID 0x0A
+#define PNS_PIPE_ENABLED_IND_UTID 0x0C
+#define PNS_PIPE_DISABLE_UTID 0x0F
+#define PNS_PIPE_DISABLED_IND_UTID 0x11
+#define PNS_PEP_DISCONNECT_UTID 0x06
+
+/* Used for tracking state of a pipe */
+enum {
+ PIPE_IDLE,
+ PIPE_DISABLED,
+ PIPE_ENABLED,
+};
+#endif /* CONFIG_PHONET_PIPECTRLR */
+
#endif
diff --git a/net/phonet/Kconfig b/net/phonet/Kconfig
index 6ec7d55..901956a 100644
--- a/net/phonet/Kconfig
+++ b/net/phonet/Kconfig
@@ -14,3 +14,14 @@ config PHONET
To compile this driver as a module, choose M here: the module
will be called phonet. If unsure, say N.
+
+config PHONET_PIPECTRLR
+ bool "Phonet Pipe Controller"
+ depends on PHONET
+ default N
+ help
+ The Pipe Controller implementation in Phonet stack to support Pipe
+ data with Nokia Slim modems like WG2.5 used on ST-Ericsson U8500
+ platform.
+
+ If unsure, say N.
diff --git a/net/phonet/pep.c b/net/phonet/pep.c
index d0e7eb2..02f60b0 100644
--- a/net/phonet/pep.c
+++ b/net/phonet/pep.c
@@ -88,6 +88,15 @@ static int pep_reply(struct sock *sk, struct sk_buff *oskb,
const struct pnpipehdr *oph = pnp_hdr(oskb);
struct pnpipehdr *ph;
struct sk_buff *skb;
+#ifdef CONFIG_PHONET_PIPECTRLR
+ const struct phonethdr *hdr = pn_hdr(oskb);
+ struct sockaddr_pn spn = {
+ .spn_family = AF_PHONET,
+ .spn_resource = 0xD9,
+ .spn_dev = hdr->pn_sdev,
+ .spn_obj = hdr->pn_sobj,
+ };
+#endif
skb = alloc_skb(MAX_PNPIPE_HEADER + len, priority);
if (!skb)
@@ -105,10 +114,270 @@ static int pep_reply(struct sock *sk, struct sk_buff *oskb,
ph->pipe_handle = oph->pipe_handle;
ph->error_code = code;
+#ifdef CONFIG_PHONET_PIPECTRLR
+ return pn_skb_send(sk, skb, &spn);
+#else
return pn_skb_send(sk, skb, &pipe_srv);
+#endif
}
#define PAD 0x00
+
+#ifdef CONFIG_PHONET_PIPECTRLR
+static u8 pipe_negotiate_fc(u8 *host_fc, u8 *remote_fc, int len)
+{
+ int i, j;
+ u8 base_fc, final_fc;
+
+ for (i = 0; i < len; i++) {
+ base_fc = host_fc[i];
+ for (j = 0; j < len; j++) {
+ if (remote_fc[j] == base_fc) {
+ final_fc = base_fc;
+ goto done;
+ }
+ }
+ }
+ return -EINVAL;
+
+done:
+ return final_fc;
+
+}
+
+static int pipe_get_flow_info(struct sock *sk, struct sk_buff *skb,
+ u8 *pref_rx_fc, u8 *req_tx_fc)
+{
+ struct pnpipehdr *hdr = pnp_hdr(skb);
+ u8 n_sb;
+
+ if (!pskb_may_pull(skb, sizeof(*hdr) + 4))
+ return -EINVAL;
+
+ n_sb = hdr->data[4];
+
+ __skb_pull(skb, sizeof(*hdr) + 4);
+ while (n_sb > 0) {
+ u8 type, buf[3], len = sizeof(buf);
+ u8 *data = pep_get_sb(skb, &type, &len, buf);
+
+ if (data == NULL)
+ return -EINVAL;
+
+ switch (type) {
+ case PN_PIPE_SB_REQUIRED_FC_TX:
+ if (len < 3 || (data[2] | data[3] | data[4]) > 3)
+ break;
+ req_tx_fc[0] = data[2];
+ req_tx_fc[1] = data[3];
+ req_tx_fc[2] = data[4];
+ break;
+
+ case PN_PIPE_SB_PREFERRED_FC_RX:
+ if (len < 3 || (data[2] | data[3] | data[4]) > 3)
+ break;
+ pref_rx_fc[0] = data[2];
+ pref_rx_fc[1] = data[3];
+ pref_rx_fc[2] = data[4];
+ break;
+
+ }
+ n_sb--;
+ }
+ return 0;
+}
+
+static int pipe_handler_send_req(struct sock *sk, u16 dobj, u8 utid,
+ u8 msg_id, u8 p_handle, gfp_t priority)
+{
+ int len;
+ struct pnpipehdr *ph;
+ struct sk_buff *skb;
+ struct sockaddr_pn spn = {
+ .spn_family = AF_PHONET,
+ .spn_resource = 0xD9,
+ .spn_dev = pn_dev(dobj),
+ .spn_obj = pn_obj(dobj),
+ };
+
+ static const u8 data[4] = {
+ PAD, PAD, PAD, PAD,
+ };
+
+ switch (msg_id) {
+ case PNS_PEP_CONNECT_REQ:
+ len = sizeof(data);
+ break;
+
+ case PNS_PEP_DISCONNECT_REQ:
+ case PNS_PEP_ENABLE_REQ:
+ case PNS_PEP_DISABLE_REQ:
+ len = 0;
+ break;
+
+ default:
+ return -EINVAL;
+ }
+
+ skb = alloc_skb(MAX_PNPIPE_HEADER + len, priority);
+ if (!skb)
+ return -ENOMEM;
+ skb_set_owner_w(skb, sk);
+
+ skb_reserve(skb, MAX_PNPIPE_HEADER);
+ if (len) {
+ __skb_put(skb, len);
+ skb_copy_to_linear_data(skb, data, len);
+ }
+ __skb_push(skb, sizeof(*ph));
+ skb_reset_transport_header(skb);
+ ph = pnp_hdr(skb);
+ ph->utid = utid;
+ ph->message_id = msg_id;
+ ph->pipe_handle = p_handle;
+ ph->error_code = PN_PIPE_NO_ERROR;
+
+ return pn_skb_send(sk, skb, &spn);
+}
+
+static int pipe_handler_send_created_ind(struct sock *sk, u16 dobj,
+ u8 utid, u8 p_handle, u8 msg_id, u8 tx_fc, u8 rx_fc)
+{
+ int err_code;
+ struct pnpipehdr *ph;
+ struct sk_buff *skb;
+ struct sockaddr_pn spn = {
+ .spn_family = AF_PHONET,
+ .spn_resource = 0xD9,
+ .spn_dev = pn_dev(dobj),
+ .spn_obj = pn_obj(dobj),
+ };
+
+ static u8 data[4] = {
+ 0x03, 0x04,
+ };
+ data[2] = tx_fc;
+ data[3] = rx_fc;
+
+ /*
+ * actually, below is number of sub-blocks and not error code.
+ * Pipe_created_ind message format does not have any
+ * error code field. However, the Phonet stack will always send
+ * an error code as part of pnpipehdr. So, use that err_code to
+ * specify the number of sub-blocks.
+ */
+ err_code = 0x01;
+
+ skb = alloc_skb(MAX_PNPIPE_HEADER + sizeof(data), GFP_ATOMIC);
+ if (!skb)
+ return -ENOMEM;
+ skb_set_owner_w(skb, sk);
+
+ skb_reserve(skb, MAX_PNPIPE_HEADER);
+ __skb_put(skb, sizeof(data));
+ skb_copy_to_linear_data(skb, data, sizeof(data));
+ __skb_push(skb, sizeof(*ph));
+ skb_reset_transport_header(skb);
+ ph = pnp_hdr(skb);
+ ph->utid = utid;
+ ph->message_id = msg_id;
+ ph->pipe_handle = p_handle;
+ ph->error_code = err_code;
+
+ return pn_skb_send(sk, skb, &spn);
+}
+
+static int pipe_handler_send_ind(struct sock *sk, u16 dobj, u8 utid,
+ u8 p_handle, u8 msg_id)
+{
+ int err_code;
+ struct pnpipehdr *ph;
+ struct sk_buff *skb;
+ struct sockaddr_pn spn = {
+ .spn_family = AF_PHONET,
+ .spn_resource = 0xD9,
+ .spn_dev = pn_dev(dobj),
+ .spn_obj = pn_obj(dobj),
+ };
+
+ /*
+ * actually, below is a filler.
+ * Pipe_enabled/disabled_ind message format does not have any
+ * error code field. However, the Phonet stack will always send
+ * an error code as part of pnpipehdr. So, use that err_code to
+ * specify the filler value.
+ */
+ err_code = 0x0;
+
+ skb = alloc_skb(MAX_PNPIPE_HEADER, GFP_ATOMIC);
+ if (!skb)
+ return -ENOMEM;
+ skb_set_owner_w(skb, sk);
+
+ skb_reserve(skb, MAX_PNPIPE_HEADER);
+ __skb_push(skb, sizeof(*ph));
+ skb_reset_transport_header(skb);
+ ph = pnp_hdr(skb);
+ ph->utid = utid;
+ ph->message_id = msg_id;
+ ph->pipe_handle = p_handle;
+ ph->error_code = err_code;
+
+ return pn_skb_send(sk, skb, &spn);
+}
+
+static int pipe_handler_enable_pipe(struct sock *sk, int cmd)
+{
+ int ret;
+ struct pep_sock *pn = pep_sk(sk);
+
+ switch (cmd) {
+ case PNPIPE_ENABLE:
+ ret = pipe_handler_send_req(sk, pn->pn_sk.sobject,
+ PNS_PIPE_ENABLE_UTID, PNS_PEP_ENABLE_REQ,
+ pn->pipe_handle, GFP_ATOMIC);
+ break;
+
+ case PNPIPE_DISABLE:
+ ret = pipe_handler_send_req(sk, pn->pn_sk.sobject,
+ PNS_PIPE_DISABLE_UTID, PNS_PEP_DISABLE_REQ,
+ pn->pipe_handle, GFP_ATOMIC);
+ break;
+
+ default:
+ ret = -EINVAL;
+ }
+
+ return ret;
+}
+
+static int pipe_handler_create_pipe(struct sock *sk, int pipe_handle, int cmd)
+{
+ int ret;
+ struct pep_sock *pn = pep_sk(sk);
+
+ switch (cmd) {
+ case PNPIPE_CREATE:
+ ret = pipe_handler_send_req(sk, pn->pn_sk.sobject,
+ PNS_PEP_CONNECT_UTID, PNS_PEP_CONNECT_REQ,
+ pipe_handle, GFP_ATOMIC);
+ break;
+
+ case PNPIPE_DESTROY:
+ ret = pipe_handler_send_req(sk, pn->remote_pep,
+ PNS_PEP_DISCONNECT_UTID,
+ PNS_PEP_DISCONNECT_REQ,
+ pn->pipe_handle, GFP_ATOMIC);
+ break;
+
+ default:
+ ret = -EINVAL;
+ }
+
+ return ret;
+}
+#endif
+
static int pep_accept_conn(struct sock *sk, struct sk_buff *skb)
{
static const u8 data[20] = {
@@ -173,6 +442,14 @@ static int pipe_snd_status(struct sock *sk, u8 type, u8 status, gfp_t priority)
struct pep_sock *pn = pep_sk(sk);
struct pnpipehdr *ph;
struct sk_buff *skb;
+#ifdef CONFIG_PHONET_PIPECTRLR
+ struct sockaddr_pn spn = {
+ .spn_family = AF_PHONET,
+ .spn_resource = 0xD9,
+ .spn_dev = pn_dev(pn->remote_pep),
+ .spn_obj = pn_obj(pn->remote_pep),
+ };
+#endif
skb = alloc_skb(MAX_PNPIPE_HEADER + 4, priority);
if (!skb)
@@ -192,7 +469,11 @@ static int pipe_snd_status(struct sock *sk, u8 type, u8 status, gfp_t priority)
ph->data[3] = PAD;
ph->data[4] = status;
+#ifdef CONFIG_PHONET_PIPECTRLR
+ return pn_skb_send(sk, skb, &spn);
+#else
return pn_skb_send(sk, skb, &pipe_srv);
+#endif
}
/* Send our RX flow control information to the sender.
@@ -308,6 +589,12 @@ static int pipe_do_rcv(struct sock *sk, struct sk_buff *skb)
struct pnpipehdr *hdr = pnp_hdr(skb);
struct sk_buff_head *queue;
int err = 0;
+#ifdef CONFIG_PHONET_PIPECTRLR
+ struct phonethdr *ph = pn_hdr(skb);
+ static u8 host_pref_rx_fc[3], host_req_tx_fc[3];
+ u8 remote_pref_rx_fc[3], remote_req_tx_fc[3];
+ u8 negotiated_rx_fc, negotiated_tx_fc;
+#endif
BUG_ON(sk->sk_state == TCP_CLOSE_WAIT);
@@ -316,6 +603,40 @@ static int pipe_do_rcv(struct sock *sk, struct sk_buff *skb)
pep_reject_conn(sk, skb, PN_PIPE_ERR_PEP_IN_USE);
break;
+#ifdef CONFIG_PHONET_PIPECTRLR
+ case PNS_PEP_CONNECT_RESP:
+ if ((ph->pn_sdev == pn_dev(pn->remote_pep)) &&
+ (ph->pn_sobj == pn_obj(pn->remote_pep))) {
+ pipe_get_flow_info(sk, skb, remote_pref_rx_fc,
+ remote_req_tx_fc);
+
+ negotiated_tx_fc = pipe_negotiate_fc(remote_req_tx_fc,
+ host_pref_rx_fc,
+ sizeof(host_pref_rx_fc));
+ negotiated_rx_fc = pipe_negotiate_fc(host_req_tx_fc,
+ remote_pref_rx_fc,
+ sizeof(host_pref_rx_fc));
+
+ pn->pipe_state = PIPE_DISABLED;
+ pipe_handler_send_created_ind(sk, pn->remote_pep,
+ PNS_PIPE_CREATED_IND_UTID,
+ pn->pipe_handle, PNS_PIPE_CREATED_IND,
+ negotiated_tx_fc, negotiated_rx_fc);
+ pipe_handler_send_created_ind(sk, pn->pn_sk.sobject,
+ PNS_PIPE_CREATED_IND_UTID,
+ pn->pipe_handle, PNS_PIPE_CREATED_IND,
+ negotiated_tx_fc, negotiated_rx_fc);
+ } else {
+ pipe_handler_send_req(sk, pn->remote_pep,
+ PNS_PEP_CONNECT_UTID,
+ PNS_PEP_CONNECT_REQ, pn->pipe_handle,
+ GFP_ATOMIC);
+ pipe_get_flow_info(sk, skb, host_pref_rx_fc,
+ host_req_tx_fc);
+ }
+ break;
+#endif
+
case PNS_PEP_DISCONNECT_REQ:
pep_reply(sk, skb, PN_PIPE_NO_ERROR, NULL, 0, GFP_ATOMIC);
sk->sk_state = TCP_CLOSE_WAIT;
@@ -323,11 +644,41 @@ static int pipe_do_rcv(struct sock *sk, struct sk_buff *skb)
sk->sk_state_change(sk);
break;
+#ifdef CONFIG_PHONET_PIPECTRLR
+ case PNS_PEP_DISCONNECT_RESP:
+ pn->pipe_state = PIPE_IDLE;
+ pipe_handler_send_req(sk, pn->pn_sk.sobject,
+ PNS_PEP_DISCONNECT_UTID,
+ PNS_PEP_DISCONNECT_REQ, pn->pipe_handle,
+ GFP_KERNEL);
+ break;
+#endif
+
case PNS_PEP_ENABLE_REQ:
/* Wait for PNS_PIPE_(ENABLED|REDIRECTED)_IND */
pep_reply(sk, skb, PN_PIPE_NO_ERROR, NULL, 0, GFP_ATOMIC);
break;
+#ifdef CONFIG_PHONET_PIPECTRLR
+ case PNS_PEP_ENABLE_RESP:
+ if ((ph->pn_sdev == pn_dev(pn->remote_pep)) &&
+ (ph->pn_sobj == pn_obj(pn->remote_pep))) {
+ pn->pipe_state = PIPE_ENABLED;
+ pipe_handler_send_ind(sk, pn->remote_pep,
+ PNS_PIPE_ENABLED_IND_UTID,
+ pn->pipe_handle, PNS_PIPE_ENABLED_IND);
+ pipe_handler_send_ind(sk, pn->pn_sk.sobject,
+ PNS_PIPE_ENABLED_IND_UTID,
+ pn->pipe_handle, PNS_PIPE_ENABLED_IND);
+ } else
+ pipe_handler_send_req(sk, pn->remote_pep,
+ PNS_PIPE_ENABLE_UTID,
+ PNS_PEP_ENABLE_REQ, pn->pipe_handle,
+ GFP_KERNEL);
+
+ break;
+#endif
+
case PNS_PEP_RESET_REQ:
switch (hdr->state_after_reset) {
case PN_PIPE_DISABLE:
@@ -346,6 +697,27 @@ static int pipe_do_rcv(struct sock *sk, struct sk_buff *skb)
pep_reply(sk, skb, PN_PIPE_NO_ERROR, NULL, 0, GFP_ATOMIC);
break;
+#ifdef CONFIG_PHONET_PIPECTRLR
+ case PNS_PEP_DISABLE_RESP:
+ if ((ph->pn_sdev == pn_dev(pn->remote_pep)) &&
+ (ph->pn_sobj == pn_obj(pn->remote_pep))) {
+ pn->pipe_state = PIPE_DISABLED;
+ pipe_handler_send_ind(sk, pn->remote_pep,
+ PNS_PIPE_DISABLED_IND_UTID,
+ pn->pipe_handle,
+ PNS_PIPE_DISABLED_IND);
+ pipe_handler_send_ind(sk, pn->pn_sk.sobject,
+ PNS_PIPE_DISABLED_IND_UTID,
+ pn->pipe_handle,
+ PNS_PIPE_DISABLED_IND);
+ } else
+ pipe_handler_send_req(sk, pn->remote_pep,
+ PNS_PIPE_DISABLE_UTID,
+ PNS_PEP_DISABLE_REQ, pn->pipe_handle,
+ GFP_KERNEL);
+ break;
+#endif
+
case PNS_PEP_CTRL_REQ:
if (skb_queue_len(&pn->ctrlreq_queue) >= PNPIPE_CTRLREQ_MAX) {
atomic_inc(&sk->sk_drops);
@@ -519,6 +891,9 @@ static int pep_connreq_rcv(struct sock *sk, struct sk_buff *skb)
newpn->rx_fc = newpn->tx_fc = PN_LEGACY_FLOW_CONTROL;
newpn->init_enable = enabled;
newpn->aligned = aligned;
+#ifdef CONFIG_PHONET_PIPECTRLR
+ newpn->remote_pep = pn->remote_pep;
+#endif
BUG_ON(!skb_queue_empty(&newsk->sk_receive_queue));
skb_queue_head(&newsk->sk_receive_queue, skb);
@@ -781,6 +1156,10 @@ static int pep_setsockopt(struct sock *sk, int level, int optname,
{
struct pep_sock *pn = pep_sk(sk);
int val = 0, err = 0;
+#ifdef CONFIG_PHONET_PIPECTRLR
+ int remote_pep;
+ int pipe_handle;
+#endif
if (level != SOL_PNPIPE)
return -ENOPROTOOPT;
@@ -791,6 +1170,48 @@ static int pep_setsockopt(struct sock *sk, int level, int optname,
lock_sock(sk);
switch (optname) {
+#ifdef CONFIG_PHONET_PIPECTRLR
+ case PNPIPE_CREATE:
+ if (val) {
+ if (pn->pipe_state > PIPE_IDLE) {
+ err = -EFAULT;
+ break;
+ }
+ remote_pep = val & 0xFFFF;
+ pipe_handle = (val >> 16) & 0xFF;
+ pn->remote_pep = remote_pep;
+ err = pipe_handler_create_pipe(sk, pipe_handle,
+ PNPIPE_CREATE);
+ break;
+ }
+
+ case PNPIPE_ENABLE:
+ if (pn->pipe_state != PIPE_DISABLED) {
+ err = -EFAULT;
+ break;
+ }
+ err = pipe_handler_enable_pipe(sk, PNPIPE_ENABLE);
+ break;
+
+ case PNPIPE_DISABLE:
+ if (pn->pipe_state != PIPE_ENABLED) {
+ err = -EFAULT;
+ break;
+ }
+
+ err = pipe_handler_enable_pipe(sk, PNPIPE_DISABLE);
+ break;
+
+ case PNPIPE_DESTROY:
+ if (pn->pipe_state < PIPE_DISABLED) {
+ err = -EFAULT;
+ break;
+ }
+
+ err = pipe_handler_create_pipe(sk, 0x0, PNPIPE_DESTROY);
+ break;
+#endif
+
case PNPIPE_ENCAP:
if (val && val != PNPIPE_ENCAP_IP) {
err = -EINVAL;
@@ -840,6 +1261,13 @@ static int pep_getsockopt(struct sock *sk, int level, int optname,
case PNPIPE_ENCAP:
val = pn->ifindex ? PNPIPE_ENCAP_IP : PNPIPE_ENCAP_NONE;
break;
+
+#ifdef CONFIG_PHONET_PIPECTRLR
+ case PNPIPE_INQ:
+ val = pn->pipe_state;
+ break;
+#endif
+
case PNPIPE_IFINDEX:
val = pn->ifindex;
break;
@@ -859,7 +1287,14 @@ static int pipe_skb_send(struct sock *sk, struct sk_buff *skb)
{
struct pep_sock *pn = pep_sk(sk);
struct pnpipehdr *ph;
- int err;
+#ifdef CONFIG_PHONET_PIPECTRLR
+ struct sockaddr_pn spn = {
+ .spn_family = AF_PHONET,
+ .spn_resource = 0xD9,
+ .spn_dev = pn_dev(pn->remote_pep),
+ .spn_obj = pn_obj(pn->remote_pep),
+ };
+#endif
if (pn_flow_safe(pn->tx_fc) &&
!atomic_add_unless(&pn->tx_credits, -1, 0)) {
@@ -877,11 +1312,11 @@ static int pipe_skb_send(struct sock *sk, struct sk_buff *skb)
} else
ph->message_id = PNS_PIPE_DATA;
ph->pipe_handle = pn->pipe_handle;
-
- err = pn_skb_send(sk, skb, &pipe_srv);
- if (err && pn_flow_safe(pn->tx_fc))
- atomic_inc(&pn->tx_credits);
- return err;
+#ifdef CONFIG_PHONET_PIPECTRLR
+ return pn_skb_send(sk, skb, &spn);
+#else
+ return pn_skb_send(sk, skb, &pipe_srv);
+#endif
}
static int pep_sendmsg(struct kiocb *iocb, struct sock *sk,
--
1.7.2.dirty
^ permalink raw reply related
* [PATCH 0/2] Phonet: Implement Pipe Controller to support Nokia Slim Modems
From: Kumar A Sanghvi @ 2010-09-24 12:23 UTC (permalink / raw)
To: remi.denis-courmont, davem, netdev
Cc: STEricsson_nomadik_linux, sudeep.divakaran, gulshan.karmani,
Kumar Sanghvi
From: Kumar Sanghvi <kumar.sanghvi@stericsson.com>
This patch implements the Pipe Controller functionality in Phonet stack to
support Nokia Modems like WG2.5 which do not have Pipe Controller in them.
Abbreviation:
APE: Application Processing Engine running Linux Kernel.
Modem is a separate entity attached to the APE.
With the current Phonet stack, to send Pipe data (example TCP/IP data over
GPRS), it is assumed that there is some type of Pipe Controller present either
in Modem or on APE user-space.
Many Nokia Modems implement the Pipe controller inside them.
HOwever, the Nokia Slim Modem WG2.5, the one in ST-Ericsson U8500 platform,
does not implement the Pipe Controller.
So, it is expected that APE running Linux implement the Pipe controller.
Now, PN_DEV_HOST (0x00) is normally the address of modem, so Phonet stack sends
out Pipe data by default on 0x00.
However, the Nokia Slim Modem WG2.5 expects that any data directed to it from
App processing engine should have dst_dev = 0x60 in Phonet header.
On APE side, Pipe controller can be implemented either in user-space or at
Phonet stack level.
1. Pipe controller at User-space level
---------------------------------------
There are 3 cases now:
Case 1: net_device carrying phonet traffic on APE has device address
= 0x6c and user-space specifies destination as 0x00.
---------------------------------------------------------------------
Nokia Slim modem WG2.5 simply gets reset for MCE related messages which
has dest_dev as something other than 0x60 in Phonet header.
Further, the modem does not process Pipe messages which has dest_dev as
something other than 0x60 in Phonet header, and simply echoes the
message back.
Case 2: net_device carrying phonet traffic on APE has device address
= 0x6c and user-space specifies destination as 0x60.
---------------------------------------------------------------------
Things work fine here.
The GPRS device gets created also and IP address is also obtained from
modem.
However, problem comes when its time for sending PIPE_DATA.
Phonet stack will by default send PIPE_DATA to destination with dst_dev
= 0x00 and dst_obj = 0x00 in pipe_skb_send. So, modem, as indicated in
case above, will not process the Pipe data message which has dest_dev
as something other than 0x60 in Phonet header, and simply echoes the
message back. So, the GPRS device user never gets a correct response.
Case 3: net_device carrying phonet traffic on APE has device address
= 0x00 and user-space specified destination as 0x60.
---------------------------------------------------------------------
Things work fine here also.
The GPRS device gets created also and IP address is also obtained from
modem.
However, again problem comes when its time for sending PIPE_DATA.
Since, Phonet stack will send PIPE_DATA to dest_dev = 0x00 and dest_obj
= 0x00, and since APE net-device also has address = 0x00, this message
will get looped-back.
So, some user-space app OR user-space Pipe handler has to take this
data, fill in correct dst_dev (0x60) and send it to modem.
As a result, the traffic essentially traverses two times via the Phonet
stack:
1st. via pipe_skb_send which will send data to 0x00 - which will
get looped back.
2nd. via user-space pipe handler which again sends this data to
modem via phonet stack.
Again, in the receive path, the return traffic will first go to pipe
handler in user-space and then it will go to gprs0 device.
2. Pipe Controller at Phonet stack
----------------------------------
Implementing Pipe controller at Phonet stack resolves the problem of GPRS data
traversing two times the Phonet stack in Case 3 above.
Further, the pipe-creation and related Pipe handling will be transparent to
user-space.
This patch implements the Pipe controller logic in Phonet stack.
The implementation is derived from 'Nokia Wireless Modem API -
WirelessModem_API_user_guide.pdf' document depicting the sequence for
establishing data connection.
The patch adds a Kconfig option to Phonet stack allowing users to
enable/disable Pipe controller functionality in Phonet stack.
Users can enable this option for Nokia Slim modems which do not have Pipe
controller in them.
The patch adds 4 setsockopt options at the Phonet stack level to enable
creation, enabling, disabling and destroying a pipe.
The patch also adds getsockopt options to query the state of pipe at any stage
ie. whether it is created or enabled.
The patch also implements negotiating the flow control and selects the best
flow control which is supported by modem and APE.
This patch has been tested on ST-Ericsson U8500 running Linux kernel and
works fine for GPRS data.
Kumar Sanghvi (2):
Phonet: Implement Pipe Controller to support Nokia Slim Modems
Documentation: Update Phonet doc for Pipe Controller implementation
Documentation/networking/phonet.txt | 53 ++++
include/linux/phonet.h | 5 +
include/net/phonet/pep.h | 21 ++
net/phonet/Kconfig | 11 +
net/phonet/pep.c | 447 ++++++++++++++++++++++++++++++++++-
5 files changed, 531 insertions(+), 6 deletions(-)
--
1.7.2.dirty
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/2] net: Allow changing number of RX queues after device allocation
From: Ben Hutchings @ 2010-09-24 12:24 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, linux-net-drivers, Tom Herbert
In-Reply-To: <1285296505.2380.43.camel@edumazet-laptop>
On Fri, 2010-09-24 at 04:48 +0200, Eric Dumazet wrote:
> Le jeudi 23 septembre 2010 à 21:19 +0100, Ben Hutchings a écrit :
> > For RPS, we create a kobject for each RX queue based on the number of
> > queues passed to alloc_netdev_mq(). However, drivers generally do not
> > determine the numbers of hardware queues to use until much later, so
> > this usually represents the maximum number the driver may use and not
> > the actual number in use.
> >
> > For TX queues, drivers can update the actual number using
> > netif_set_real_num_tx_queues(). Add a corresponding function for RX
> > queues, netif_set_real_num_rx_queues().
> >
> > Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> > ---
>
> Seems very good to me, except a minor style issue here :
>
> All functions in this file use a single line.
>
> > -static int rx_queue_register_kobjects(struct net_device *net)
> > +int
> > +net_rx_queue_update_kobjects(struct net_device *net, int old_num, int new_num)
>
> ->
>
> int net_rx_queue_update_kobjects(struct net_device *net, int old, int new)
Why should I rename variables to fit a function signature on one line?
> Also, I dont understand why we need to restrict
> netif_set_real_num_rx_queues() to lower the count.
> This wastes memory.
>
> Why dont we allocate dev->_rx once we know the real count, not in
> alloc_netdev_mq() but in register_netdevice() ?
We probably could do. I was just being consistent with
netif_set_real_num_tx_queues().
Note that both functions allow changing the number of queues on a
registered device, although I don't think any driver uses this.
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
* [PATCH 2/2] Documentation: Update Phonet doc for Pipe Controller implementation
From: Kumar A Sanghvi @ 2010-09-24 12:23 UTC (permalink / raw)
To: remi.denis-courmont, davem, netdev
Cc: STEricsson_nomadik_linux, sudeep.divakaran, gulshan.karmani,
Kumar Sanghvi, Linus Walleij
In-Reply-To: <1285330996-27076-1-git-send-email-kumar.sanghvi@stericsson.com>
From: Kumar Sanghvi <kumar.sanghvi@stericsson.com>
Updates the Phonet document with description related to Pipe controller
implementation
Signed-off-by: Kumar Sanghvi <kumar.sanghvi@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@stericsson.com>
---
Documentation/networking/phonet.txt | 53 +++++++++++++++++++++++++++++++++++
1 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/Documentation/networking/phonet.txt b/Documentation/networking/phonet.txt
index cf76608..cccf5ff 100644
--- a/Documentation/networking/phonet.txt
+++ b/Documentation/networking/phonet.txt
@@ -182,6 +182,59 @@ The pipe protocol provides two socket options at the SOL_PNPIPE level:
or zero if encapsulation is off.
+Phonet Pipe-controller Implementation
+-------------------------------------
+
+Phonet Pipe-controller is enabled by selecting the CONFIG_PHONET_PIPECTRLR Kconfig
+option. It is useful when communicating with those Nokia Modems which do not
+implement Pipe controller in them e.g. Nokia Slim Modem used in ST-Ericsson
+U8500 platform.
+
+The implementation is based on the Data Connection Establishment Sequence
+depicted in 'Nokia Wireless Modem API - Wireless_modem_user_guide.pdf'
+document.
+
+It allows a phonet sequenced socket (host-pep) to initiate a Pipe connection
+between itself and a remote pipe-end point (e.g. modem).
+
+The implementation adds socket options at SOL_PNPIPE level:
+
+ PNPIPE_CREATE
+ It accepts an integer argument where-in
+ lower order 16 bits: pn_dev and pn_port pair for remote pep.
+ higher order 16 bits: 8 bit pipe-handle
+
+ It sends a PNS_PEP_CONNECT_REQ on sequenced socket itself. On getting
+ PNS_PEP_CONNECT_RESP, it sends PNS_PEP_CONNECT_REQ to remote pep. On
+ getting response from remote pep, it selects the best possible Flow
+ control mechanism supported by remote-pep (modem) and then it sends
+ PNS_PEP_CREATED_IND to the sequenced socket and to the remote pep.
+
+ It then updates the pipe state associated with the sequenced socket to
+ be PIPE_DISABLED.
+
+ PNPIPE_ENABLE
+ It follows the same sequence as above for enabling a pipe by sending
+ PNS_PEP_ENABLE_REQ initially and then sending PNS_PEP_ENABLED_IND after
+ getting responses from sequenced socket and remote-pep.
+ It will also update the pipe state associated with the sequenced socket
+ to PIPE_ENABLED.
+
+ PNPIPE_DESTROY
+ This will send out PNS_PEP_DISCONNECT_REQ on the sequenced socket and
+ the remote pep.
+ It will also update the pipe state associated with the sequenced socket
+ to PIPE_IDLE
+
+ PNPIPE_INQ
+ This getsocktopt allows the user-space running on the sequenced socket
+ to examine the pipe state associated with that socket ie. whether the
+ pipe is created (PIPE_DISABLED) or enabled (PIPE_ENABLED) or disabled
+ (PIPE_DISABLED) or no pipe exists (PIPE_IDLE).
+
+After a pipe has been created and enabled successfully, the Pipe data can be
+exchanged between the host-pep and remote-pep (modem).
+
Authors
-------
--
1.7.2.dirty
^ permalink raw reply related
* Re: [PATCH 6/8] ptp: Added a clock that uses the eTSEC found on the MPC85xx.
From: Alan Cox @ 2010-09-24 11:52 UTC (permalink / raw)
To: Christian Riesch
Cc: John Stultz, Rodolfo Giometti, Arnd Bergmann, Peter Zijlstra,
linux-api, devicetree-discuss, linux-kernel, David Miller,
Thomas Gleixner, netdev, Christoph Lameter, linuxppc-dev,
Richard Cochran, linux-arm-kernel, Krzysztof Halasa
In-Reply-To: <4C9BC620.3@riesch.at>
> However, if the clock selected by the BMC is switched off, loses its
> network connection..., the second best clock is selected by the BMC and
> becomes master. This clock may be less accurate and thus our slave clock
> has to switch from one notion of time to another. Is that the conflict
> you mentioned?
No you get situations where you have policy reasons for trusting
particular clocks for particular things.
So you may have a PTP or NTP clock providing basic system time but also
have other PTP clocks that are actually being used for synchronization
work.
With NTP it's not so far been a big issue - NTP isn't used for industrial
high precision control and the cases we end up with multiple NTP clocks
it's on a virtualised systems where it is isolated.
With high precision clocks you sometimes want to honour a specific PTP
time source and use it rather than try and merge it with your other time
sources (which may differ from the equipment elsewhere). What matters is
things like all the parts of a several mile long conveyor belt of hot
steel slab stopping at the same moment [1].
In lots of control applications you've got assorted different time planes
which wish to talk their own time and you have to accept it, so we need
to support that kind of use.
I agree entirely the normal boring 'I installed my distro and..' case for
PTP or for NTP is merging all the sources, running the algorithm and using
the system time for it. Likewise almost all "normal" application code
will be watching system time.
Alan
[1] Which was my first encounter with writing Vax/VMS assembly language
^ permalink raw reply
* Re: [PATCH 7/8] net: Allow setting the network namespace by fd
From: jamal @ 2010-09-24 11:51 UTC (permalink / raw)
To: David Lamparter
Cc: Eric W. Biederman, linux-kernel, Linux Containers, netdev,
netfilter-devel, linux-fsdevel, Daniel Lezcano, Linus Torvalds,
Michael Kerrisk, Ulrich Drepper, Al Viro, David Miller,
Serge E. Hallyn, Pavel Emelyanov, Pavel Emelyanov, Ben Greear,
Matt Helsley, Jonathan Corbet, Sukadev Bhattiprolu,
Jan Engelhardt, Patrick McHardy
In-Reply-To: <20100923145856.GB1160234@jupiter.n2.diac24.net>
On Thu, 2010-09-23 at 16:58 +0200, David Lamparter wrote:
> migrating route table entries makes no sense because
> a) they refer to devices and configuration that does not exist in the
> target namespace; they only make sense within their netns context
> b) they are purely virtual and you get the same result from deleting and
> recreating them.
>
> Network devices are special because they may have something attached to
> them, be it hardware or some daemon.
Routes functionally reside on top of netdevices, point to nexthop
neighbors across these netdevices etc. Underlying assumption is you take
care of that dependency when migrating.
We are talking about FIB entries here not the route cache; moving a few
pointers within the kernel is a hell lot faster than recreating a subset
of BGP entries from user space.
Eric, I didnt follow the exposed-races arguement: Why would it involve
more than just some basic locking only while you change the struct net
pointer to the new namespace for these sub-subsystems?
cheers,
jamal
^ 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