* Re: [PATCH net] net: cdc_ncm: workaround for missing CDC Union
From: Bjørn Mork @ 2013-01-21 8:31 UTC (permalink / raw)
To: Alexey Orishko
Cc: Oliver Neukum, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Greg Suarez, Alexey Orishko
In-Reply-To: <CAL_Kpj1B=_+eN3Y0n3d9_r4JoeHD2LQFSU+b+taCZL0G4icu6A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Alexey Orishko <alexey.orishko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> On Fri, Jan 18, 2013 at 10:17 PM, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> wrote:
>
>>>> Some Sierra Wireless firmwares support CDC MBIM but have no CDC
>>>> Union funtional descriptor. This violates the MBIM specification,
>
> I don't believe Sierra Wireless violates MBIM specification.
> See in the specification: "there are two ways to group interfaces: the
> WHCM Union functional descriptor and IAD."
I disagree. This is not about the WHCM Union descriptor, it's about the
CDC Union descriptor. WHCM is of course not mandatory.
Quoting that whole section from the MBIM specification:
<quote>
6.1 OVERVIEW
A USB MBIM function is implemented as a USB CDC function with two
interfaces. Functions shall provide a CDC Union functional descriptor
to group these two interfaces. See [USBWMC11].
A Communication Class interface, with class 02h and subclass 0Eh, and
a Data Class interface combine to form a single functional unit
representing the USB MBIM device. The Communication Class interface
includes a single endpoint for event notification; it also uses the
device’s default pipe for control messages. The Data Class interface
includes two bulk endpoints for data traffic.
There are two ways to group interfaces: the WHCM Union Functional
Descriptor (see [USBWMC11]) and the IAD. Devices may also provide an
IAD. If an IAD is provided, the information in the IAD for MBIM
functions shall be consistent with the information in the CDC Union
descriptor and Communication Class interface descriptor.
</quote>
The "Functions shall provide a CDC Union functional descriptor to group
these two interfaces." is pretty clear IMHO. You also have table 6‐2
listing the HEADER, UNION and MBIM functional descriptors as "Required".
There is absolutely not way to make this anything but a firmware bug.
But I am all for working around it, of course. There also seems to be a
couple more oddities with the MBIM mode of this device compared to the
other I've seen, but those are more likely revealing driver bugs. I
intend to fix them as well.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information
From: Stefan Richter @ 2013-01-21 8:28 UTC (permalink / raw)
To: stephan.gatzka
Cc: Waskiewicz Jr, Peter P, linux1394-devel, netdev, yoshfuji, davem
In-Reply-To: <50FCDD89.3020403@gmail.com>
On Jan 21 Stephan Gatzka wrote:
> On Jan 20 Waskiewicz Jr, Peter P wrote:
> > I'm no expert on firewire requirements, but if you go down the path
> > of adding a net_device_ops member, I'd recommend adding a pointer
> > to your own struct of ops. This would be similar to wireless ops.
> >
> > Only a suggestion, since you may still need to add more ops later
> > on, and this way you can contain the inflation to a firewire-specific
> > struct of function pointers.
> >
>
> Thanks for your note. Right now I only need on function pointer for
> filling RFC3146 information and I can imagine doing the same for
> IPv4/ARP which would be a second function.
There is a limited count of IEEE 1394 specifics:
a) RFC 2734 ARP: currently implemented by inspecting and mangling ARP
packets within the firewire-net driver (inbound as well as outbound
packets).
b) RFC 2734 MCAP (Multicast Channel Allocation Protocol): currently not
implemented; not sure if needed (I see a few big downsides to using
per-multicast-group channels); not sure if networking core support
would be needed for this
c) RFC 2855 DHCP for IEEE 1394: currently not implemented; not sure if
needed; not sure if it would concern the kernel at all
d) RFC 3146 NDISC (Neighbor Discovery Protocol for IPv6): That's the
only real problem in search of a solution.
I bet there won't be any additional RFCs invented for networking over
1394, ever.
--
Stefan Richter
-=====-===-= ---= =-=-=
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [PATCH 2/2] CDC_NCM: adding support FLAG_NOARP for Infineon modem platform
From: Wei Shuai @ 2013-01-21 8:22 UTC (permalink / raw)
To: David Miller
Cc: sshtylyov, dcbw, peter, oneukum, gregkh, alexey.orishko, bjorn,
linux-usb, netdev
In-Reply-To: <20130120.230902.1326170122198671921.davem@davemloft.net>
Thank you David. yes in the core driver, FLAG_NOARP will be translated
to IFF_NOARP
2013/1/21, David Miller <davem@davemloft.net>:
> From: Wei Shuai <cpuwolf@gmail.com>
> Date: Mon, 21 Jan 2013 10:20:22 +0800
>
>> The main problem is that these devices don't support ethernet.
>
> He's saying your comment is referring to the wrong thing,
> rather than saying anything against what your change is
> doing.
>
> Read his feedback carefully:
>
>>>> +/* Same as wwan_info, but with IFF_NOARP */
>>>
>>> FLAG_NOARP, you mean?
>
> He's saying your commnet is talking about FLAG_NOARP rather
> than what the core code does with this flag, which is
> translate into setting IFF_NOARP on the net device.
>
>
^ permalink raw reply
* Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information
From: Stefan Richter @ 2013-01-21 8:09 UTC (permalink / raw)
To: stephan.gatzka; +Cc: YOSHIFUJI Hideaki, netdev, linux1394-devel, David Miller
In-Reply-To: <50FC6068.3020302@gmail.com>
On Jan 20 Stephan Gatzka wrote:
> On 01/20/2013 07:47 PM, YOSHIFUJI Hideaki wrote:
>
> > My current position is to change "mac address" to
> >
> > struct fwnet_hwaddr {
> > u8 guid[8];
> > u8 max_rec;
> > u8 sspd;
> > u8 fifo[6];
> > };
> >
>
> That is something I'm not really convinced of. As Stefan Richter pointed
> out clearly, the fifo address might be different between IPv4 and IPv6
> communication.
If it is of any help, the initial implementation could assume that IPv4
unicast_FIFO and IPv6 unicast_FIFO are the same. RFC 3146 is silent on
this topic (which means it can be one way or the other), but from an
implementation point of view, using one FIFO offset for both seems quite
natural. Currently the only existing RFC 3146 implementation which is
known to us is Mac OS X, and since your tests with OS X 10.6 went well,
they obviously use one offset for both protocols.
But if we actually put this assumption into the implementation now, we
should make sure that we can easily expand the implementation later in the
event that a third implementation comes across which uses separate
unicast_FIFOs.
--
Stefan Richter
-=====-===-= ---= =-=-=
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [PATCH 0/5]: soreuseport: Bind multiple sockets to the same port
From: Li Yu @ 2013-01-21 7:58 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Laight, netdev, davem, netdev, eric.dumazet
In-Reply-To: <50FCECDE.7060200@gmail.com>
于 2013年01月21日 15:23, Li Yu 写道:
> 于 2013年01月17日 02:22, Tom Herbert 写道:
>>> Hmmm.... do you need that sort of fairness between the threads?
>>>
>> Yes :-)
>>
>>> If one request takes longer than average to process, then you
>>> don't want other requests to be delayed when there are other
>>> idle worker processes.
>>>
>> On a heavily loaded server processing thousands of requests/second,
>> law of large numbers hopefully applies where each connection
>> represents approximately same unit of work.
>>
>
> It seem that these words are reasonable for some scenarios, we
> backported old version of SO_REUSEPORT patch into RHEL6 2.6.32-220.x
> kernel on CDN platform, and result in better balanced
> CPU utility among some haproxy instances.
>
> Also, we did a performance benchmark for old SO_REUSEPORT. It
>
> indeed bring significant improvement for short connections performance
> sometimes, but it also has some performance regression another
> sometimes. I think that problem is random selecting policy, the
> selected result may trigger extra CPU cache misses -- I tried to write
> a SO_BINDCPU patch to directly use RPS/RSS hashed result to select
> listen fd, the performance regression disappear then. but I have send
> it here since I did not implement load balance feature yet ...
> I will send the benchmark results soon.
>
These are results of performance benchmark of old SO_REUSEPORT:
HW of testbed:
Summary: Dell R720, 2 x Xeon E5-2680 0 2.70GHz, 31.4GB / 32GB 1600MHz DDR3
System: Dell PowerEdge R720 (Dell 02P51C)
Processors: 2 x Xeon E5-2680 0 2.70GHz 8000MHz FSB (2 sockets x 8 cores
x 2 threads)
Memory: 31.4GB / 32GB 1600MHz DDR3 == 8 x 4GB, 16 x empty
Network: Chelsio Communications T420-CR Unified Wire Ethernet Controller
OS: RHEL Server 6.2 (Santiago) x86_64, 64-bit
BIOS: Dell 1.0.4 02/21/2012
processes/mode - number of worker processes/listen mode
4/8/16 : numbers of worker processes, each process is
bound on individual processor.
listen mode:
-s: RHEL6 without any extra patch
-r: RHEL6 with SO_REUSEPORT
-R: RHEL6 with both SO_REUSEPORT and SO_BINDCPU
64B|1x - This benchmark suite just is to simulate simple RPC
workload. The client sends RPC request first, the
server replies a RPC response (I said such a pair of
messages is a RPC transaction ), then client send
next RPC request to start another new RPC trans.
64B/1024B : both RPC requests/responses are 64/1024
bytes length.
1x/1024x : each TCP connection has 1 or 1024 RPC
trans.
The numbers in below table are represented by 10000 trans per second.
=====================================================================
processes/mode 64B|1x 64B|1024x 1024B|1x 1024B|1024x
=====================================================================
4/-s 18 80 17 78
---------------------------------------------------------------------
4/-r 16 71 15 67
---------------------------------------------------------------------
4/-R 23 96 23 92
---------------------------------------------------------------------
8/-s 18 165 18 160
---------------------------------------------------------------------
8/-r 30 155 29 147
---------------------------------------------------------------------
8/-R 36 185 36 180
---------------------------------------------------------------------
16/-s 15 230 14 220
---------------------------------------------------------------------
16/-r 38 230 38 220
---------------------------------------------------------------------
16/-R 43 230 43 220
---------------------------------------------------------------------
Above data are against RHEL6 2.6.32.279.xx kernel, I also tested
upstream 3.6.2 kernel with these patches, the results are similar.
Thanks
Yu
>>> Also having the same thread normally collect a request would
>>> make it more likely that the required code/data be in the
>>> cache of the cpu (assuming that the main reason for multiple
>>> threads is to load balance over multiple cpus, and with the
>>> threads tied to a single cpu).
>>>
>> Right. Multiple listener sockets also imply that the work on the
>> connected sockets will be in the same thread or at least dispatched to
>> thread which is close to the same CPU. soreuseport moves the start of
>> siloed processing into kernel.
>>
>>> If there are a lot of processes sleeping in accept() (on the same
>>> socket) it might be worth looking at which is actually woken
>>> when a new connection arrives. If they are sleeping in poll/select
>>> it is probably more difficult (but not impossible) to avoid waking
>>> all the processes for every incoming connection.
>>
>> We had considered solving this within accept. The problem is that
>> there's no way to indicate how much work a thread should do via
>> accept. For instance, an event loop usually would look like:
>>
>> while (1) {
>> fd = accept();
>> process(fd);
>> }
>>
>> With multiple threads, the number of accepted sockets in a particular
>> thread is non-deterministic. It is even possible that one thread
>> could end up accepting all the connections, and the others are starved
>> (wake up but no connection to process.). Since connections are the
>> unit of work, this creates imbalance among threads. There was an
>> attempt to fix this in user space by sleeping for a while instead of
>> calling accept on threads for one that have already have a
>> disproportionate number of connections. This was unpleasant-- it
>> needed shared state in user space and provided no granularity.
>>
>
> I also have some thinks on this imbalance problem ...
>
> At Last, I assumed that every accept-thread holds same numbers of
> listen sockets, so we just can do load balance base on length of accept
> queue.
>
> Thanks for great SO_REUSEPORT work.
>
>> Tom
>> --
>> 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
* Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information
From: Stefan Richter @ 2013-01-21 7:39 UTC (permalink / raw)
To: stephan.gatzka; +Cc: YOSHIFUJI Hideaki, netdev, linux1394-devel, Miller, David
In-Reply-To: <50FCDF5D.3060300@gmail.com>
On Jan 21 Stephan Gatzka wrote:
> > We could have multiple "net_device"s per single physical
> > interface at the same time, then.
>
> Of course, but I would avoid it if it's not necessary. What's the
> problem with introducing a function pointer in struct net_device or
> struct net_device_ops?
Two net_device instances on one 1394 card would be awkward: They would
have to share one instance of isochronous reception context (for reception
of asynchronous 1394 streams; those are used for broadcasts and
multicasts). Such a sharing is surely possible, but if double net_device
instantiation can be avoided, then avoid it.
Not to mention the user interface problem of having two netifs, one which
only supports IPv4 and another one which only supports IPv6. So far I
never had IPv6 configured into a Linux kernel, but I suppose that folks
are used to be able to use eth0 etc. for both protocols.
> > Multicast is a big issue. Because IPv6 is fan of
> > multicast, and it uses link-local multicast as its
> > core infrastructure. Without infrastructure to
> > support it, I'm not going to agree.
>
> firewire net supports multicast and we use it very often. My patch to
> support IPv6 does not change it. In fact, because I can communicate via
> IPv6 between two firewire nodes, multicast _is_ running. The driver
> does not do lot's of special things with multicast packets. But
> multicast packets are recognized because they have to be sent somehow
> different (GASP).
(At the moment we transport multicasts to the same 1394 channel like
broadcasts.
IEEE 1394 supports two addressing modes: IEEE 1212 based memory-mapable
addresses of the form bus:node:offset = 10 bits + 6 bits + 48 bits for
node-to-node communication, and "channel" = a 6 bit channel number for
communication of 1 node to 0...n nodes.
RFC 2734 broadcasts and multicasts use the channel addressing type. Hence
max_rec/ sspd/ unicast_FIFO come not into play with broadcasts and
multicasts. Broadcasts are sent to a fixed known channel number;
multicasts are sent either to the broadcast channel number or to a
separate channel number which is negotiated per multicast group using RFC
2734 Multicast Channel Allocation Protocol. For the time being the Linux
driver only implements multicasts to the broadcast channel.)
--
Stefan Richter
-=====-===-= ---= =-=-=
http://arcgraph.de/sr/
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
^ permalink raw reply
* Re: v3 for tcp friends?
From: Li Yu @ 2013-01-21 7:31 UTC (permalink / raw)
To: David Miller; +Cc: brutus, netdev
In-Reply-To: <50FCEE64.80203@gmail.com>
于 2013年01月21日 15:29, Li Yu 写道:
> 于 2012年09月05日 00:58, David Miller 写道:
>> From: Bruce Curtis <brutus@google.com>
>> Date: Tue, 4 Sep 2012 08:10:23 -0700
>>
>>> Will do, issues addressed, I'll get the patch out later today or
>>> tomorrow at the latest.
>>
>> Thanks a lot Bruce.
>> --
>> 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
>>
>
>
> Hi, Bruce,
>
> I tested the TCP friends, found a bug here:
>
> [ 106.541372] Pid: 1765, comm: client Not tainted 3.7.0-rc1+ #25
> [ 106.543121] Call Trace:
> [ 106.543950] [<ffffffff8133d212>] inet_sock_destruct+0x102/0x1f0
> [ 106.545687] [<ffffffff812c38ad>] __sk_free+0x1d/0x110
> [ 106.547209] [<ffffffff812c3a1c>] sk_free+0x1c/0x20
> [ 106.548611] [<ffffffff8131680c>] tcp_close+0x6c/0x3f0
> [ 106.549863] [<ffffffff8133caea>] inet_release+0xda/0xf0
> [ 106.551134] [<ffffffff8133ca30>] ? inet_release+0x20/0xf0
> [ 106.552419] [<ffffffff8137f3de>] ? mutex_unlock+0xe/0x10
> [ 106.553658] [<ffffffff812bf948>] sock_release+0x28/0xa0
> [ 106.557366] [<ffffffff812bfd69>] sock_close+0x29/0x30
> [ 106.558831] [<ffffffff81128972>] __fput+0x122/0x210
> [ 106.560541] [<ffffffff81128a6e>] ____fput+0xe/0x10
> [ 106.562006] [<ffffffff8105354e>] task_work_run+0x9e/0xd0
> [ 106.563285] [<ffffffff810027e1>] do_notify_resume+0x61/0x70
> [ 106.564582] [<ffffffff8138a908>] int_signal+0x12/0x17
>
>
> I also backported and tested it on stable kernel 3.7.3/RHEL6
> kernel, this bug still exists. It seem that client may close listening
> sockets, may we need to add one reference count for listen socket
> before send its address to peer?
>
Sorry, I lost an important line of kernel log before above them:
[ 106.539367] IPv4: Attempt to release TCP socket in state 10
ffff880074abb5c0
BTW: state 10 = TCP_LISTEN
> And, our TCP friends v4? :)
>
> Thanks
>
> Yu
>
^ permalink raw reply
* Re: v3 for tcp friends?
From: Li Yu @ 2013-01-21 7:29 UTC (permalink / raw)
To: David Miller; +Cc: brutus, netdev
In-Reply-To: <20120904.125841.2293649688957878987.davem@davemloft.net>
于 2012年09月05日 00:58, David Miller 写道:
> From: Bruce Curtis <brutus@google.com>
> Date: Tue, 4 Sep 2012 08:10:23 -0700
>
>> Will do, issues addressed, I'll get the patch out later today or
>> tomorrow at the latest.
>
> Thanks a lot Bruce.
> --
> 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
>
Hi, Bruce,
I tested the TCP friends, found a bug here:
[ 106.541372] Pid: 1765, comm: client Not tainted 3.7.0-rc1+ #25
[ 106.543121] Call Trace:
[ 106.543950] [<ffffffff8133d212>] inet_sock_destruct+0x102/0x1f0
[ 106.545687] [<ffffffff812c38ad>] __sk_free+0x1d/0x110
[ 106.547209] [<ffffffff812c3a1c>] sk_free+0x1c/0x20
[ 106.548611] [<ffffffff8131680c>] tcp_close+0x6c/0x3f0
[ 106.549863] [<ffffffff8133caea>] inet_release+0xda/0xf0
[ 106.551134] [<ffffffff8133ca30>] ? inet_release+0x20/0xf0
[ 106.552419] [<ffffffff8137f3de>] ? mutex_unlock+0xe/0x10
[ 106.553658] [<ffffffff812bf948>] sock_release+0x28/0xa0
[ 106.557366] [<ffffffff812bfd69>] sock_close+0x29/0x30
[ 106.558831] [<ffffffff81128972>] __fput+0x122/0x210
[ 106.560541] [<ffffffff81128a6e>] ____fput+0xe/0x10
[ 106.562006] [<ffffffff8105354e>] task_work_run+0x9e/0xd0
[ 106.563285] [<ffffffff810027e1>] do_notify_resume+0x61/0x70
[ 106.564582] [<ffffffff8138a908>] int_signal+0x12/0x17
I also backported and tested it on stable kernel 3.7.3/RHEL6
kernel, this bug still exists. It seem that client may close listening
sockets, may we need to add one reference count for listen socket
before send its address to peer?
And, our TCP friends v4? :)
Thanks
Yu
^ permalink raw reply
* Re: [PATCH 0/5]: soreuseport: Bind multiple sockets to the same port
From: Li Yu @ 2013-01-21 7:23 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Laight, netdev, davem, netdev, eric.dumazet
In-Reply-To: <CA+mtBx-DRiSg4z5OUvp4=pJxZ=Ki4pt-vz716ubsJx1PHnD7Nw@mail.gmail.com>
于 2013年01月17日 02:22, Tom Herbert 写道:
>> Hmmm.... do you need that sort of fairness between the threads?
>>
> Yes :-)
>
>> If one request takes longer than average to process, then you
>> don't want other requests to be delayed when there are other
>> idle worker processes.
>>
> On a heavily loaded server processing thousands of requests/second,
> law of large numbers hopefully applies where each connection
> represents approximately same unit of work.
>
It seem that these words are reasonable for some scenarios, we
backported old version of SO_REUSEPORT patch into RHEL6 2.6.32-220.x
kernel on CDN platform, and result in better balanced
CPU utility among some haproxy instances.
Also, we did a performance benchmark for old SO_REUSEPORT. It
indeed bring significant improvement for short connections performance
sometimes, but it also has some performance regression another
sometimes. I think that problem is random selecting policy, the
selected result may trigger extra CPU cache misses -- I tried to write
a SO_BINDCPU patch to directly use RPS/RSS hashed result to select
listen fd, the performance regression disappear then. but I have send
it here since I did not implement load balance feature yet ...
I will send the benchmark results soon.
>> Also having the same thread normally collect a request would
>> make it more likely that the required code/data be in the
>> cache of the cpu (assuming that the main reason for multiple
>> threads is to load balance over multiple cpus, and with the
>> threads tied to a single cpu).
>>
> Right. Multiple listener sockets also imply that the work on the
> connected sockets will be in the same thread or at least dispatched to
> thread which is close to the same CPU. soreuseport moves the start of
> siloed processing into kernel.
>
>> If there are a lot of processes sleeping in accept() (on the same
>> socket) it might be worth looking at which is actually woken
>> when a new connection arrives. If they are sleeping in poll/select
>> it is probably more difficult (but not impossible) to avoid waking
>> all the processes for every incoming connection.
>
> We had considered solving this within accept. The problem is that
> there's no way to indicate how much work a thread should do via
> accept. For instance, an event loop usually would look like:
>
> while (1) {
> fd = accept();
> process(fd);
> }
>
> With multiple threads, the number of accepted sockets in a particular
> thread is non-deterministic. It is even possible that one thread
> could end up accepting all the connections, and the others are starved
> (wake up but no connection to process.). Since connections are the
> unit of work, this creates imbalance among threads. There was an
> attempt to fix this in user space by sleeping for a while instead of
> calling accept on threads for one that have already have a
> disproportionate number of connections. This was unpleasant-- it
> needed shared state in user space and provided no granularity.
>
I also have some thinks on this imbalance problem ...
At Last, I assumed that every accept-thread holds same numbers of
listen sockets, so we just can do load balance base on length of accept
queue.
Thanks for great SO_REUSEPORT work.
> Tom
> --
> 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
* Re: [RFC PATCH 3/3] xfrm4: Invalidate all ipv4 routes on IPsec pmtu events
From: Steffen Klassert @ 2013-01-21 6:48 UTC (permalink / raw)
To: David Miller; +Cc: Yurij.Plotnikov, bhutchings, netdev, Alexandra.Kossovsky
In-Reply-To: <20130118.143923.1384219845592340856.davem@davemloft.net>
On Fri, Jan 18, 2013 at 02:39:23PM -0500, David Miller wrote:
> From: Steffen Klassert <steffen.klassert@secunet.com>
> Date: Fri, 18 Jan 2013 09:16:01 +0100
>
> > On IPsec pmtu events we can't access the transport headers of
> > the original packet, so we can't find the socket that sent
> > the packet. The only chance to notify the socket about the
> > pmtu change is to force a relookup for all routes. This
> > patch implenents this for the IPsec protocols.
> >
> > Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
>
> Expensive, but I really can't come up with a better idea.
Yes, it's a last resort fix. But pmtu events are rare, so
it should not harm too much.
^ permalink raw reply
* Re: [RFC PATCH 1/3] ipv4: Invalidate the socket cached route on pmtu events if possible
From: Steffen Klassert @ 2013-01-21 6:43 UTC (permalink / raw)
To: Julian Anastasov
Cc: Yurij M. Plotnikov, Ben Hutchings, netdev, Alexandra N. Kossovsky
In-Reply-To: <alpine.LFD.2.00.1301190031080.1803@ja.ssi.bg>
On Sat, Jan 19, 2013 at 02:54:04AM +0200, Julian Anastasov wrote:
> > +
> > +void ipv4_sk_update_pmtu(struct sk_buff *skb, struct sock *sk, u32 mtu)
> > +{
> > + const struct iphdr *iph = (const struct iphdr *) skb->data;
> > + struct flowi4 fl4;
> > + struct rtable *rt = (struct rtable *) __sk_dst_get(sk);
>
> I guess __sk_dst_get should be called after
> bh_lock_sock ?
Yes, absolutely. I'll fix it before I submit the patch.
Thanks for your review!
^ permalink raw reply
* Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information
From: Stephan Gatzka @ 2013-01-21 6:37 UTC (permalink / raw)
To: YOSHIFUJI Hideaki; +Cc: linux1394-devel, netdev, David Miller
In-Reply-To: <50FC3BB1.4070005@linux-ipv6.org>
> [ARP and NDISC]
> - both can be handled in more natural way.
> -- You will not need to mangle those packets when
> sending/receiving.
This is also true if we introduce a function pointer. My last
implementation does not mangle packets in the driver.
> -- You do not need to inspect ARP/NDISC packet.
> By using netevent notification mechanism, you can
> learn peer parameters.
That is worth to investigate. Will I get notifications when a ARP/NDISC
will be send or only if the stack received ARP/NDISC packets? However, I
can't see how this will help to get the firewire specific information
into the ARP/NDISC packet. This has to be done either via the suggested
function pointer or your extension of the mac address.
^ permalink raw reply
* [PATCH 2/2] ARM: davinci: da850: add OF_DEV_AUXDATA entry for eth0.
From: Prabhakar Lad @ 2013-01-21 6:29 UTC (permalink / raw)
To: LAK, DLOS
Cc: Sekhar Nori, LKML, Lad, Prabhakar, netdev, devicetree-discuss,
Heiko Schocher
In-Reply-To: <1358749759-20517-1-git-send-email-prabhakar.lad@ti.com>
From: Lad, Prabhakar <prabhakar.lad@ti.com>
Add OF_DEV_AUXDATA for eth0 driver in da850 board dt
file to use emac clock.
Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: davinci-linux-open-source@linux.davincidsp.com
Cc: netdev@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Heiko Schocher <hs@denx.de>
---
arch/arm/mach-davinci/da8xx-dt.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 37c27af..d548a38 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -37,11 +37,18 @@ static void __init da8xx_init_irq(void)
of_irq_init(da8xx_irq_match);
}
+struct of_dev_auxdata da850_evm_auxdata_lookup[] __initdata = {
+ OF_DEV_AUXDATA("ti,davinci-dm6467-emac", 0x01e20000, "davinci_emac.1",
+ NULL),
+ {}
+};
+
#ifdef CONFIG_ARCH_DAVINCI_DA850
static void __init da850_init_machine(void)
{
- of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+ of_platform_populate(NULL, of_default_bus_match_table,
+ da850_evm_auxdata_lookup, NULL);
da8xx_uart_clk_enable();
}
--
1.7.4.1
^ permalink raw reply related
* [PATCH 1/2] ARM: davinci: da850: add DT node for eth0.
From: Prabhakar Lad @ 2013-01-21 6:29 UTC (permalink / raw)
To: LAK, DLOS
Cc: Sekhar Nori, LKML, Lad, Prabhakar, netdev, devicetree-discuss,
Heiko Schocher
In-Reply-To: <1358749759-20517-1-git-send-email-prabhakar.lad@ti.com>
From: Lad, Prabhakar <prabhakar.lad@ti.com>
Add eth0 device tree node information to da850 by
providing interrupt details and local mac address of eth0.
Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: davinci-linux-open-source@linux.davincidsp.com
Cc: netdev@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Heiko Schocher <hs@denx.de>
---
arch/arm/boot/dts/da850-evm.dts | 3 +++
arch/arm/boot/dts/da850.dtsi | 15 +++++++++++++++
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 37dc5a3..a1d6e3e 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -24,5 +24,8 @@
serial2: serial@1d0d000 {
status = "okay";
};
+ eth0: emac@1e20000 {
+ status = "okay";
+ };
};
};
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 640ab75..309cc99 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -56,5 +56,20 @@
interrupt-parent = <&intc>;
status = "disabled";
};
+ eth0: emac@1e20000 {
+ compatible = "ti,davinci-dm6467-emac";
+ reg = <0x220000 0x4000>;
+ ti,davinci-ctrl-reg-offset = <0x3000>;
+ ti,davinci-ctrl-mod-reg-offset = <0x2000>;
+ ti,davinci-ctrl-ram-offset = <0>;
+ ti,davinci-ctrl-ram-size = <0x2000>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <33
+ 34
+ 35
+ 36
+ >;
+ interrupt-parent = <&intc>;
+ };
};
};
--
1.7.4.1
^ permalink raw reply related
* Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information
From: Stephan Gatzka @ 2013-01-21 6:25 UTC (permalink / raw)
To: YOSHIFUJI Hideaki; +Cc: linux1394-devel, netdev, David Miller
In-Reply-To: <50FCA825.7070609@linux-ipv6.org>
> We could have multiple "net_device"s per single physical
> interface at the same time, then.
Of course, but I would avoid it if it's not necessary. What's the
problem with introducing a function pointer in struct net_device or
struct net_device_ops?
>
> Multicast is a big issue. Because IPv6 is fan of
> multicast, and it uses link-local multicast as its
> core infrastructure. Without infrastructure to
> support it, I'm not going to agree.
firewire net supports multicast and we use it very often. My patch to
support IPv6 does not change it. In fact, because I can communicate via
IPv6 between two firewire nodes, multicast _is_ running. The driver
does not do lot's of special things with multicast packets. But
multicast packets are recognized because they have to be sent somehow
different (GASP).
>
> And, firewire driver does not seem to support zerocopy
> (fragmented skb) support. It help performance.
O.k., good point. I will have a look into that. But I suggest to not mix
up this issue with the IPv6 over firewire enhancement. That should be a
separate patch.
Stephan
^ permalink raw reply
* Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information
From: Stephan Gatzka @ 2013-01-21 6:17 UTC (permalink / raw)
To: Waskiewicz Jr, Peter P; +Cc: linux1394-devel, netdev, yoshfuji, stefanr, davem
In-Reply-To: <20130120212233.GA6776@ppwaskie-mobl2.amr.corp.intel.com>
> I'm no expert on firewire requirements, but if you go down the path
> of adding a net_device_ops member, I'd recommend adding a pointer
> to your own struct of ops. This would be similar to wireless ops.
>
> Only a suggestion, since you may still need to add more ops later
> on, and this way you can contain the inflation to a firewire-specific
> struct of function pointers.
>
Thanks for your note. Right now I only need on function pointer for
filling RFC3146 information and I can imagine doing the same for
IPv4/ARP which would be a second function.
Stephan
^ permalink raw reply
* [BUG] Bug in netprio_cgroup and netcls_cgroup ?
From: Li Zefan @ 2013-01-21 6:08 UTC (permalink / raw)
To: John Fastabend, Neil Horman, Daniel Wagner
Cc: LKML, netdev-u79uwXL29TY76Z2rM5mHXA, Cgroups
I'm not a network developer, so correct me if I'm wrong.
Since commit 406a3c638ce8b17d9704052c07955490f732c2b8
("net: netprio_cgroup: rework update socket logic"), sock->sk->sk_cgrp_prioidx
is set when the socket is created, and won't be updated unless the task is
moved to another cgroup.
Now the problem is, a socket can be _shared_ by multiple processes (fork, SCM_RIGHT).
If we place those processes in different cgroups, and each cgroup has
different configs, but all of the processes will send data via this socket
with the same network priority.
Similar with cls cgroup.
^ permalink raw reply
* Re: surprising memory request
From: Jason Wang @ 2013-01-21 5:44 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Eric Dumazet, Dirk Hohndel, netdev, David Woodhouse
In-Reply-To: <20130118095250.6b9ca9b7@nehalam.linuxnetplumber.net>
On 01/19/2013 01:52 AM, Stephen Hemminger wrote:
> On Fri, 18 Jan 2013 09:46:30 -0800
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>> On Fri, 2013-01-18 at 08:58 -0800, Dirk Hohndel wrote:
>>> Running openconnect on a very recent 3.8 (a few commits before Linus cut
>>> RC4) I get this allocation failure. I'm unclear why we would need 128
>>> contiguous pages here...
>>>
>>> /D
>>>
>>> [66015.673818] openconnect: page allocation failure: order:7, mode:0x10c0d0
>>> [66015.673827] Pid: 3292, comm: openconnect Tainted: G W 3.8.0-rc3-00352-gdfdebc2 #94
>>> [66015.673830] Call Trace:
>>> [66015.673841] [<ffffffff810e9c29>] warn_alloc_failed+0xe9/0x140
>>> [66015.673849] [<ffffffff81093967>] ? on_each_cpu_mask+0x87/0xa0
>>> [66015.673854] [<ffffffff810ec349>] __alloc_pages_nodemask+0x579/0x720
>>> [66015.673859] [<ffffffff810ec507>] __get_free_pages+0x17/0x50
>>> [66015.673866] [<ffffffff81123979>] kmalloc_order_trace+0x39/0xf0
>>> [66015.673874] [<ffffffff81666178>] ? __hw_addr_add_ex+0x78/0xc0
>>> [66015.673879] [<ffffffff811260d8>] __kmalloc+0xc8/0x180
>>> [66015.673883] [<ffffffff81666616>] ? dev_addr_init+0x66/0x90
>>> [66015.673889] [<ffffffff81660985>] alloc_netdev_mqs+0x145/0x300
>>> [66015.673896] [<ffffffff81513830>] ? tun_net_fix_features+0x20/0x20
>>> [66015.673902] [<ffffffff815168aa>] __tun_chr_ioctl+0xd0a/0xec0
>>> [66015.673908] [<ffffffff81516a93>] tun_chr_ioctl+0x13/0x20
>>> [66015.673913] [<ffffffff8113b197>] do_vfs_ioctl+0x97/0x530
>>> [66015.673917] [<ffffffff811256f3>] ? kmem_cache_free+0x33/0x170
>>> [66015.673923] [<ffffffff81134896>] ? final_putname+0x26/0x50
>>> [66015.673927] [<ffffffff8113b6c1>] sys_ioctl+0x91/0xb0
>>> [66015.673935] [<ffffffff8180e3d2>] system_call_fastpath+0x16/0x1b
>>> [66015.673938] Mem-Info:
>> Thats because Jason thought that tun device had to have an insane number
>> of queues to get good performance.
>>
>> #define MAX_TAP_QUEUES 1024
>>
>> Thats crazy if your machine has say 8 cpus.
>>
>> And Jason didnt care to adapt the memory allocations done in
>> alloc_netdev_mqs(), in order to switch to vmalloc() when kmalloc()
>> fails.
>>
>> commit c8d68e6be1c3b242f1c598595830890b65cea64a
>> Author: Jason Wang <jasowang@redhat.com>
>> Date: Wed Oct 31 19:46:00 2012 +0000
>>
>> tuntap: multiqueue support
>>
>> This patch converts tun/tap to a multiqueue devices and expose the multiqueue
>> queues as multiple file descriptors to userspace. Internally, each tun_file were
>> abstracted as a queue, and an array of pointers to tun_file structurs were
>> stored in tun_structure device, so multiple tun_files were allowed to be
>> attached to the device as multiple queues.
>>
>> When choosing txq, we first try to identify a flow through its rxhash, if it
>> does not have such one, we could try recorded rxq and then use them to choose
>> the transmit queue. This policy may be changed in the future.
>>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>> Signed-off-by: David S. Miller <davem@davemloft.net>
> Also the tuntap device now has it's own flow cache which is also a bad idea.
> Why not just 128 queues and a hash like SFQ?
Hi Stephen:
I know your concerns, I think we can solve it by limiting the number of
flow caches to a value (say 4096). With this, the average worst
searching depth is 4 which solves the issue when there's lots of
short-live connections.
The issue of just an array of 128 entries is that the matching is not
accurate. With an array of limited entries, we can easily get the index
collision with two different flows, which may result the packets of a
flow move back of forth between queues. Ideally we may need a perfect
filter and doing comparison on n-tuple which may be very expensive for
software device such as tun, so I choose to store rxhash in the flow
caches and using a hash list to do the match.
Thanks
>
> --
> 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
* Re: surprising memory request
From: Jason Wang @ 2013-01-21 5:23 UTC (permalink / raw)
To: David Woodhouse; +Cc: Eric Dumazet, Dirk Hohndel, netdev
In-Reply-To: <1358531946.2397.265.camel@shinybook.infradead.org>
On 01/19/2013 01:59 AM, David Woodhouse wrote:
> On Fri, 2013-01-18 at 09:46 -0800, Eric Dumazet wrote:
>> #define MAX_TAP_QUEUES 1024
>>
>> Thats crazy if your machine has say 8 cpus.
> Even crazier if your userspace is never going to *use* MQ. Can't we
> default to one queue unless userspace explicitly requests more?
>
Yes, if userspace never use MQ, we just use a one queue netdevice. Just
draft a patch fro Dirk to test.
Thanks
^ permalink raw reply
* Re: surprising memory request
From: Jason Wang @ 2013-01-21 5:21 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Dirk Hohndel, netdev, David Woodhouse
In-Reply-To: <1358531673.11051.420.camel@edumazet-glaptop>
On 01/19/2013 01:54 AM, Eric Dumazet wrote:
> On Fri, 2013-01-18 at 09:46 -0800, Eric Dumazet wrote:
>
>> Thats because Jason thought that tun device had to have an insane number
>> of queues to get good performance.
>>
>> #define MAX_TAP_QUEUES 1024
>>
>> Thats crazy if your machine has say 8 cpus.
>>
>> And Jason didnt care to adapt the memory allocations done in
>> alloc_netdev_mqs(), in order to switch to vmalloc() when kmalloc()
>> fails.
> I suggest using the more reasonable :
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index c81680d..ec18fbf 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -113,7 +113,7 @@ struct tap_filter {
> * the order of 100-200 CPUs so this leaves us some breathing space if we want
> * to match a queue per guest CPU.
> */
> -#define MAX_TAP_QUEUES 1024
> +#define MAX_TAP_QUEUES DEFAULT_MAX_NUM_RSS_QUEUES
>
> #define TUN_FLOW_EXPIRE (3 * HZ)
>
But it's default value 8 is a little too small, we can easily have a kvm
guest with more than 8 vcpus and a host multiqueue card with more than 8
queues. Maybe we can use num_possible_cpus() or just an arbitrary number
such as 256 which seems large enough.
>
>
> --
> 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
* Re: surprising memory request
From: Jason Wang @ 2013-01-21 5:13 UTC (permalink / raw)
To: Eric Dumazet, Dirk Hohndel; +Cc: netdev, David Woodhouse
In-Reply-To: <1358531190.11051.402.camel@edumazet-glaptop>
On Friday, January 18, 2013 09:46:30 AM Eric Dumazet wrote:
> On Fri, 2013-01-18 at 08:58 -0800, Dirk Hohndel wrote:
> > Running openconnect on a very recent 3.8 (a few commits before Linus cut
> > RC4) I get this allocation failure. I'm unclear why we would need 128
> > contiguous pages here...
> >
> > /D
> >
> > [66015.673818] openconnect: page allocation failure: order:7,
> > mode:0x10c0d0
> > [66015.673827] Pid: 3292, comm: openconnect Tainted: G W
> > 3.8.0-rc3-00352-gdfdebc2 #94 [66015.673830] Call Trace:
> > [66015.673841] [<ffffffff810e9c29>] warn_alloc_failed+0xe9/0x140
> > [66015.673849] [<ffffffff81093967>] ? on_each_cpu_mask+0x87/0xa0
> > [66015.673854] [<ffffffff810ec349>] __alloc_pages_nodemask+0x579/0x720
> > [66015.673859] [<ffffffff810ec507>] __get_free_pages+0x17/0x50
> > [66015.673866] [<ffffffff81123979>] kmalloc_order_trace+0x39/0xf0
> > [66015.673874] [<ffffffff81666178>] ? __hw_addr_add_ex+0x78/0xc0
> > [66015.673879] [<ffffffff811260d8>] __kmalloc+0xc8/0x180
> > [66015.673883] [<ffffffff81666616>] ? dev_addr_init+0x66/0x90
> > [66015.673889] [<ffffffff81660985>] alloc_netdev_mqs+0x145/0x300
> > [66015.673896] [<ffffffff81513830>] ? tun_net_fix_features+0x20/0x20
> > [66015.673902] [<ffffffff815168aa>] __tun_chr_ioctl+0xd0a/0xec0
> > [66015.673908] [<ffffffff81516a93>] tun_chr_ioctl+0x13/0x20
> > [66015.673913] [<ffffffff8113b197>] do_vfs_ioctl+0x97/0x530
> > [66015.673917] [<ffffffff811256f3>] ? kmem_cache_free+0x33/0x170
> > [66015.673923] [<ffffffff81134896>] ? final_putname+0x26/0x50
> > [66015.673927] [<ffffffff8113b6c1>] sys_ioctl+0x91/0xb0
> > [66015.673935] [<ffffffff8180e3d2>] system_call_fastpath+0x16/0x1b
>
> > [66015.673938] Mem-Info:
> Thats because Jason thought that tun device had to have an insane number
> of queues to get good performance.
>
> #define MAX_TAP_QUEUES 1024
>
> Thats crazy if your machine has say 8 cpus.
>
> And Jason didnt care to adapt the memory allocations done in
> alloc_netdev_mqs(), in order to switch to vmalloc() when kmalloc()
> fails.
>
Right, looks like the alloc_netdev_mqs uses kmalloc to require a huge number of contigious pages used by netdev_queue and netdev_rx_queue. Most of them are not needed when MQ is not enabled.I wonder whether we can solve the contigious page allocation in alloc_netdev_mqs() by using flex array instead of kmalloc() to allocate rx/tx queues.
Dirk, could you pls try the following patch that only allocate one queue when IFF_MULTI_QUEUE is not specified.
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 3f011e0..734085e 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1589,6 +1589,8 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
else {
char *name;
unsigned long flags = 0;
+ int queues = ifr->ifr_flags & IFF_MULTI_QUEUE ?
+ MAX_TAP_QUEUES : 1;
if (!ns_capable(net->user_ns, CAP_NET_ADMIN))
return -EPERM;
@@ -1612,8 +1614,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
name = ifr->ifr_name;
dev = alloc_netdev_mqs(sizeof(struct tun_struct), name,
- tun_setup,
- MAX_TAP_QUEUES, MAX_TAP_QUEUES);
+ tun_setup, queues, queues);
if (!dev)
return -ENOMEM;
> commit c8d68e6be1c3b242f1c598595830890b65cea64a
> Author: Jason Wang <jasowang@redhat.com>
> Date: Wed Oct 31 19:46:00 2012 +0000
>
> tuntap: multiqueue support
>
> This patch converts tun/tap to a multiqueue devices and expose the
> multiqueue queues as multiple file descriptors to userspace. Internally,
> each tun_file were abstracted as a queue, and an array of pointers to
> tun_file structurs were stored in tun_structure device, so multiple
> tun_files were allowed to be attached to the device as multiple queues.
>
> When choosing txq, we first try to identify a flow through its rxhash,
> if it does not have such one, we could try recorded rxq and then use them
> to choose the transmit queue. This policy may be changed in the future.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply related
* Re: splice() giving unexpected EOF in 3.7.3 and 3.8-rc4+
From: David Miller @ 2013-01-21 4:21 UTC (permalink / raw)
To: eric.dumazet; +Cc: normalperson, linux-kernel, netdev, linux-fsdevel, w
In-Reply-To: <1358575996.3464.447.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 18 Jan 2013 22:13:16 -0800
> On Fri, 2013-01-18 at 21:54 -0800, Eric Dumazet wrote:
>
>>
>> Hmm, this might be already fixed in net-next tree, could you try it ?
>>
>
> Yes, running your program on net-next seems OK.
>
> David, we need the two following commits.
Tossed into 'net' and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] firewire net: Use LL_RESERVED_SPACE(), HH_DATA_OFF().
From: David Miller @ 2013-01-21 4:16 UTC (permalink / raw)
To: yoshfuji; +Cc: linux1394-devel, netdev, linux-kernel
In-Reply-To: <50FBA4BB.4010008@linux-ipv6.org>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Sun, 20 Jan 2013 17:03:07 +0900
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Applied.
^ permalink raw reply
* Re: [PATCH] firewire net: Ensure checksumming in upper layer.
From: David Miller @ 2013-01-21 4:16 UTC (permalink / raw)
To: yoshfuji; +Cc: linux1394-devel, netdev, linux-kernel
In-Reply-To: <50FBA02C.9030203@linux-ipv6.org>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Sun, 20 Jan 2013 16:43:40 +0900
> It is wrong to set skb->ip_summed to CHECKSUM_UNNECESSARY unless
> the device has already checked it.
>
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Applied.
^ permalink raw reply
* Re: [PATCH v4 2/3] net: split eth_mac_addr for better error handling
From: David Miller @ 2013-01-21 4:14 UTC (permalink / raw)
To: akong; +Cc: mst, rusty, qemu-devel, kvm, virtualization, netdev
In-Reply-To: <1358649789-2338-3-git-send-email-akong@redhat.com>
From: akong@redhat.com
Date: Sun, 20 Jan 2013 10:43:08 +0800
> From: Stefan Hajnoczi <stefanha@gmail.com>
>
> When we set mac address, software mac address in system and hardware mac
> address all need to be updated. Current eth_mac_addr() doesn't allow
> callers to implement error handling nicely.
>
> This patch split eth_mac_addr() to prepare part and real commit part,
> then we can prepare first, and try to change hardware address, then do
> the real commit if hardware address is set successfully.
>
> Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
> Signed-off-by: Amos Kong <akong@redhat.com>
This patch doesn't apply to net-next.
^ 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