* Re: [PATCH 0/8] gianfar: Add support for hibernation
From: David Miller @ 2009-10-13 19:09 UTC (permalink / raw)
To: afleming; +Cc: scottwood, linuxppc-dev, netdev
In-Reply-To: <64B2BB18-32DC-4B98-95D6-F203F74040D5@freescale.com>
From: Andy Fleming <afleming@freescale.com>
Date: Tue, 13 Oct 2009 12:22:38 -0500
> No, it was fine (though made unnecessary by other patches). The BD
> has a union:
>
> struct {
> u16 status; /* Status Fields */
> u16 length; /* Buffer length */
> };
> u32 lstatus;
>
> so when you write "lstatus", you need to use the BD_LFLAG() macro, but
> when you write "status", you are just setting the status bits.
Indeed I missed that, thanks.
^ permalink raw reply
* Re: [PATCH] r8169: partial support and phy init for the 8168d
From: David Miller @ 2009-10-13 19:01 UTC (permalink / raw)
To: romieu; +Cc: netdev, simon.farnsworth, edward_hsu
In-Reply-To: <20091007224420.GA20170@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Thu, 8 Oct 2009 00:44:20 +0200
> Extracted from Realtek's 8.012.00 r8168 driver.
>
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
> Tested-by: Simon Farnsworth <simon.farnsworth@onelan.com>
> Cc: Edward Hsu <edward_hsu@realtek.com.tw>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 2/2] [RFC] Add c/r support for connected INET sockets
From: Oren Laadan @ 2009-10-13 19:00 UTC (permalink / raw)
To: Dan Smith
Cc: containers-qjLDD68F18O7TbgM5vRIOg, netdev-u79uwXL29TY76Z2rM5mHXA,
John Dykstra
In-Reply-To: <87ws2zcjhe.fsf-FLMGYpZoEPULwtHQx/6qkW3U47Q5hpJU@public.gmane.org>
Dan Smith wrote:
> OL> * Did you test this with UDP too ?
>
> Not sendmail of course, but I have a little test program that
> maintains a DGRAM connection to the echo service on a remote node,
> yeah.
>
> OL> * What happens if the the clock on the target machine differs from
> OL> the clock on the origin machine ? (TCP timestamps)
>
> I guess maybe we should canonicalize the timeout values to something
> like "milliseconds after checkpoint start"? This would allow the
> remote system to reset the timers to something reasonable. It would
> also cause non-migration restarts to restore the timers appropriately
> for a coordinated restart of multiple machines.
IIRC, the TCP stack takes the timestamp for each packet directly from
jiffies. So you need to teach TCP to add a per-container (or you can
make it per-socket) delta to that timestamp.
>
> OL> * How confident are we that "bad" input in one or more fields,
> OL> that you don't currently sanitize, cannot create "bad" behavior ?
> OL> (bad can be kernel crash, unauthorized behavior, DoS etc)
>
> I'm going to say 0.052.
Ah ... sure ...
To avoid confusion, can you state the units :p
>
> I haven't evaluated much of it, no :)
I guess my point is that we want to ask the networking people this
question in an explicit way.
>
> OL> * How much does TCP rely on the validity of the info in the
> OL> protocol control block, and what sorts of bads can happen if it
> OL> isn't ? Would TCP be still happy if the URG point is bogus, would
> OL> it allow the user to sent packets otherwise disallowed (to that
> OL> user?), or maybe it could crash the kernel ?
>
> Good question, I'll have to look.
Ditto.
So I'm thinking, for both, do (1) put a big fat comment in the code
saying that sanity-tests are needed, and what for, and (2) send a
separate mail to the networking people with these two scenarios and
request comments ?
>
> OL> * Can you please document (brief description) how the restart
> OL> logic works (listening parent socket etc) ?
>
> Sure.
>
> OL> * Do you intend to checkpoint (and collect) lingering sockets,
> OL> that is they are closed by the application so not references by
> OL> any task, but still sending data from their buffers ?
>
> Yeah, I expect that will be important :)
Cool. How about a TODO comment somewhere to convince everyone ( = me)
that you have it in your plans :)
>
> OL> * I'd like to also preserve the "older" behavior - so the user can
> OL> choose to restart and reset all previous connections, keep
> OL> listening sockets (e.g. RESTART_DISCONNET).
>
> Sure, sounds good to me.
>
>>> + printk("Doing post-restart hash\n");
>
> (oops, looks like I left some debug messages in place)
>
> OL> I wonder if a user can use this to convince TCP to send some nasty
> OL> packets to some arbitrary destination, with specific seq-number or
> OL> what not ?
>
> I'm not sure what you mean. The sk->num value comes from the sport
> which should have been refused during the bind() if it's in use or not
> permitted, no?
I think Serge already pointed in his review that this should not permit
a user to bind inconsistent or restricted ports.
I actually meant the contrary: suppose a malicious user on your machine
wants to attack a target machine/connection. can that user provide such
destination-address data and protocol parameters to build a connection
that locally seems valid, but is malicious ?
For example, now, if a user wants to send a TCP packet with arbitrary
protocol parameters, he needs to use raw IP sockets, which require
privilege. Would restarting a connection with the desired parameters
become a way to bypass that restriction ? (e.g. assume the user
restarts while using the host's network namespace).
Oren.
^ permalink raw reply
* Re: [PATCH] r8169: partial support and phy init for the 8168d
From: David Miller @ 2009-10-13 18:56 UTC (permalink / raw)
To: romieu; +Cc: netdev, simon.farnsworth, edward_hsu
In-Reply-To: <20091013174907.GA7267@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Tue, 13 Oct 2009 19:49:07 +0200
> Must I submit again or change something ?
No, I've got it, don't worry about it.
^ permalink raw reply
* Re: PATCH: Network Device Naming mechanism and policy
From: Ben Hutchings @ 2009-10-13 18:56 UTC (permalink / raw)
To: Dan Williams
Cc: Karl O. Pinc, Greg KH, Narendra K, notting, matt_domsch, netdev,
shemminger, linux-hotplug, jordan_hargrave, charles_rose
In-Reply-To: <1255457860.2196.24.camel@localhost.localdomain>
On Tue, 2009-10-13 at 11:17 -0700, Dan Williams wrote:
> On Mon, 2009-10-12 at 14:41 -0500, Karl O. Pinc wrote:
> > On 10/12/2009 02:09:00 PM, Greg KH wrote:
> >
> > > "LOM"?
> >
> > "LAN On Motherboard" of all things.
> >
> > (I had to look this
> > one up. The expansion better suited
> > to today's economy is "Low On Manna".)
>
> Or the previous usage from Sun, Apple, and others: "Lights Out
> Management". Not sure why they needed to clash with a name already used
> in server-space, but perhaps I'm just out-of-date and there's a fancier
> name for LOM these days, and LOM got repurposed.
It's widely used with both meanings - what's more, LOM is an expected
feature of LOMs. :-)
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* RE: PATCH: Network Device Naming mechanism and policy
From: Narendra_K @ 2009-10-13 18:53 UTC (permalink / raw)
To: dcbw, greg
Cc: shemminger, Matt_Domsch, netdev, linux-hotplug, Jordan_Hargrave
In-Reply-To: <1255456950.2196.18.camel@localhost.localdomain>
>If the BIOS support exists, it is trivial to use udev to
>create the correct naming mechanism for your machine, either
>using MAC address or BIOS-provided slot naming. No kernel
>patch is required.
>
Yes. In case, we want to rename only once. MAC address or slot names do
provide persistent naming. They help in retaining whatever names are
assigned during install time, which is the first instantiation of the
OS. But these names may not be as expected (like first on board network
interface name is expected to be "eth0" which is not always the case and
might not reflect what is written on the chassis label as "Gb1" and
"Gb2" etc) which would result in unattended installs break. Also image
based deployments will face problems by introducing state such as MAC
address.
With regards,
Narendra K
^ permalink raw reply
* Re: [PATCHv2 1/4] First Patch on TFRC-SP. Copy base files from TFRC
From: Jarek Poplawski @ 2009-10-13 18:53 UTC (permalink / raw)
To: Ivo Calado; +Cc: dccp, netdev
In-Reply-To: <cb00fa210910131125m17eca24cx4a912e75f91f0fd2@mail.gmail.com>
On Tue, Oct 13, 2009 at 03:25:48PM -0300, Ivo Calado wrote:
> On Tue, Oct 13, 2009 at 15:21, Jarek Poplawski <jarkao2@gmail.com> wrote:
> > On Tue, Oct 13, 2009 at 03:12:14PM -0300, Ivo Calado wrote:
> >> On Tue, Oct 13, 2009 at 15:06, Jarek Poplawski <jarkao2@gmail.com> wrote:
> >> > Ivo Calado wrote, On 10/13/2009 07:18 PM:
> >> >
> >> > ...
> >> >> Following the rule #8 in Documentation/SubmittingPatches the patch is
...
> >> 8) E-mail size.
> >>
> >> ...
> >> Large changes are not appropriate for mailing lists, and some
> >> maintainers. If your patch, uncompressed, exceeds 40 kB in size,
...
> > Large changes are not appropriate for mailing lists, and some
> > maintainers. If your patch, uncompressed, exceeds 300 kB in size,
...
> Hi Jarek,
> strange! I'm using the current DCCP test tree, branch dccp.
> Am I correct in use these rules?
Hmm... Looks like a fresh change in Linus' (and net-next) tree. So,
there is a hard legal question: which tree rules should be respected
here?
I guess you're one of a few respecting these rules ;-) Well done!
Best regards,
Jarek P.
^ permalink raw reply
* Re: PATCH: Network Device Naming mechanism and policy
From: Ben Hutchings @ 2009-10-13 18:53 UTC (permalink / raw)
To: Dan Williams
Cc: Bill Nottingham, Scott James Remnant, Matt Domsch, Narendra K,
netdev, linux-hotplug, jordan_hargrave
In-Reply-To: <1255457182.2196.21.camel@localhost.localdomain>
On Tue, 2009-10-13 at 11:06 -0700, Dan Williams wrote:
> On Mon, 2009-10-12 at 13:37 -0400, Bill Nottingham wrote:
> > Scott James Remnant (scott@ubuntu.com) said:
> > > On the other hand, they *tend* to be unique for a wide range of systems.
> > > This makes them pretty comparable to LABELs on disks, and we have
> > > a /dev/disk/by-label
> > >
> > > Remember that udev already supports symlink stacking, and priorities and
> > > such.
> > >
> > > I don't think there's any danger of supporting a /dev/netdev/by-mac by
> > > default, it'll be a benefit to most and those who don't have unique MACs
> > > will just ignore it.
> >
> > At the moment, we do not appear to get the proper change uevents from things
> > like 'ip link set dev <foo> address <bar>', so we can't currently maintain
> > these symlinks.
>
> And if we really want seamless support for MAC spoofing, we want
> ETHTOOL_GPERMADDR for all drivers too, so that if your configuration
> says "rename device XX:XX:XX:XX:XX:XX to YY:YY:YY:YY:YY:YY" we can
> actually figure stuff out after the spoof.
ETHTOOL_GPERMADDR is handled in the ethtool core now. Are you thinking
of drivers that don't have ethtool ops? Maybe it's time to add default
operations.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] net: Add netdev_alloc_skb_ip_align() helper
From: David Miller @ 2009-10-13 18:53 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4AD49DFC.9020406@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 13 Oct 2009 17:34:20 +0200
> [PATCH net-next-2.6] net: Use netdev_alloc_skb_ip_align()
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 0/5] netxen: add diagnostic tools support
From: David Miller @ 2009-10-13 18:53 UTC (permalink / raw)
To: dhananjay; +Cc: netdev, ameen.rahman
In-Reply-To: <1255447905-29805-1-git-send-email-dhananjay@netxen.com>
From: Dhananjay Phadke <dhananjay@netxen.com>
Date: Tue, 13 Oct 2009 08:31:40 -0700
> Series of 5 patches to add diagostic and various other
> (internal) tools support.
>
> Please apply to net-next-2.6.
Applied, thanks.
^ permalink raw reply
* Re: [PATCHv2 1/4] First Patch on TFRC-SP. Copy base files from TFRC
From: Arnaldo Carvalho de Melo @ 2009-10-13 18:42 UTC (permalink / raw)
To: Ivo Calado; +Cc: Jarek Poplawski, dccp, netdev
In-Reply-To: <cb00fa210910131125m17eca24cx4a912e75f91f0fd2@mail.gmail.com>
Em Tue, Oct 13, 2009 at 03:25:48PM -0300, Ivo Calado escreveu:
> strange! I'm using the current DCCP test tree, branch dccp.
> Am I correct in use these rules?
Follow the rules in the latest Documentation/SubmittingPatches file,
that is:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/SubmittingPatches;hb=HEAD
And that states:
-------------------------------------------------------------------
8) E-mail size.
When sending patches to Linus, always follow step #7.
Large changes are not appropriate for mailing lists, and some
maintainers. If your patch, uncompressed, exceeds 300 kB in size,
it is preferred that you store your patch on an Internet-accessible
server, and provide instead a URL (link) pointing to your patch.
-------------------------------------------------------------------
As Jarek pointed out.
- Arnaldo
^ permalink raw reply
* Re: pull request: wireless-2.6 2009-10-13
From: David Miller @ 2009-10-13 18:42 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20091013150558.GC2747@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 13 Oct 2009 11:05:58 -0400
> Here are a few (almost-)one-liners for 2.6.32. Included are fixes for
> a use-after-free, a missing "!" in front of a memcmp when comparing
> BSSIDs, a race when using hardware-based scanning, the ieee80211_rx
> context problem, a related documentation change, and a minor build
> issue.
>
> Please let me know if there are problems!
Pulled, thanks a lot!
^ permalink raw reply
* Re: [PATCHv2 1/4] First Patch on TFRC-SP. Copy base files from TFRC
From: Ivo Calado @ 2009-10-13 18:25 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: dccp, netdev
In-Reply-To: <20091013182144.GA3338@del.dom.local>
On Tue, Oct 13, 2009 at 15:21, Jarek Poplawski <jarkao2@gmail.com> wrote:
> On Tue, Oct 13, 2009 at 03:12:14PM -0300, Ivo Calado wrote:
>> On Tue, Oct 13, 2009 at 15:06, Jarek Poplawski <jarkao2@gmail.com> wrote:
>> > Ivo Calado wrote, On 10/13/2009 07:18 PM:
>> >
>> > ...
>> >> Following the rule #8 in Documentation/SubmittingPatches the patch is
>> >> stored at
>> >> http://embedded.ufcg.edu.br/~ivocalado/dccp/patches/patches_tfrc_sp_receiver-v2/tfrc_sp_receiver_01.patch
>> >>
>> >
>> > Does this patch really exceed 300kb in size?
>> >
>> > Jarek P.
>> >
>>
>>
>> Hi jarek,
>> This patch has 68kb in size, but in the rule #8 it says:
>>
>>
>> 8) E-mail size.
>>
>> ...
>> Large changes are not appropriate for mailing lists, and some
>> maintainers. If your patch, uncompressed, exceeds 40 kB in size,
>> it is preferred that you store your patch on an Internet-accessible
>> server, and provide instead a URL (link) pointing to your patch.
>> "
>
> Hi Ivo,
> Current version?
>
> "8) E-mail size.
>
> When sending patches to Linus, always follow step #7.
>
> Large changes are not appropriate for mailing lists, and some
> maintainers. If your patch, uncompressed, exceeds 300 kB in size,
> it is preferred that you store your patch on an Internet-accessible
> server, and provide instead a URL (link) pointing to your patch.
> "
>
> Jarek P.
>
Hi Jarek,
strange! I'm using the current DCCP test tree, branch dccp.
Am I correct in use these rules?
best regards,
Ivo
--
Ivo Augusto Andrade Rocha Calado
MSc. Candidate
Embedded Systems and Pervasive Computing Lab - http://embedded.ufcg.edu.br
Systems and Computing Department - http://www.dsc.ufcg.edu.br
Electrical Engineering and Informatics Center - http://www.ceei.ufcg.edu.br
Federal University of Campina Grande - http://www.ufcg.edu.br
PGP: 0x03422935
Quidquid latine dictum sit, altum viditur.
^ permalink raw reply
* Re: [PATCHv2 1/4] First Patch on TFRC-SP. Copy base files from TFRC
From: Jarek Poplawski @ 2009-10-13 18:21 UTC (permalink / raw)
To: Ivo Calado; +Cc: dccp, netdev
In-Reply-To: <cb00fa210910131112w5e4cc3a6gd46b480efdb55262@mail.gmail.com>
On Tue, Oct 13, 2009 at 03:12:14PM -0300, Ivo Calado wrote:
> On Tue, Oct 13, 2009 at 15:06, Jarek Poplawski <jarkao2@gmail.com> wrote:
> > Ivo Calado wrote, On 10/13/2009 07:18 PM:
> >
> > ...
> >> Following the rule #8 in Documentation/SubmittingPatches the patch is
> >> stored at
> >> http://embedded.ufcg.edu.br/~ivocalado/dccp/patches/patches_tfrc_sp_receiver-v2/tfrc_sp_receiver_01.patch
> >>
> >
> > Does this patch really exceed 300kb in size?
> >
> > Jarek P.
> >
>
>
> Hi jarek,
> This patch has 68kb in size, but in the rule #8 it says:
>
>
> 8) E-mail size.
>
> ...
> Large changes are not appropriate for mailing lists, and some
> maintainers. If your patch, uncompressed, exceeds 40 kB in size,
> it is preferred that you store your patch on an Internet-accessible
> server, and provide instead a URL (link) pointing to your patch.
> "
Hi Ivo,
Current version?
"8) E-mail size.
When sending patches to Linus, always follow step #7.
Large changes are not appropriate for mailing lists, and some
maintainers. If your patch, uncompressed, exceeds 300 kB in size,
it is preferred that you store your patch on an Internet-accessible
server, and provide instead a URL (link) pointing to your patch.
"
Jarek P.
^ permalink raw reply
* Re: PATCH: Network Device Naming mechanism and policy
From: Dan Williams @ 2009-10-13 18:17 UTC (permalink / raw)
To: Karl O. Pinc
Cc: Greg KH, Narendra K, notting, matt_domsch, netdev, shemminger,
linux-hotplug, jordan_hargrave, charles_rose
In-Reply-To: <1255376510.3956.1@mofo>
On Mon, 2009-10-12 at 14:41 -0500, Karl O. Pinc wrote:
> On 10/12/2009 02:09:00 PM, Greg KH wrote:
>
> > "LOM"?
>
> "LAN On Motherboard" of all things.
>
> (I had to look this
> one up. The expansion better suited
> to today's economy is "Low On Manna".)
Or the previous usage from Sun, Apple, and others: "Lights Out
Management". Not sure why they needed to clash with a name already used
in server-space, but perhaps I'm just out-of-date and there's a fancier
name for LOM these days, and LOM got repurposed.
Dan
^ permalink raw reply
* Re: [PATCHv2 1/4] First Patch on TFRC-SP. Copy base files from TFRC
From: Ivo Calado @ 2009-10-13 18:12 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: dccp, netdev
In-Reply-To: <4AD4C19E.5060608@gmail.com>
On Tue, Oct 13, 2009 at 15:06, Jarek Poplawski <jarkao2@gmail.com> wrote:
> Ivo Calado wrote, On 10/13/2009 07:18 PM:
>
> ...
>> Following the rule #8 in Documentation/SubmittingPatches the patch is
>> stored at
>> http://embedded.ufcg.edu.br/~ivocalado/dccp/patches/patches_tfrc_sp_receiver-v2/tfrc_sp_receiver_01.patch
>>
>
> Does this patch really exceed 300kb in size?
>
> Jarek P.
>
Hi jarek,
This patch has 68kb in size, but in the rule #8 it says:
8) E-mail size.
...
Large changes are not appropriate for mailing lists, and some
maintainers. If your patch, uncompressed, exceeds 40 kB in size,
it is preferred that you store your patch on an Internet-accessible
server, and provide instead a URL (link) pointing to your patch.
"
--
Ivo Augusto Andrade Rocha Calado
MSc. Candidate
Embedded Systems and Pervasive Computing Lab - http://embedded.ufcg.edu.br
Systems and Computing Department - http://www.dsc.ufcg.edu.br
Electrical Engineering and Informatics Center - http://www.ceei.ufcg.edu.br
Federal University of Campina Grande - http://www.ufcg.edu.br
PGP: 0x03422935
Quidquid latine dictum sit, altum viditur.
^ permalink raw reply
* Re: Moving drivers into staging (was Re: [GIT PULL] SCSI fixes for 2.6.32-rc3)
From: Luis R. Rodriguez @ 2009-10-13 18:08 UTC (permalink / raw)
To: Greg KH
Cc: Ingo Molnar, James Bottomley, Linus Torvalds, Theodore Tso,
Andrew Morton, linux-scsi, linux-kernel, Jing Huang, netdev,
linux-wireless
In-Reply-To: <20091012232429.GA24254@suse.de>
On Mon, Oct 12, 2009 at 4:24 PM, Greg KH <gregkh@suse.de> wrote:
> On Mon, Oct 12, 2009 at 05:42:44PM +0200, Ingo Molnar wrote:
>> Hm, i think i even gave drivers/staging/ its name?
>
> Yes you did, and I appreciate it :)
>
>> > [...] It seems that I'm the only one that has the ability to drop
>> > drivers out of the kernel tree, which is a funny situation :)
>>
>> You are the only one who has the ability to send a warning shot towards
>> drivers _without hurting users_, and by moving it into the focus of a
>> team of cleanup oriented developers.
>>
>> I think that's an important distinction ;-)
>
> Good point.
>
>> > In thinking about this a lot more, I don't really mind it. If people
>> > want to push stuff out of "real" places in the kernel, into
>> > drivers/staging/ and give the original authors and maintainers notice
>> > about what is going on, _and_ provide a TODO file for what needs to
>> > happen to get the code back into the main portion of the kernel tree,
>> > then I'll be happy to help out with this and manage it.
>> >
>> > I think a 6-9 month window (basically 3 kernel releases) should be
>> > sufficient time to have a driver that has been in drivers/staging/ be
>> > cleaned up enough to move back into the main kernel tree. If not, it
>> > could be easily dropped.
>> >
>> > Any objections to this?
>>
>> Sounds excellent to me!
>
> Great, I'll await the patches to move stuff to drivers/staging/ now.
>
> Wireless developers, warm up your editors :)
OK -- prism54 seems like a good candidate, instead of removing it
completely as I originally outlined on the feature removal schedule.
Do we have a file to give notices to move drivers to staging because
they are old as with the feature removal schedule? The more visible
these things become the better it is for users.
Luis
^ permalink raw reply
* Re: [PATCHv2 1/4] First Patch on TFRC-SP. Copy base files from TFRC
From: Jarek Poplawski @ 2009-10-13 18:06 UTC (permalink / raw)
To: Ivo Calado; +Cc: dccp, netdev
In-Reply-To: <4AD4B677.4000308@embedded.ufcg.edu.br>
Ivo Calado wrote, On 10/13/2009 07:18 PM:
...
> Following the rule #8 in Documentation/SubmittingPatches the patch is
> stored at
> http://embedded.ufcg.edu.br/~ivocalado/dccp/patches/patches_tfrc_sp_receiver-v2/tfrc_sp_receiver_01.patch
>
Does this patch really exceed 300kb in size?
Jarek P.
^ permalink raw reply
* Re: [PATCH] net: Add netdev_alloc_skb_ip_align() helper
From: Eric Dumazet @ 2009-10-13 18:06 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20091013103037.475e2400@s6510>
Stephen Hemminger a écrit :
> Name_is_getting_too_damn_long can we think of something beter.
yes probably
>
> Also, it isn't really ip alignment but compensating for the ethernet
> header.
> alloc_ether_skb?
Dont know, but NET_IP_ALIGN was about making sure skb->data + sizeof(ethernet header)
is 4 bytes aligned, not for handling ethernet header itself in our stack (we only need
2 bytes alignement for this ethernet header), but IP header.
^ permalink raw reply
* Re: PATCH: Network Device Naming mechanism and policy
From: Dan Williams @ 2009-10-13 18:06 UTC (permalink / raw)
To: Bill Nottingham
Cc: Scott James Remnant, Matt Domsch, Narendra K, netdev,
linux-hotplug, jordan_hargrave
In-Reply-To: <20091012173705.GA22736@nostromo.devel.redhat.com>
On Mon, 2009-10-12 at 13:37 -0400, Bill Nottingham wrote:
> Scott James Remnant (scott@ubuntu.com) said:
> > On the other hand, they *tend* to be unique for a wide range of systems.
> > This makes them pretty comparable to LABELs on disks, and we have
> > a /dev/disk/by-label
> >
> > Remember that udev already supports symlink stacking, and priorities and
> > such.
> >
> > I don't think there's any danger of supporting a /dev/netdev/by-mac by
> > default, it'll be a benefit to most and those who don't have unique MACs
> > will just ignore it.
>
> At the moment, we do not appear to get the proper change uevents from things
> like 'ip link set dev <foo> address <bar>', so we can't currently maintain
> these symlinks.
And if we really want seamless support for MAC spoofing, we want
ETHTOOL_GPERMADDR for all drivers too, so that if your configuration
says "rename device XX:XX:XX:XX:XX:XX to YY:YY:YY:YY:YY:YY" we can
actually figure stuff out after the spoof.
Dan
^ permalink raw reply
* configure VF parameters from PF domain
From: Satish Chowdhury @ 2009-10-13 18:05 UTC (permalink / raw)
To: netdev
In-Reply-To: <be5d34890910131101w386bb753oc2798176558db3e0@mail.gmail.com>
Hi,
I am verifying the functionality of Intel 82576 based NIC card on
Xen. VF device is assigned(passthrough) to a VM.
I can configure the MAC, VLAN parameter of VF in the VM domain on the
VF interface. But, I want have control over the VF from PF domain.
i.e I should be able to configure VF MAC, VLAN parameters from PF
domain.
Is there any tool available ? Else give me pointers how the above can
be achieved? Is there a way to preconfigure VF parameters before
assigning VF to VM.
Regards,
-Satish
^ permalink raw reply
* Re: PATCH: Network Device Naming mechanism and policy
From: Dan Williams @ 2009-10-13 18:02 UTC (permalink / raw)
To: Greg KH
Cc: Stephen Hemminger, Matt Domsch, netdev, linux-hotplug, Narendra_K,
jordan_hargrave
In-Reply-To: <20091010210612.GA1927@kroah.com>
On Sat, 2009-10-10 at 14:06 -0700, Greg KH wrote:
> On Sat, Oct 10, 2009 at 11:32:19AM -0700, Stephen Hemminger wrote:
> >
> > BTW, for our distro, we are looking into device renaming based on PCI slot
> > because that is what router OS's do. Customers expect if they replace the card
> > in slot 0, it will come back with the same name. This is not what server
> > customers expect.
>
> If your bios exposes the PCI slots to userspace (through the proper ACPI
> namespace), doing this type of naming should be trivial with some simple
> udev rules, no additional kernel infrastructure is needed.
By and large, the people that care most about persistent network device
names based on *location in the machine* are server users. This allows
hotswap of cards or single-image-multiple-machine without needing
configuration changes, which is nice.
Those users can reasonably be expected to choose hardware whose BIOS
supports the ACPI tables that (mostly) guarantee to provide actual,
stable names for their hardware. If there's even a 10% chance that on
consumer-level systems the names won't be stable on a given boot (and I
can't see how, without BIOS support, we can guarantee 100% stability)
then it's a worthless guarantee.
If the BIOS support exists, it is trivial to use udev to create the
correct naming mechanism for your machine, either using MAC address or
BIOS-provided slot naming. No kernel patch is required.
If the BIOS support does not exist, you are not guaranteed a stable
naming mechanism except by MAC address, because the BIOS may randomly
change enumeration based on the time of day, or it may not. A 90 or 95%
stability guarantee is not a guarantee at all.
Third, USB enumeration will always be unstable. Thus we have an
unsolvable discrepancy in behavior between PCI and USB.
Is this correct?
Dan
^ permalink raw reply
* Re: [PATCH] r8169: partial support and phy init for the 8168d
From: Francois Romieu @ 2009-10-13 17:49 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Simon Farnsworth, Edward Hsu
In-Reply-To: <20091007224420.GA20170@electric-eye.fr.zoreil.com>
Must I submit again or change something ?
--
Ueimor
^ permalink raw reply
* Re: PATCH: Network Device Naming mechanism and policy
From: dann frazier @ 2009-10-13 17:36 UTC (permalink / raw)
To: Narendra_K
Cc: netdev, linux-hotplug, Matt_Domsch, Jordan_Hargrave, Charles_Rose
In-Reply-To: <EDA0A4495861324DA2618B4C45DCB3EE58954D@blrx3m08.blr.amer.dell.com>
1;2202;0cOn Tue, Oct 13, 2009 at 10:43:49PM +0530, Narendra_K@Dell.com wrote:
>
> >> These device nodes are not functional at the moment - open() returns
> >> -ENOSYS. Their only purpose is to provide userspace with a kernel
> >> name to ifindex mapping, in a form that udev can easily manage.
> >
> >If the idea is just to provide a userspace-visible mapping
> >(and presumably take advantage of udev's infrastructure for
> >naming) does this need kernel changes? Could this be a
> >hierarchy under e.g. /etc/udev instead, using plain text
> >files? It still means we need something like libnetdevname for
> >apps to do the translation, but I'm not seeing why it matters
> >how this map is stored. Is there some special property of the
> >character devices (e.g. uevents) that we're not already
> >getting with the existing interfaces?
>
> Yes. The char device by itself doesn't help in any way. But it provides
> a flexible mechanism to provide multiple names for the same device, just
> the way it is for disks.
Right - so any reason this couldn't be implemented completely in
userspace by having udev manipulate plain text files under say
/etc/udev/net/?
I do agree that it would be nice for admins/installers to tweak/use
nic names in a similar way to storage names (udev rules), and it might
let us take advantage of a lot of the existing udev code.
--
dann frazier
^ permalink raw reply
* Re: behaviour question for igb on nehalem box
From: Chris Friesen @ 2009-10-13 17:32 UTC (permalink / raw)
To: Alexander Duyck
Cc: e1000-list, Linux Network Development list, Allan, Bruce W,
Brandeburg, Jesse, Ronciak, John, Kirsher, Jeffrey T,
gospo@redhat.com
In-Reply-To: <4ACFCBE8.7060108@intel.com>
On 10/09/2009 05:48 PM, Alexander Duyck wrote:
> The odds of any 2 flows overlapping when you are only using 4 flows is
> pretty high, especially if the addresses/ports are close in range. You
> typically need something on the order of about 16 flows over a wide
> range of port numbers in order to get a good distribution.
Yes, I realize this. However, I was surprised that we were seeing the
packet count increasing for only one queue but the interrupt count
increasing for more than one.
Also, if we really crank up the traffic levels the box apparently
panics. They're working on getting a serial cable hooked up to it to
get the debug information, so I don't really have much information on
that part just yet.
We're going to try the out-of-tree drivers. Unfortunately it appears
that the out-of-tree igb driver doesn't compile for this kernel. I
suspect the compat code needs tweaking.
Chris
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
^ 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