* Re: [PATCH] gianfar v5: implement nfc
From: Sebastian.Poehn @ 2011-06-27 14:43 UTC (permalink / raw)
To: joe; +Cc: netdev
In-Reply-To: <1308761280.10423.19.camel@Joe-Laptop>
Thanks for your feedback Joe!
> I'm a bit confused by this:
/*
* What we already have:
* A temporary copy of the filer table which will later replace the current one.
* In the filer table we always have one mask entry followed by a value (of action).
* Further we have the mask table which is a list of all mask in the filer table.
* To every entry we have the start and the end of the validity and a block index
* (same block indexes means dependency). We want to sort every dependent block!
*/
static void gfar_sort_mask_table(struct gfar_mask_entry *mask_table,
struct filer_table *temp_table, u32 and_index)
{
/* Pointer to compare function (_asc or _desc) */
int (*gfar_comp)(const void *, const void *);
u32 i, size = 0, start = 0, prev = 1;
u32 old_first, old_last, new_first, new_last;
gfar_comp = &gfar_comp_desc;
for (i = 0; i < and_index; i++) {
/* As long, as the block is the same (dependency) we only increase
* the size */
if (prev != mask_table[i].block) {
/* The +1 is because start is a mask and the important
* FF80 information is located in the next value element */
old_first = mask_table[start].start + 1;
/* -1 because we are already at the start of the next dependent block */
old_last = mask_table[i - 1].end;
/* Here the mask table is sorted! So the entries in the current
* block change may change their location */
sort(mask_table + start, size,
sizeof(struct gfar_mask_entry),
gfar_comp, &gfar_swap);
/* Toggle order for every block. This makes the
* thing more efficient! */
if (gfar_comp == gfar_comp_desc)
gfar_comp = &gfar_comp_asc;
else
gfar_comp = &gfar_comp_desc;
/* The same as above but the elements are others because of the sorting */
new_first = mask_table[start].start + 1;
new_last = mask_table[i - 1].end;
gfar_swap_bits(&temp_table->fe[new_first],
&temp_table->fe[old_first],
&temp_table->fe[new_last],
&temp_table->fe[old_last],
RQFCR_QUEUE | RQFCR_CLE |
RQFCR_RJE | RQFCR_AND
);
start = i;
size = 0;
}
size++;
prev = mask_table[i].block;
}
}
> Doesn't this just swap the same bits around twice?
Due to the masks are sorted numerically it is possible that a mask from any location changes its locations to ANY. Lets think of this example and the usage of the sequential swapping:
A has a header <- old_first new position after sorting: 2
B <- new_last new position after sorting: 4
C new position after sorting: 3
D has a trailer <- old_last and new_first new position after sorting: 1
First swap first:
A has a trailer
B
C
D has a header
Second swap:
A has a trailer
B has a header
C
D
And now after the sorted order is applied:
D
A has a trailer
C
B has a header
Thats not correct!
The concurrent swapper does:
A
B has a trailer
C
D has a header
And:
D has a header
A
C
B has a trailer
That's all right!
DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.
^ permalink raw reply
* Re: [PATCH] net/can: activate bit-timing calculation and netlink based drivers by default
From: Marc Kleine-Budde @ 2011-06-27 14:49 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
socketcan-users-0fE9KPoRgkgATYTw5x5z8w, wg-5Yr1BZd7O62+XT7JhA+gdA
In-Reply-To: <20110627135044.GF318-MxZ6Iy/zr/UdbCeoMzGj59i2O/JbrIOy@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1653 bytes --]
On 06/27/2011 03:50 PM, Kurt Van Dijck wrote:
> Is this modification then also the right thing to do?
yes - there's no need for "default N' (or 'default n') as it's default.
> diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
> index 1d699e3..ac48574 100644
> --- a/drivers/net/can/Kconfig
> +++ b/drivers/net/can/Kconfig
> @@ -4,7 +4,6 @@ menu "CAN Device Drivers"
> config CAN_VCAN
> tristate "Virtual Local CAN Interface (vcan)"
> depends on CAN
> - default N
> ---help---
> Similar to the network loopback devices, vcan offers a
> virtual local CAN interface.
> @@ -15,7 +14,6 @@ config CAN_VCAN
> config CAN_SLCAN
> tristate "Serial / USB serial CAN Adaptors (slcan)"
> depends on CAN
> - default N
> ---help---
> CAN driver for several 'low cost' CAN interfaces that are attached
> via serial lines or via USB-to-serial adapters using the LAWICEL
> @@ -124,7 +122,6 @@ source "drivers/net/can/softing/Kconfig"
> config CAN_DEBUG_DEVICES
> bool "CAN devices debugging messages"
> depends on CAN
> - default N
> ---help---
> Say Y here if you want the CAN device drivers to produce a bunch of
> debug messages to the system log. Select this if you are having
If you make a patch from it...
Acked-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 191 bytes --]
_______________________________________________
Socketcan-users mailing list
Socketcan-users-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-users
^ permalink raw reply
* Re: SKB paged fragment lifecycle on receive
From: Ian Campbell @ 2011-06-27 14:42 UTC (permalink / raw)
To: Eric Dumazet
Cc: Jeremy Fitzhardinge, netdev@vger.kernel.org, xen-devel,
Rusty Russell
In-Reply-To: <1308938183.2532.8.camel@edumazet-laptop>
On Fri, 2011-06-24 at 18:56 +0100, Eric Dumazet wrote:
> Le vendredi 24 juin 2011 à 10:29 -0700, Jeremy Fitzhardinge a écrit :
> > On 06/24/2011 08:43 AM, Ian Campbell wrote:
> > > We've previously looked into solutions using the skb destructor callback
> > > but that falls over if the skb is cloned since you also need to know
> > > when the clone is destroyed. Jeremy Fitzhardinge and I subsequently
> > > looked at the possibility of a no-clone skb flag (i.e. always forcing a
> > > copy instead of a clone) but IIRC honouring it universally turned into a
> > > very twisty maze with a number of nasty corner cases etc. It also seemed
> > > that the proportion of SKBs which get cloned at least once appeared as
> > > if it could be quite high which would presumably make the performance
> > > impact unacceptable when using the flag. Another issue with using the
> > > skb destructor is that functions such as __pskb_pull_tail will eat (and
> > > free) pages from the start of the frag array such that by the time the
> > > skb destructor is called they are no longer there.
> > >
> > > AIUI Rusty Russell had previously looked into a per-page destructor in
> > > the shinfo but found that it couldn't be made to work (I don't remember
> > > why, or if I even knew at the time). Could that be an approach worth
> > > reinvestigating?
> > >
> > > I can't really think of any other solution which doesn't involve some
> > > sort of driver callback at the time a page is free()d.
> >
>
> This reminds me the packet mmap (tx path) games we play with pages.
>
> net/packet/af_packet.c : tpacket_destruct_skb(), poking
> TP_STATUS_AVAILABLE back to user to tell him he can reuse space...
This is OK because af_packet involves no kernel side protocol and hence
there can be no retransmits etc? Otherwise you would suffer from the
same sorts of issues as I described with NFS at [0]?
However it seems like this might still have a problem if your SKBs are
ever cloned. What happens in this case, e.g if a user of AF_PACKET sends
a broadcast via a device associated with a bridge[1] (where it would be
flooded)?
Wouldn't you get into the situation where the destructor of the initial
skb is called before one or more of the clones going to a different
destination were sent. So you would send TP_STATUS_AVAILABLE to
userspace before the stack was really finished with the page and run the
risk of userspace reusing the buffer, leading to incorrect bytes going
to some destinations?
It looks to me that anything which does any zero-copy type thing to the
network stack will have problems with one or both of protocol retransmit
or SKB clone. There's simply no mechanism to know when the stack is
really finished with a page.
Ian.
[0] http://marc.info/?l=linux-nfs&m=122424132729720&w=2
[1] Since dhcp clients typically use AF_PACKET and you typically put the
IP address on the bridge itself in these configurations this won't be
that unusual.
Ian.
^ permalink raw reply
* Re: [RFT PATCH v3 00/12] Cleanup and extension of netdev features
From: Michał Mirosław @ 2011-06-27 14:21 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev, David S. Miller, Ben Hutchings
In-Reply-To: <4E0276A0.8010802@candelatech.com>
On Wed, Jun 22, 2011 at 04:11:28PM -0700, Ben Greear wrote:
> On 06/22/2011 09:04 AM, Michał Mirosław wrote:
> >v3 of a feature handling cleanup and extension series. For testing, you
> >might want user-space ethtool patched with:
> >
> >http://patchwork.ozlabs.org/patch/96374/
> There is a typo in one of those patches:
> CC fs/quota/netlink.o
> /home/greearb/git/net-next-2.6/net/core/dev.c: In function ‘__netdev_update_features’:
> /home/greearb/git/net-next-2.6/net/core/dev.c:5288: warning: too many arguments for format
> CC net/core/ethtool.o
> netdev_dbg(dev, "Features changed: %pNF -> pNF\n",
> &dev->features, &features);
Noted for next version.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [PATCH] net/can: activate bit-timing calculation and netlink based drivers by default
From: Kurt Van Dijck @ 2011-06-27 13:50 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
socketcan-users-0fE9KPoRgkgATYTw5x5z8w,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, wg-5Yr1BZd7O62+XT7JhA+gdA
In-Reply-To: <1309160391-22486-1-git-send-email-mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Is this modification then also the right thing to do?
diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
index 1d699e3..ac48574 100644
--- a/drivers/net/can/Kconfig
+++ b/drivers/net/can/Kconfig
@@ -4,7 +4,6 @@ menu "CAN Device Drivers"
config CAN_VCAN
tristate "Virtual Local CAN Interface (vcan)"
depends on CAN
- default N
---help---
Similar to the network loopback devices, vcan offers a
virtual local CAN interface.
@@ -15,7 +14,6 @@ config CAN_VCAN
config CAN_SLCAN
tristate "Serial / USB serial CAN Adaptors (slcan)"
depends on CAN
- default N
---help---
CAN driver for several 'low cost' CAN interfaces that are attached
via serial lines or via USB-to-serial adapters using the LAWICEL
@@ -124,7 +122,6 @@ source "drivers/net/can/softing/Kconfig"
config CAN_DEBUG_DEVICES
bool "CAN devices debugging messages"
depends on CAN
- default N
---help---
Say Y here if you want the CAN device drivers to produce a bunch of
debug messages to the system log. Select this if you are having
^ permalink raw reply related
* Re: [PATCH] NET: TC35815: Only build driver on Toshiba eval boards.
From: Atsushi Nemoto @ 2011-06-27 12:57 UTC (permalink / raw)
To: ralf; +Cc: davem, netdev, linux-mips
In-Reply-To: <20110625165409.GA1760@linux-mips.org>
On Sat, 25 Jun 2011 17:54:09 +0100, Ralf Baechle <ralf@linux-mips.org> wrote:
> That's the only place where the TC35815 is known to be used.
>
> Ralf
>
> drivers/net/Kconfig | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index be25e92..2b4ebfb 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -1516,7 +1516,8 @@ config CS89x0_NONISA_IRQ
>
> config TC35815
> tristate "TOSHIBA TC35815 Ethernet support"
> - depends on NET_PCI && PCI && MIPS
> + depends on NET_PCI && PCI && MACH_TXX9
> + default y
> select PHYLIB
>
> config E100
Yes, OK for me.
Acked-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
^ permalink raw reply
* Re: SKB paged fragment lifecycle on receive
From: Michael S. Tsirkin @ 2011-06-27 11:19 UTC (permalink / raw)
To: Ian Campbell
Cc: netdev@vger.kernel.org, Jeremy Fitzhardinge, xen-devel,
mashirle@us.ibm.com, Rusty Russell
In-Reply-To: <1309172042.32717.199.camel@zakaz.uk.xensource.com>
On Mon, Jun 27, 2011 at 11:54:02AM +0100, Ian Campbell wrote:
> On Mon, 2011-06-27 at 11:21 +0100, Michael S. Tsirkin wrote:
> > On Mon, Jun 27, 2011 at 10:41:35AM +0100, Ian Campbell wrote:
> > > On Sun, 2011-06-26 at 11:25 +0100, Michael S. Tsirkin wrote:
> > > > On Fri, Jun 24, 2011 at 04:43:22PM +0100, Ian Campbell wrote:
> > > > > In this mode guest data pages ("foreign pages") were mapped into the
> > > > > backend domain (using Xen grant-table functionality) and placed into the
> > > > > skb's paged frag list (skb_shinfo(skb)->frags, I hope I am using the
> > > > > right term). Once the page is finished with netback unmaps it in order
> > > > > to return it to the guest (we really want to avoid returning such pages
> > > > > to the general allocation pool!).
> > > >
> > > > Are the pages writeable by the source guest while netback processes
> > > > them? If yes, firewalling becomes unreliable as the packet can be
> > > > modified after it's checked, right?
> > >
> > > We only map the paged frags, the linear area is always copied (enough to
> > > cover maximally sized TCP/IP, including options), for this reason.
> >
> > Hmm. That'll cover the most common scenarios
> > (such as port filtering) but not deep inspection.
>
> Right.
>
> > Not sure how important that is.
> >
> > > > Also, for guest to guest communication, do you wait for
> > > > the destination to stop looking at the packet in order
> > > > to return it to the source? If yes, can source guest
> > > > networking be disrupted by a slow destination?
> > >
> > > There is a timeout which ultimately does a copy into dom0 memory and
> > > frees up the domain grant for return to the sending guest.
> >
> > Interesting. How long's the timeout?
>
> 1 second IIRC.
I think that's unlikely to prevent networking disruption, only
complete loss of networking.
> > > I suppose one difference with this is that it deals with data from
> > > "dom0" userspace buffers rather than (what looks like) kernel memory,
> > > although I don't know if that matters yet. Also it hangs off of struct
> > > sock which netback doesn't have. Anyway I'll check it out.
> >
> > I think the most important detail is the copy on clone approach.
> > We can make it controlled by an skb flag if necessary.
> >
> > > > > but IIRC honouring it universally turned into a
> > > > > very twisty maze with a number of nasty corner cases etc.
> > > >
> > > > Any examples? Are they covered by the patchset above?
> > >
> > > It was quite a while ago so I don't remember many of the specifics.
> > > Jeremy might remember better but for example any broadcast traffic
> > > hitting a bridge (a very interesting case for Xen), seems like a likely
> > > case? pcap was another one which I do remember, but that's obviously
> > > less critical.
> >
> > Last I looked I thought these clone the skb, so if a copy happens on
> > clone things will work correctly?
>
> Things should be correct, but won't necessarily perform well.
>
> In particular if the clones (which become copies with this flag) are
> frequent enough then there is no advantage to doing mapping instead of
> just copying upfront, in fact it probably hurts overall.
True. Further, the CPU used up by the copy isn't accounted for in the
appropriate cgroup.
> Taking a quick look at the callers of skb_clone I also see skb_segment
> in there. Since Xen tries to pass around large skbs (using LRO/GSO over
> the PV interface) in order to amortise costs it is quite common for
> things to undergo GSO as they hit the physical device. I'm not sure if
> these commonly hit the specific code path which causes a clone though.
Probably not, I think this patchset was tested with GSO as well.
> > > I presume with the TX zero-copy support the "copying due to attempted
> > > clone" rate is low?
> >
> > Yes. My understanding is that this version targets a non-bridged setup
> > (guest connected to a macvlan on a physical dev) as the first step.
>
> OK.
>
> > > > > FWIW I proposed a session on the subject for LPC this year.
> > > > We also plan to discuss this on kvm forum 2011
> > > > (colocated with linuxcon 2011).
> > > > http://www.linux-kvm.org/page/KVM_Forum_2011
> > >
> > > I had already considered coming to LinuxCon for other reasons but
> > > unfortunately I have family commitments around then :-(
>
> > And I'm not coming to LPC this year :(
>
> That's a shame.
>
> Ian.
>
^ permalink raw reply
* [PATCH v2] NET: AX88796: Tighten up Kconfig dependencies
From: Ralf Baechle @ 2011-06-27 11:13 UTC (permalink / raw)
To: David S. Miller, Eric Miao, Russell King, Ben Dooks, Pa
Cc: linux-arm-kernel, linux-kernel, linux-sh, netdev, linux-mips
In def47c5095d53814512bb0c62ec02dfdec769db1 [[netdrvr] Fix dependencies for
ax88796 ne2k clone driver] the AX88796 driver got restricted to just be
build for ARM and MIPS on the sole merrit that it was written for some ARM
sytems and the driver had the misfortune to just build on MIPS, so MIPS was
throw into the dependency for a good measure. Later
8687991a734a67f1638782c968f46fff0f94bb1f [ax88796: add superh to kconfig
dependencies] added SH but only one in-tree SH system actually has an
AX88796.
Tighten up dependencies by using an auxilliary config sysmbol
HAS_NET_AX88796 which is selected only by the platforms that actually
have or may have an AX88796. This also means the driver won't be built
anymore for any MIPS platform.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
---
v2: fixed Sergei's complaints about the log message
arch/arm/mach-pxa/Kconfig | 2 ++
arch/arm/mach-s3c2410/Kconfig | 1 +
arch/arm/mach-s3c2440/Kconfig | 1 +
arch/sh/boards/Kconfig | 1 +
drivers/net/Kconfig | 5 ++++-
5 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
index cd19309..37ce06f 100644
--- a/arch/arm/mach-pxa/Kconfig
+++ b/arch/arm/mach-pxa/Kconfig
@@ -247,11 +247,13 @@ config MACH_COLIBRI300
select PXA3xx
select CPU_PXA300
select CPU_PXA310
+ select HAS_NET_AX88796
config MACH_COLIBRI320
bool "Toradex Colibri PXA320"
select PXA3xx
select CPU_PXA320
+ select HAS_NET_AX88796
config MACH_COLIBRI_EVALBOARD
bool "Toradex Colibri Evaluation Carrier Board support"
diff --git a/arch/arm/mach-s3c2410/Kconfig b/arch/arm/mach-s3c2410/Kconfig
index 7245a55..d665f92 100644
--- a/arch/arm/mach-s3c2410/Kconfig
+++ b/arch/arm/mach-s3c2410/Kconfig
@@ -122,6 +122,7 @@ config ARCH_BAST
select S3C_DEV_HWMON
select S3C_DEV_USB_HOST
select S3C_DEV_NAND
+ select HAS_NET_AX88796
help
Say Y here if you are using the Simtec Electronics EB2410ITX
development board (also known as BAST)
diff --git a/arch/arm/mach-s3c2440/Kconfig b/arch/arm/mach-s3c2440/Kconfig
index 50825a3..7ddbd22 100644
--- a/arch/arm/mach-s3c2440/Kconfig
+++ b/arch/arm/mach-s3c2440/Kconfig
@@ -86,6 +86,7 @@ config MACH_ANUBIS
select S3C24XX_GPIO_EXTRA64
select S3C2440_XTAL_12000000
select S3C_DEV_USB_HOST
+ select HAS_NET_AX88796
help
Say Y here if you are using the Simtec Electronics ANUBIS
development system
diff --git a/arch/sh/boards/Kconfig b/arch/sh/boards/Kconfig
index d893411..f23f332 100644
--- a/arch/sh/boards/Kconfig
+++ b/arch/sh/boards/Kconfig
@@ -162,6 +162,7 @@ config SH_HIGHLANDER
depends on CPU_SUBTYPE_SH7780 || CPU_SUBTYPE_SH7785
select SYS_SUPPORTS_PCI
select IO_TRAPPED if MMU
+ select HAS_NET_AX88796
config SH_SH7757LCR
bool "SH7757LCR"
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index be25e92..85d18c4 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -237,13 +237,16 @@ source "drivers/net/arm/Kconfig"
config AX88796
tristate "ASIX AX88796 NE2000 clone support"
- depends on ARM || MIPS || SUPERH
+ depends on HAS_NET_AX88796
select PHYLIB
select MDIO_BITBANG
help
AX88796 driver, using platform bus to provide
chip detection and resources
+config HAS_NET_AX88796
+ bool
+
config AX88796_93CX6
bool "ASIX AX88796 external 93CX6 eeprom support"
depends on AX88796
^ permalink raw reply related
* Re: SKB paged fragment lifecycle on receive
From: Ian Campbell @ 2011-06-27 10:54 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Jeremy Fitzhardinge, xen-devel, netdev@vger.kernel.org,
mashirle@us.ibm.com, Russell, Rusty
In-Reply-To: <20110627102129.GB12978@redhat.com>
On Mon, 2011-06-27 at 11:21 +0100, Michael S. Tsirkin wrote:
> On Mon, Jun 27, 2011 at 10:41:35AM +0100, Ian Campbell wrote:
> > On Sun, 2011-06-26 at 11:25 +0100, Michael S. Tsirkin wrote:
> > > On Fri, Jun 24, 2011 at 04:43:22PM +0100, Ian Campbell wrote:
> > > > In this mode guest data pages ("foreign pages") were mapped into the
> > > > backend domain (using Xen grant-table functionality) and placed into the
> > > > skb's paged frag list (skb_shinfo(skb)->frags, I hope I am using the
> > > > right term). Once the page is finished with netback unmaps it in order
> > > > to return it to the guest (we really want to avoid returning such pages
> > > > to the general allocation pool!).
> > >
> > > Are the pages writeable by the source guest while netback processes
> > > them? If yes, firewalling becomes unreliable as the packet can be
> > > modified after it's checked, right?
> >
> > We only map the paged frags, the linear area is always copied (enough to
> > cover maximally sized TCP/IP, including options), for this reason.
>
> Hmm. That'll cover the most common scenarios
> (such as port filtering) but not deep inspection.
Right.
> Not sure how important that is.
>
> > > Also, for guest to guest communication, do you wait for
> > > the destination to stop looking at the packet in order
> > > to return it to the source? If yes, can source guest
> > > networking be disrupted by a slow destination?
> >
> > There is a timeout which ultimately does a copy into dom0 memory and
> > frees up the domain grant for return to the sending guest.
>
> Interesting. How long's the timeout?
1 second IIRC.
> > I suppose one difference with this is that it deals with data from
> > "dom0" userspace buffers rather than (what looks like) kernel memory,
> > although I don't know if that matters yet. Also it hangs off of struct
> > sock which netback doesn't have. Anyway I'll check it out.
>
> I think the most important detail is the copy on clone approach.
> We can make it controlled by an skb flag if necessary.
>
> > > > but IIRC honouring it universally turned into a
> > > > very twisty maze with a number of nasty corner cases etc.
> > >
> > > Any examples? Are they covered by the patchset above?
> >
> > It was quite a while ago so I don't remember many of the specifics.
> > Jeremy might remember better but for example any broadcast traffic
> > hitting a bridge (a very interesting case for Xen), seems like a likely
> > case? pcap was another one which I do remember, but that's obviously
> > less critical.
>
> Last I looked I thought these clone the skb, so if a copy happens on
> clone things will work correctly?
Things should be correct, but won't necessarily perform well.
In particular if the clones (which become copies with this flag) are
frequent enough then there is no advantage to doing mapping instead of
just copying upfront, in fact it probably hurts overall.
Taking a quick look at the callers of skb_clone I also see skb_segment
in there. Since Xen tries to pass around large skbs (using LRO/GSO over
the PV interface) in order to amortise costs it is quite common for
things to undergo GSO as they hit the physical device. I'm not sure if
these commonly hit the specific code path which causes a clone though.
> > I presume with the TX zero-copy support the "copying due to attempted
> > clone" rate is low?
>
> Yes. My understanding is that this version targets a non-bridged setup
> (guest connected to a macvlan on a physical dev) as the first step.
OK.
> > > > FWIW I proposed a session on the subject for LPC this year.
> > > We also plan to discuss this on kvm forum 2011
> > > (colocated with linuxcon 2011).
> > > http://www.linux-kvm.org/page/KVM_Forum_2011
> >
> > I had already considered coming to LinuxCon for other reasons but
> > unfortunately I have family commitments around then :-(
> And I'm not coming to LPC this year :(
That's a shame.
Ian.
^ permalink raw reply
* Re: SKB paged fragment lifecycle on receive
From: Michael S. Tsirkin @ 2011-06-27 10:21 UTC (permalink / raw)
To: Ian Campbell
Cc: netdev@vger.kernel.org, Jeremy Fitzhardinge, xen-devel,
mashirle@us.ibm.com, Rusty Russell
In-Reply-To: <1309167695.32717.181.camel@zakaz.uk.xensource.com>
On Mon, Jun 27, 2011 at 10:41:35AM +0100, Ian Campbell wrote:
> On Sun, 2011-06-26 at 11:25 +0100, Michael S. Tsirkin wrote:
> > On Fri, Jun 24, 2011 at 04:43:22PM +0100, Ian Campbell wrote:
> > > In this mode guest data pages ("foreign pages") were mapped into the
> > > backend domain (using Xen grant-table functionality) and placed into the
> > > skb's paged frag list (skb_shinfo(skb)->frags, I hope I am using the
> > > right term). Once the page is finished with netback unmaps it in order
> > > to return it to the guest (we really want to avoid returning such pages
> > > to the general allocation pool!).
> >
> > Are the pages writeable by the source guest while netback processes
> > them? If yes, firewalling becomes unreliable as the packet can be
> > modified after it's checked, right?
>
> We only map the paged frags, the linear area is always copied (enough to
> cover maximally sized TCP/IP, including options), for this reason.
Hmm. That'll cover the most common scenarios
(such as port filtering) but not deep inspection.
Not sure how important that is.
> > Also, for guest to guest communication, do you wait for
> > the destination to stop looking at the packet in order
> > to return it to the source? If yes, can source guest
> > networking be disrupted by a slow destination?
>
> There is a timeout which ultimately does a copy into dom0 memory and
> frees up the domain grant for return to the sending guest.
Interesting. How long's the timeout?
> > > Jeremy Fitzhardinge and I subsequently
> > > looked at the possibility of a no-clone skb flag (i.e. always forcing a
> > > copy instead of a clone)
> >
> > I think this is the approach that the patchset
> > 'macvtap/vhost TX zero-copy support' takes.
>
> That's TX from the guests PoV, the same as I am looking at here,
> correct?
Right.
> I should definitely check this work out, thanks for the pointer. Is V7
> (http://marc.info/?l=linux-kernel&m=130661128431312&w=2) the most recent
> posting?
I think so.
> I suppose one difference with this is that it deals with data from
> "dom0" userspace buffers rather than (what looks like) kernel memory,
> although I don't know if that matters yet. Also it hangs off of struct
> sock which netback doesn't have. Anyway I'll check it out.
I think the most important detail is the copy on clone approach.
We can make it controlled by an skb flag if necessary.
> > > but IIRC honouring it universally turned into a
> > > very twisty maze with a number of nasty corner cases etc.
> >
> > Any examples? Are they covered by the patchset above?
>
> It was quite a while ago so I don't remember many of the specifics.
> Jeremy might remember better but for example any broadcast traffic
> hitting a bridge (a very interesting case for Xen), seems like a likely
> case? pcap was another one which I do remember, but that's obviously
> less critical.
Last I looked I thought these clone the skb, so if a copy happens on
clone things will work correctly?
> I presume with the TX zero-copy support the "copying due to attempted
> clone" rate is low?
Yes. My understanding is that this version targets a non-bridged setup
(guest connected to a macvlan on a physical dev) as the first step.
> > > FWIW I proposed a session on the subject for LPC this year.
> > We also plan to discuss this on kvm forum 2011
> > (colocated with linuxcon 2011).
> > http://www.linux-kvm.org/page/KVM_Forum_2011
>
> I had already considered coming to LinuxCon for other reasons but
> unfortunately I have family commitments around then :-(
>
> Ian.
And I'm not coming to LPC this year :(
--
MST
^ permalink raw reply
* Re: [RFC 70/72] netx: Move the netx driver
From: Sascha Hauer @ 2011-06-27 9:45 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev
In-Reply-To: <1309010363-22750-71-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, Jun 25, 2011 at 06:59:21AM -0700, Jeff Kirsher wrote:
> Move the netx driver into drivers/net/ethernet/ and make the
> necessary Kconfig and Makefile changes.
>
> CC: Sascha Hauer <s.hauer@pengutronix.de>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
> drivers/net/Kconfig | 10 ----------
> drivers/net/Makefile | 1 -
> drivers/net/ethernet/Kconfig | 10 ++++++++++
> drivers/net/ethernet/Makefile | 1 +
> drivers/net/{ => ethernet}/netx-eth.c | 0
> 5 files changed, 11 insertions(+), 11 deletions(-)
> rename drivers/net/{ => ethernet}/netx-eth.c (100%)
>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 4ddc389..dfae2ec 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -236,16 +236,6 @@ config SH_ETH
> This driver supporting CPUs are:
> - SH7710, SH7712, SH7763, SH7619, SH7724, and SH7757.
>
> -config NET_NETX
> - tristate "NetX Ethernet support"
> - select MII
> - depends on ARCH_NETX
> - help
> - This is support for the Hilscher netX builtin Ethernet ports
> -
> - To compile this driver as a module, choose M here. The module
> - will be called netx-eth.
> -
> config NET_PCI
> bool "EISA, VLB, PCI and on board controllers"
> depends on ISA || EISA || PCI
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index 83075d4..c24b5ef 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -52,7 +52,6 @@ obj-$(CONFIG_DEFXX) += defxx.o
> obj-$(CONFIG_EQUALIZER) += eql.o
> obj-$(CONFIG_TUN) += tun.o
> obj-$(CONFIG_VETH) += veth.o
> -obj-$(CONFIG_NET_NETX) += netx-eth.o
>
> obj-$(CONFIG_DEV_APPLETALK) += appletalk/
> obj-$(CONFIG_ETHERNET) += ethernet/
> diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
> index 3ec1903..b7d8d9b 100644
> --- a/drivers/net/ethernet/Kconfig
> +++ b/drivers/net/ethernet/Kconfig
> @@ -176,6 +176,16 @@ config FEALNX
> source "drivers/net/ethernet/natsemi/Kconfig"
> source "drivers/net/ethernet/8390/Kconfig"
>
> +config NET_NETX
> + tristate "NetX Ethernet support"
> + depends on ARCH_NETX
> + select MII
> + ---help---
> + This is support for the Hilscher netX builtin Ethernet ports
> +
> + To compile this driver as a module, choose M here. The module
> + will be called netx-eth.
> +
> config FORCEDETH
> tristate "nForce Ethernet support"
> depends on PCI
> diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
> index 3b2a35a..c1a1c61 100644
> --- a/drivers/net/ethernet/Makefile
> +++ b/drivers/net/ethernet/Makefile
> @@ -42,6 +42,7 @@ obj-$(CONFIG_NET_VENDOR_MOTOROLA) += motorola/
> obj-$(CONFIG_NET_VENDOR_MYRI) += myricom/
> obj-$(CONFIG_FEALNX) += fealnx.o
> obj-$(CONFIG_NET_VENDOR_NATSEMI) += natsemi/
> +obj-$(CONFIG_NET_NETX) += netx-eth.o
> obj-$(CONFIG_FORCEDETH) += forcedeth.o
> obj-$(CONFIG_OCTEON_MGMT_ETHERNET) += octeon/
> obj-$(CONFIG_ETHOC) += ethoc.o
> diff --git a/drivers/net/netx-eth.c b/drivers/net/ethernet/netx-eth.c
> similarity index 100%
> rename from drivers/net/netx-eth.c
> rename to drivers/net/ethernet/netx-eth.c
> --
> 1.7.5.4
>
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [RFC 69/72] dm9000: Move the Davicom driver
From: Sascha Hauer @ 2011-06-27 9:45 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev, Ben Dooks
In-Reply-To: <1309010363-22750-70-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, Jun 25, 2011 at 06:59:20AM -0700, Jeff Kirsher wrote:
> Move the Davicom driver into drivers/net/ethernet/davicom/ and
> make the necessary Kconfig and Makefile changes.
>
> CC: Ben Dooks <ben@simtec.co.uk>
> CC: Sascha Hauer <s.hauer@pengutronix.de>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
> drivers/net/Kconfig | 28 ------------------------
> drivers/net/Makefile | 1 -
> drivers/net/ethernet/Kconfig | 1 +
> drivers/net/ethernet/Makefile | 1 +
> drivers/net/ethernet/davicom/Kconfig | 31 +++++++++++++++++++++++++++
> drivers/net/ethernet/davicom/Makefile | 5 ++++
> drivers/net/{ => ethernet/davicom}/dm9000.c | 0
> drivers/net/{ => ethernet/davicom}/dm9000.h | 0
> 8 files changed, 38 insertions(+), 29 deletions(-)
> create mode 100644 drivers/net/ethernet/davicom/Kconfig
> create mode 100644 drivers/net/ethernet/davicom/Makefile
> rename drivers/net/{ => ethernet/davicom}/dm9000.c (100%)
> rename drivers/net/{ => ethernet/davicom}/dm9000.h (100%)
>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index d1bcd23..4ddc389 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -246,34 +246,6 @@ config NET_NETX
> To compile this driver as a module, choose M here. The module
> will be called netx-eth.
>
> -config DM9000
> - tristate "DM9000 support"
> - depends on ARM || BLACKFIN || MIPS
> - select CRC32
> - select MII
> - ---help---
> - Support for DM9000 chipset.
> -
> - To compile this driver as a module, choose M here. The module
> - will be called dm9000.
> -
> -config DM9000_DEBUGLEVEL
> - int "DM9000 maximum debug level"
> - depends on DM9000
> - default 4
> - help
> - The maximum level of debugging code compiled into the DM9000
> - driver.
> -
> -config DM9000_FORCE_SIMPLE_PHY_POLL
> - bool "Force simple NSR based PHY polling"
> - depends on DM9000
> - ---help---
> - This configuration forces the DM9000 to use the NSR's LinkStatus
> - bit to determine if the link is up or down instead of the more
> - costly MII PHY reads. Note, this will not work if the chip is
> - operating with an external PHY.
> -
> config NET_PCI
> bool "EISA, VLB, PCI and on board controllers"
> depends on ISA || EISA || PCI
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index b647529..83075d4 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -53,7 +53,6 @@ obj-$(CONFIG_EQUALIZER) += eql.o
> obj-$(CONFIG_TUN) += tun.o
> obj-$(CONFIG_VETH) += veth.o
> obj-$(CONFIG_NET_NETX) += netx-eth.o
> -obj-$(CONFIG_DM9000) += dm9000.o
>
> obj-$(CONFIG_DEV_APPLETALK) += appletalk/
> obj-$(CONFIG_ETHERNET) += ethernet/
> diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
> index ac88e7c..3ec1903 100644
> --- a/drivers/net/ethernet/Kconfig
> +++ b/drivers/net/ethernet/Kconfig
> @@ -73,6 +73,7 @@ source "drivers/net/ethernet/broadcom/Kconfig"
> source "drivers/net/ethernet/brocade/Kconfig"
> source "drivers/net/ethernet/chelsio/Kconfig"
> source "drivers/net/ethernet/cisco/Kconfig"
> +source "drivers/net/ethernet/davicom/Kconfig"
>
> config DNET
> tristate "Dave ethernet support (DNET)"
> diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
> index afbb0ff..3b2a35a 100644
> --- a/drivers/net/ethernet/Makefile
> +++ b/drivers/net/ethernet/Makefile
> @@ -19,6 +19,7 @@ obj-$(CONFIG_NET_VENDOR_BROADCOM) += broadcom/
> obj-$(CONFIG_NET_VENDOR_BROCADE) += brocade/
> obj-$(CONFIG_NET_VENDOR_CHELSIO) += chelsio/
> obj-$(CONFIG_NET_VENDOR_CISCO) += cisco/
> +obj-$(CONFIG_DM9000) += davicom/
> obj-$(CONFIG_DNET) += dnet.o
> obj-$(CONFIG_DEPCA) += depca.o
> obj-$(CONFIG_NET_VENDOR_DLINK) += dlink/
> diff --git a/drivers/net/ethernet/davicom/Kconfig b/drivers/net/ethernet/davicom/Kconfig
> new file mode 100644
> index 0000000..0a03b0b
> --- /dev/null
> +++ b/drivers/net/ethernet/davicom/Kconfig
> @@ -0,0 +1,31 @@
> +#
> +# Davicom device configuration
> +#
> +
> +config DM9000
> + tristate "DM9000 support"
> + depends on ARM || BLACKFIN || MIPS
> + select CRC32
> + select MII
> + ---help---
> + Support for DM9000 chipset.
> +
> + To compile this driver as a module, choose M here. The module
> + will be called dm9000.
> +
> +config DM9000_DEBUGLEVEL
> + int "DM9000 maximum debug level"
> + depends on DM9000
> + default 4
> + help
> + The maximum level of debugging code compiled into the DM9000
> + driver.
> +
> +config DM9000_FORCE_SIMPLE_PHY_POLL
> + bool "Force simple NSR based PHY polling"
> + depends on DM9000
> + ---help---
> + This configuration forces the DM9000 to use the NSR's LinkStatus
> + bit to determine if the link is up or down instead of the more
> + costly MII PHY reads. Note, this will not work if the chip is
> + operating with an external PHY.
> diff --git a/drivers/net/ethernet/davicom/Makefile b/drivers/net/ethernet/davicom/Makefile
> new file mode 100644
> index 0000000..74b31f0
> --- /dev/null
> +++ b/drivers/net/ethernet/davicom/Makefile
> @@ -0,0 +1,5 @@
> +#
> +# Makefile for the Davicom device drivers.
> +#
> +
> +obj-$(CONFIG_DM9000) += dm9000.o
> diff --git a/drivers/net/dm9000.c b/drivers/net/ethernet/davicom/dm9000.c
> similarity index 100%
> rename from drivers/net/dm9000.c
> rename to drivers/net/ethernet/davicom/dm9000.c
> diff --git a/drivers/net/dm9000.h b/drivers/net/ethernet/davicom/dm9000.h
> similarity index 100%
> rename from drivers/net/dm9000.h
> rename to drivers/net/ethernet/davicom/dm9000.h
> --
> 1.7.5.4
>
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: SKB paged fragment lifecycle on receive
From: Ian Campbell @ 2011-06-27 9:41 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Jeremy Fitzhardinge, xen-devel, netdev@vger.kernel.org,
mashirle@us.ibm.com, Russell, Rusty
In-Reply-To: <20110626102543.GA4961@redhat.com>
On Sun, 2011-06-26 at 11:25 +0100, Michael S. Tsirkin wrote:
> On Fri, Jun 24, 2011 at 04:43:22PM +0100, Ian Campbell wrote:
> > In this mode guest data pages ("foreign pages") were mapped into the
> > backend domain (using Xen grant-table functionality) and placed into the
> > skb's paged frag list (skb_shinfo(skb)->frags, I hope I am using the
> > right term). Once the page is finished with netback unmaps it in order
> > to return it to the guest (we really want to avoid returning such pages
> > to the general allocation pool!).
>
> Are the pages writeable by the source guest while netback processes
> them? If yes, firewalling becomes unreliable as the packet can be
> modified after it's checked, right?
We only map the paged frags, the linear area is always copied (enough to
cover maximally sized TCP/IP, including options), for this reason.
> Also, for guest to guest communication, do you wait for
> the destination to stop looking at the packet in order
> to return it to the source? If yes, can source guest
> networking be disrupted by a slow destination?
There is a timeout which ultimately does a copy into dom0 memory and
frees up the domain grant for return to the sending guest.
> > Jeremy Fitzhardinge and I subsequently
> > looked at the possibility of a no-clone skb flag (i.e. always forcing a
> > copy instead of a clone)
>
> I think this is the approach that the patchset
> 'macvtap/vhost TX zero-copy support' takes.
That's TX from the guests PoV, the same as I am looking at here,
correct?
I should definitely check this work out, thanks for the pointer. Is V7
(http://marc.info/?l=linux-kernel&m=130661128431312&w=2) the most recent
posting?
I suppose one difference with this is that it deals with data from
"dom0" userspace buffers rather than (what looks like) kernel memory,
although I don't know if that matters yet. Also it hangs off of struct
sock which netback doesn't have. Anyway I'll check it out.
> > but IIRC honouring it universally turned into a
> > very twisty maze with a number of nasty corner cases etc.
>
> Any examples? Are they covered by the patchset above?
It was quite a while ago so I don't remember many of the specifics.
Jeremy might remember better but for example any broadcast traffic
hitting a bridge (a very interesting case for Xen), seems like a likely
case? pcap was another one which I do remember, but that's obviously
less critical.
I presume with the TX zero-copy support the "copying due to attempted
clone" rate is low?
> > FWIW I proposed a session on the subject for LPC this year.
> We also plan to discuss this on kvm forum 2011
> (colocated with linuxcon 2011).
> http://www.linux-kvm.org/page/KVM_Forum_2011
I had already considered coming to LinuxCon for other reasons but
unfortunately I have family commitments around then :-(
Ian.
^ permalink raw reply
* Re: [RFC 56/72] macb: Move the Atmel driver
From: Jamie Iles @ 2011-06-27 9:29 UTC (permalink / raw)
To: Nicolas Ferre; +Cc: Jeff Kirsher, davem, netdev, Jamie Iles
In-Reply-To: <4E083572.6050302@atmel.com>
On Mon, Jun 27, 2011 at 09:46:58AM +0200, Nicolas Ferre wrote:
> Hi,
>
> Le 25/06/2011 15:59, Jeff Kirsher :
> > Move the Atmel driver into drivers/net/ethernet/atmel/ and
>
> I am not sure that "atmel" is the proper name for a directory containing
> the macb.c driver. This controller has not been made by atmel and will
> be shared with others soon (Cf. paches by Jamie Iles).
>
> So two questions remains:
> - will we need to have a directory for this driver?
> - what will be the name of this directory?
The MACB is actually a Cadence IP block and I have a set of patches that
add support for the Cadence GEM so personally I'd be happy with
drivers/net/ethernet/cadence.
Jamie
^ permalink raw reply
* Re: [PATCH] NET: AX88796: Tighten up Kconfig dependencies
From: Sergei Shtylyov @ 2011-06-27 9:17 UTC (permalink / raw)
To: Ralf Baechle
Cc: linux-mips, Russell King, Jeff Garzik, linux-sh, netdev,
Magnus Damm, linux-kernel, Paul Mundt, Ben Dooks, Eric Miao,
David S. Miller, linux-arm-kernel
In-Reply-To: <20110625180050.GA9620@linux-mips.org>
Hello.
On 25-06-2011 22:00, Ralf Baechle wrote:
> In def47c5095d53814512bb0c62ec02dfdec769db1 the AX88796 driver got
Please also specify the summary of that commit.
> restricted to just be build for ARM and MIPS on the sole merrit that it
Merit?
> was written for some ARM sytems and the driver had the missfortune to
Misfortune?
> just build on MIPS, so MIPS was throw into the dependency for a good
> measure. Later 8687991a734a67f1638782c968f46fff0f94bb1f added SH but
Summary here too, please.
> only one in-tree SH system actually has an AX88796.
> Tighten up dependencies by using an auxilliary config sysmbol
> HAS_NET_AX88796 which is selected only by the platforms that actually
> have or may have an AX88796. This also means the driver won't be built
> anymore for any MIPS platform.
> Signed-off-by: Ralf Baechle<ralf@linux-mips.org>
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] sctp: Reducing rwnd by sizeof(struct sk_buff) for each CHUNK is too aggressive
From: Thomas Graf @ 2011-06-27 9:11 UTC (permalink / raw)
To: Vladislav Yasevich; +Cc: Sridhar Samudrala, linux-sctp, netdev
In-Reply-To: <4E04AB67.1040407@hp.com>
On Fri, Jun 24, 2011 at 11:21:11AM -0400, Vladislav Yasevich wrote:
> We, instead of trying to underestimate the window size, try to over-estimate it.
> Almost every implementation has some kind of overhead and we don't know how
> that overhead will impact the window. As such we try to temporarily account for this
> overhead.
I looked into this some more and it turns out that adding per-packet
overhead is difficult because when we mark chunks for retransmissions
we have to add its data size to the peer rwnd again but we have no
idea how many packets were used for the initial transmission. Therefore
if we add an overhead, we can only do so per chunk.
> If we treat the window as strictly available data, then we may end up sending a lot more traffic
> then the window can take thus causing us to enter 0 window probe and potential retransmission
> issues that will trigger congestion control.
> We'd like to avoid that so we put some overhead into our computations. It may not be ideal
> since we do this on a per-chunk basis. It could probably be done on per-packet basis instead.
> This way, we'll essentially over-estimate but under-subscribe our current view of the peers
> window. So in one shot, we are not going to over-fill it and will get an updated view next
> time the SACK arrives.
What kind of configuration showed this behaviour? Did you observe that
issue with Linux peers? If a peer announces an a_rwnd which it cannot
handle then that is a implementation bug of the receiver and not of the
sender.
We won't go into zero window probe mode that easily, remember it's only
one packet allowed in flight while rwnd is 0. We always take into
account outstanding bytes when updating rwnd with a_rwnd so our view of
the peer's rwnd is very accurate.
In fact the RFC clearly states when and how to update the peer rwnd:
B) Any time a DATA chunk is transmitted (or retransmitted) to a peer,
the endpoint subtracts the data size of the chunk from the rwnd of
that peer.
I would like to try and reproduce the behaviour you have observed and
fix it without cutting our ability to produce pmtu maxed packets with
small data chunks.
^ permalink raw reply
* winner
From: Microsoft @ 2011-06-26 15:53 UTC (permalink / raw)
You have won 500.000 GBP
send your phone number
and address
^ permalink raw reply
* Re: [PATCH] net/can: activate bit-timing calculation and netlink based drivers by default
From: Marc Kleine-Budde @ 2011-06-27 8:04 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
socketcan-users-0fE9KPoRgkgATYTw5x5z8w,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <4E083930.50102-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 572 bytes --]
On 06/27/2011 10:02 AM, Wolfgang Grandegger wrote:
> Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
>
> Ahh, ohh, a trivial fix for a long-standing problem. Would be nice if
> Kbuild would report such invalid default settings.
ACK, Marc
Send patches :)
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 191 bytes --]
_______________________________________________
Socketcan-users mailing list
Socketcan-users-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-users
^ permalink raw reply
* Re: [PATCH] net/can: activate bit-timing calculation and netlink based drivers by default
From: Wolfgang Grandegger @ 2011-06-27 8:02 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
socketcan-users-0fE9KPoRgkgATYTw5x5z8w,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <1309160391-22486-1-git-send-email-mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Hi Marc,
On 06/27/2011 09:39 AM, Marc Kleine-Budde wrote:
> The two options "CAN bit-timing calculation" and
> "Platform CAN drivers with Netlink support" have a "default Y". In order to
> activate them by default, change to "default y".
>
> Signed-off-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> ---
> drivers/net/can/Kconfig | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
> index bbf06f7..f1f9fd9 100644
> --- a/drivers/net/can/Kconfig
> +++ b/drivers/net/can/Kconfig
> @@ -36,7 +36,7 @@ config CAN_SLCAN
> config CAN_DEV
> tristate "Platform CAN drivers with Netlink support"
> depends on CAN
> - default Y
> + default y
> ---help---
> Enables the common framework for platform CAN drivers with Netlink
> support. This is the standard library for CAN drivers.
> @@ -45,7 +45,7 @@ config CAN_DEV
> config CAN_CALC_BITTIMING
> bool "CAN bit-timing calculation"
> depends on CAN_DEV
> - default Y
> + default y
> ---help---
> If enabled, CAN bit-timing parameters will be calculated for the
> bit-rate specified via Netlink argument "bitrate" when the device
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Ahh, ohh, a trivial fix for a long-standing problem. Would be nice if
Kbuild would report such invalid default settings.
Thanks,
Wolfgang.
^ permalink raw reply
* Re: [RFC 56/72] macb: Move the Atmel driver
From: Nicolas Ferre @ 2011-06-27 7:46 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev, Jamie Iles
In-Reply-To: <1309010363-22750-57-git-send-email-jeffrey.t.kirsher@intel.com>
Hi,
Le 25/06/2011 15:59, Jeff Kirsher :
> Move the Atmel driver into drivers/net/ethernet/atmel/ and
I am not sure that "atmel" is the proper name for a directory containing
the macb.c driver. This controller has not been made by atmel and will
be shared with others soon (Cf. paches by Jamie Iles).
So two questions remains:
- will we need to have a directory for this driver?
- what will be the name of this directory?
Best regards,
> make the necessary Kconfig and Makefile changes.
>
> CC: Nicolas Ferre <nicolas.ferre@atmel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> MAINTAINERS | 2 +-
> drivers/net/Kconfig | 14 -------------
> drivers/net/Makefile | 1 -
> drivers/net/ethernet/Kconfig | 1 +
> drivers/net/ethernet/Makefile | 1 +
> drivers/net/ethernet/atmel/Kconfig | 32 +++++++++++++++++++++++++++++++
> drivers/net/ethernet/atmel/Makefile | 5 ++++
> drivers/net/{ => ethernet/atmel}/macb.c | 0
> drivers/net/{ => ethernet/atmel}/macb.h | 0
> 9 files changed, 40 insertions(+), 16 deletions(-)
> create mode 100644 drivers/net/ethernet/atmel/Kconfig
> create mode 100644 drivers/net/ethernet/atmel/Makefile
> rename drivers/net/{ => ethernet/atmel}/macb.c (100%)
> rename drivers/net/{ => ethernet/atmel}/macb.h (100%)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 506d4d0..9ddb715 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1303,7 +1303,7 @@ F: include/video/atmel_lcdc.h
> ATMEL MACB ETHERNET DRIVER
> M: Nicolas Ferre <nicolas.ferre@atmel.com>
> S: Supported
> -F: drivers/net/macb.*
> +F: drivers/net/ethernet/atmel/
>
> ATMEL SPI DRIVER
> M: Nicolas Ferre <nicolas.ferre@atmel.com>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 9709106..7063b9c 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -2,9 +2,6 @@
> # Network device configuration
> #
>
> -config HAVE_NET_MACB
> - bool
> -
> menuconfig NETDEVICES
> default y if UML
> depends on NET
> @@ -224,17 +221,6 @@ menuconfig NET_ETHERNET
>
> if NET_ETHERNET
>
> -config MACB
> - tristate "Atmel MACB support"
> - depends on HAVE_NET_MACB
> - select PHYLIB
> - help
> - The Atmel MACB ethernet interface is found on many AT32 and AT91
> - parts. Say Y to include support for the MACB chip.
> -
> - To compile this driver as a module, choose M here: the module
> - will be called macb.
> -
> config SH_ETH
> tristate "Renesas SuperH Ethernet support"
> depends on SUPERH && \
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index 5c189ab..a2a1e0a 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -68,7 +68,6 @@ obj-$(CONFIG_ETHOC) += ethoc.o
> obj-$(CONFIG_GRETH) += greth.o
>
> obj-$(CONFIG_DNET) += dnet.o
> -obj-$(CONFIG_MACB) += macb.o
>
> obj-$(CONFIG_DEV_APPLETALK) += appletalk/
> obj-$(CONFIG_ETHERNET) += ethernet/
> diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
> index fede911..e7c5f0b 100644
> --- a/drivers/net/ethernet/Kconfig
> +++ b/drivers/net/ethernet/Kconfig
> @@ -39,6 +39,7 @@ config ARIADNE
>
> source "drivers/net/ethernet/arm/Kconfig"
> source "drivers/net/ethernet/atheros/Kconfig"
> +source "drivers/net/ethernet/atmel/Kconfig"
> source "drivers/net/ethernet/blackfin/Kconfig"
> source "drivers/net/ethernet/broadcom/Kconfig"
> source "drivers/net/ethernet/brocade/Kconfig"
> diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
> index b8cc6ef..6c69e98 100644
> --- a/drivers/net/ethernet/Makefile
> +++ b/drivers/net/ethernet/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_NET_VENDOR_APPLE) += apple/
> obj-$(CONFIG_ARIADNE) += ariadne.o
> obj-$(CONFIG_NET_ARM) += arm/
> obj-$(CONFIG_NET_VENDOR_ATHEROS) += atheros/
> +obj-$(CONFIG_NET_ATMEL) += atmel/
> obj-$(CONFIG_NET_BFIN) += blackfin/
> obj-$(CONFIG_NET_VENDOR_BROADCOM) += broadcom/
> obj-$(CONFIG_NET_VENDOR_BROCADE) += brocade/
> diff --git a/drivers/net/ethernet/atmel/Kconfig b/drivers/net/ethernet/atmel/Kconfig
> new file mode 100644
> index 0000000..a8c11ea
> --- /dev/null
> +++ b/drivers/net/ethernet/atmel/Kconfig
> @@ -0,0 +1,32 @@
> +#
> +# Atmel device configuration
> +#
> +
> +config HAVE_NET_MACB
> + bool
> +
> +config NET_ATMEL
> + bool "Atmel devices"
> + depends on HAVE_NET_MACB
> + ---help---
> + If you have a network (Ethernet) card belonging to this class, say Y.
> + Make sure you know the name of your card. Read the Ethernet-HOWTO,
> + available from <http://www.tldp.org/docs.html#howto>.
> +
> + If unsure, say Y.
> +
> + Note that the answer to this question doesn't directly affect the
> + kernel: saying N will just cause the configurator to skip all
> + the remaining Atmel network card questions. If you say Y, you will be
> + asked for your specific card in the following questions.
> +
> +config MACB
> + tristate "Atmel MACB support"
> + depends on NET_ATMEL && HAVE_NET_MACB
> + select PHYLIB
> + ---help---
> + The Atmel MACB ethernet interface is found on many AT32 and AT91
> + parts. Say Y to include support for the MACB chip.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called macb.
> diff --git a/drivers/net/ethernet/atmel/Makefile b/drivers/net/ethernet/atmel/Makefile
> new file mode 100644
> index 0000000..91f79b1
> --- /dev/null
> +++ b/drivers/net/ethernet/atmel/Makefile
> @@ -0,0 +1,5 @@
> +#
> +# Makefile for the Atmel network device drivers.
> +#
> +
> +obj-$(CONFIG_MACB) += macb.o
> diff --git a/drivers/net/macb.c b/drivers/net/ethernet/atmel/macb.c
> similarity index 100%
> rename from drivers/net/macb.c
> rename to drivers/net/ethernet/atmel/macb.c
> diff --git a/drivers/net/macb.h b/drivers/net/ethernet/atmel/macb.h
> similarity index 100%
> rename from drivers/net/macb.h
> rename to drivers/net/ethernet/atmel/macb.h
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH 1/2] can: bfin_can: simplify xmit id1 setup
From: Kurt Van Dijck @ 2011-06-27 7:43 UTC (permalink / raw)
To: Mike Frysinger
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, David S. Miller,
Wolfgang Grandegger,
uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b
In-Reply-To: <1308925982-14645-1-git-send-email-vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
On Fri, Jun 24, 2011 at 10:33:01AM -0400, Mike Frysinger wrote:
> If we look closely, the 4 writes to TRANSMIT_CHL.id1 can be collapsed
> down into much simpler code. So do just that.
>
> This also fixes a build failure due to the I/O macros no longer
> getting pulled in. Their minor (and accidental) usage here gets
> dropped as part of the unification.
>
> Signed-off-by: Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
Nice cleanup.
Acked-by: Kurt Van Dijck <kurt.van.dijck-/BeEPy95v10@public.gmane.org>
^ permalink raw reply
* [PATCH] net/can: activate bit-timing calculation and netlink based drivers by default
From: Marc Kleine-Budde @ 2011-06-27 7:39 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
socketcan-users-0fE9KPoRgkgATYTw5x5z8w, wg-5Yr1BZd7O62+XT7JhA+gdA
The two options "CAN bit-timing calculation" and
"Platform CAN drivers with Netlink support" have a "default Y". In order to
activate them by default, change to "default y".
Signed-off-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
---
drivers/net/can/Kconfig | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
index bbf06f7..f1f9fd9 100644
--- a/drivers/net/can/Kconfig
+++ b/drivers/net/can/Kconfig
@@ -36,7 +36,7 @@ config CAN_SLCAN
config CAN_DEV
tristate "Platform CAN drivers with Netlink support"
depends on CAN
- default Y
+ default y
---help---
Enables the common framework for platform CAN drivers with Netlink
support. This is the standard library for CAN drivers.
@@ -45,7 +45,7 @@ config CAN_DEV
config CAN_CALC_BITTIMING
bool "CAN bit-timing calculation"
depends on CAN_DEV
- default Y
+ default y
---help---
If enabled, CAN bit-timing parameters will be calculated for the
bit-rate specified via Netlink argument "bitrate" when the device
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH] net_sched: fix dequeuer fairness
From: David Miller @ 2011-06-27 7:15 UTC (permalink / raw)
To: jhs, hadi; +Cc: eric.dumazet, herbert, netdev, adi, joe
In-Reply-To: <1309112034.5134.66.camel@mojatatu>
From: jamal <hadi@cyberus.ca>
Date: Sun, 26 Jun 2011 14:13:54 -0400
> [PATCH] net_sched: fix dequeuer fairness
Applied, thanks!
^ permalink raw reply
* Re: [net-next 0/9][pull request] Intel Wired LAN Driver Update
From: David Miller @ 2011-06-27 7:08 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo
In-Reply-To: <1308986546-12964-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Sat, 25 Jun 2011 00:22:17 -0700
> The following series contains updates to ixgbe. The changes are mainly
> cleanup/update of the ixgbe driver.
>
> The following are changes since commit c6af9c406ceb3434281cf230938453931dcbab75:
> net: wimax: Remove of unused 'rfkill_input' pointer
> and are available in the git repository at:
> master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/net-next-2.6 master
I'll pull this, thanks Jeff.
^ permalink raw reply
* Re: [PATCH 0/8] wan: Use current logging forms
From: David Miller @ 2011-06-27 7:08 UTC (permalink / raw)
To: joe; +Cc: netdev, linux-kernel
In-Reply-To: <cover.1309150683.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Sun, 26 Jun 2011 22:01:27 -0700
> Joe Perches (8):
> generic_hdlc: Update to current logging forms
> cosa: Update to current logging forms
> cyclom: Update to current logging forms
> frame relay dlci/frad: Update to current logging forms
> dscc4: Update to current logging forms
> farsync: Update to current logging forms
> ixp4xx_hss: Update to current logging forms
> wan: Update to current logging forms
All applied, thanks Joe.
^ 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