* 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
* [PATCH 2/2] Modifies CCID4 in order to work with tfrc-sp
From: Ivo Calado @ 2009-10-13 17:31 UTC (permalink / raw)
To: dccp; +Cc: netdev, ivocalado
Modifies CCID4 in order to work with tfrc-sp.
Changes:
- Implements random ecn nonce to be added to sent packets at ccid4
- Adds parsing of options loss intervals and dropped packets
- Adds checking of parsed info from options
Signed-off-by: Ivo Calado <ivocalado@embedded.ufcg.edu.br>
Signed-off-by: Erivaldo Xavier <desadoc@gmail.com>
Signed-off-by: Leandro Sales <leandroal@gmail.com>
Index: dccp_tree_work04/net/dccp/ccids/ccid4.h
===================================================================
--- dccp_tree_work04.orig/net/dccp/ccids/ccid4.h 2009-10-12 20:01:07.523059905 -0300
+++ dccp_tree_work04/net/dccp/ccids/ccid4.h 2009-10-12 20:11:01.847156634 -0300
@@ -6,6 +6,13 @@
*
* An implementation of the DCCP protocol
*
+ * Copyright (c) 2009 Ivo Calado, Erivaldo Xavier, Leandro Sales
+ *
+ * This code has been developed by the Federal University of Campina Grande
+ * Embedded Systems and Pervasive Computing Lab. For further information
+ * please see http://embedded.ufcg.edu.br/
+ * <ivocalado@embedded.ufcg.edu.br> <desadoc@gmail.com> <leandroal@gmail.com>
+ *
* Copyright (c) 2007 Leandro Sales, Tommi Saviranta
*
* This code has been developed by the Federal University of Campina Grande
@@ -47,7 +54,7 @@
#ifndef _DCCP_CCID4_H_
#define _DCCP_CCID4_H_
-#include "lib/tfrc_ccids.h"
+#include "lib/tfrc_ccids_sp.h"
/* The nominal packet size to be used into TFRC equation as per CCID-4 draft*/
#define NOM_PACKET_SIZE 1460
Index: dccp_tree_work04/net/dccp/ccids/ccid4.c
===================================================================
--- dccp_tree_work04.orig/net/dccp/ccids/ccid4.c 2009-10-12 20:01:07.511531378 -0300
+++ dccp_tree_work04/net/dccp/ccids/ccid4.c 2009-10-12 20:13:07.272031863 -0300
@@ -6,6 +6,13 @@
*
* An implementation of the DCCP protocol
*
+ * Copyright (c) 2009 Ivo Calado, Erivaldo Xavier, Leandro Sales
+ *
+ * This code has been developed by the Federal University of Campina Grande
+ * Embedded Systems and Pervasive Computing Lab. For further information
+ * please see http://embedded.ufcg.edu.br/
+ * <ivocalado@embedded.ufcg.edu.br> <desadoc@gmail.com> <leandroal@gmail.com>
+ *
* Copyright (c) 2007 Leandro Sales, Tommi Saviranta
*
* This code has been developed by the Federal University of Campina Grande
@@ -295,9 +302,14 @@
if (delay >= TFRC_T_DELTA)
return (u32)delay / USEC_PER_MSEC;
- tfrc_hc_tx_update_win_count(hctx, now);
+ tfrc_sp_hc_tx_update_win_count(hctx, now);
}
+ if (dccp_data_packet(skb))
+ DCCP_SKB_CB(skb)->dccpd_ecn =
+ tfrc_sp_get_random_ect(&hctx->li_data,
+ DCCP_SKB_CB(skb)->dccpd_seq);
+
/* prepare to send now (add options etc.) */
dp->dccps_hc_tx_insert_options = 1;
DCCP_SKB_CB(skb)->dccpd_ccval = hctx->last_win_count;
@@ -314,14 +326,15 @@
/* Changes to s will become effective the next time X is computed */
hctx->s = ccid4_hc_tx_measure_packet_size(sk, len);
- if (tfrc_tx_hist_add(&hctx->hist, dccp_sk(sk)->dccps_gss))
- DCCP_CRIT("packet history - out of memory!");
+ if (tfrc_sp_tx_hist_add(&hctx->hist, dccp_sk(sk)->dccps_gss,
+ hctx->last_win_count))
+ DCCP_CRIT("packet history - out of memory!");
}
static void ccid4_hc_tx_packet_recv(struct sock *sk, struct sk_buff *skb)
{
struct tfrc_hc_tx_sock *hctx = tfrc_hc_tx_sk(sk);
- struct tfrc_tx_hist_entry *acked;
+ struct tfrc_tx_hist_entry *acked, *old;
ktime_t now;
unsigned long t_nfb;
u32 r_sample;
@@ -342,7 +355,10 @@
if (acked == NULL)
return;
/* For the sake of RTT sampling, ignore/remove all older entries */
- tfrc_tx_hist_purge(&acked->next);
+ old = tfrc_tx_hist_two_rtt_old(hctx->hist,
+ DCCP_SKB_CB(skb)->dccpd_ccval);
+ if (old != NULL)
+ tfrc_sp_tx_hist_purge(&old->next);
/* Update the moving average for the RTT estimate (RFC 3448, 4.3) */
now = ktime_get_real();
@@ -375,7 +391,7 @@
/* Update sending rate (step 4 of [RFC 3448, 4.3]) */
if (hctx->p > 0)
- hctx->x_calc = tfrc_calc_x(NOM_PACKET_SIZE, hctx->rtt, hctx->p);
+ hctx->x_calc = tfrc_sp_calc_x(NOM_PACKET_SIZE, hctx->rtt, hctx->p);
ccid4_hc_tx_update_x(sk, &now);
done_computing_x:
@@ -453,6 +469,8 @@
u8 option, u8 *optval, u8 optlen)
{
struct tfrc_hc_tx_sock *hctx = tfrc_hc_tx_sk(sk);
+ struct sk_buff *skb;
+ u32 new_p;
__be32 opt_val;
switch (option) {
@@ -477,14 +495,72 @@
dccp_role(sk), sk, opt_val);
} else {
/* Update the fixpoint Loss Event Rate fraction */
- hctx->p = tfrc_invert_loss_event_rate(opt_val);
+ hctx->p = tfrc_sp_invert_loss_event_rate(opt_val);
ccid4_pr_debug("%s(%p), LOSS_EVENT_RATE=%u\n",
dccp_role(sk), sk, opt_val);
}
break;
case TFRC_OPT_DROPPED_PACKETS:
- /* FIXME: Implement this sock option according to ccid-4 draft */
+ tfrc_sp_parse_dropped_packets_opt(&hctx->li_data,
+ optval, optlen);
+
+ skb = skb_peek(&sk->sk_receive_queue);
+
+ if (skb == NULL)
+ break;
+
+ if (!tfrc_sp_check_ecn_sum(&hctx->li_data,
+ optval, optlen, skb)) {
+ /*
+ * TODO: consider ecn sum test fail
+ * and update allowed sending rate
+ */
+ }
+
+ new_p =
+ tfrc_sp_p_from_loss_intervals_opt(&hctx->li_data,
+ hctx->hist,
+ hctx->last_win_count,
+ DCCP_SKB_CB(skb)->dccpd_seq);
+ if (hctx->p != new_p) {
+ /*
+ * TODO: use p value obtained
+ * from loss intervals option
+ */
+ }
+
+ break;
+ case TFRC_OPT_LOSS_INTERVALS:
+
+ hctx->li_data.skip_length = *optval;
+ tfrc_sp_parse_loss_intervals_opt(&hctx->li_data,
+ optval, optlen);
+
+ skb = skb_peek(&sk->sk_receive_queue);
+
+ if (skb == NULL)
+ break;
+
+ if (!tfrc_sp_check_ecn_sum(&hctx->li_data,
+ optval, optlen, skb)) {
+ /*
+ * TODO: consider ecn sum test fail
+ * and update allowed sending rate
+ */
+ }
+
+ new_p =
+ tfrc_sp_p_from_loss_intervals_opt(&hctx->li_data,
+ hctx->hist,
+ hctx->last_win_count,
+ DCCP_SKB_CB(skb)->dccpd_seq);
+ if (hctx->p != new_p) {
+ /*
+ * TODO: use p value obtained
+ * from loss intervals option
+ */
+ }
break;
}
return 0;
@@ -505,7 +581,8 @@
struct tfrc_hc_tx_sock *hctx = tfrc_hc_tx_sk(sk);
sk_stop_timer(sk, &hctx->no_feedback_timer);
- tfrc_tx_hist_purge(&hctx->hist);
+ tfrc_sp_tx_hist_purge(&hctx->hist);
+ tfrc_sp_tx_ld_cleanup(&hctx->li_data.ecn_sums_head);
}
static void ccid4_hc_tx_get_info(struct sock *sk, struct tcp_info *info)
@@ -584,7 +661,7 @@
* have a reliable estimate for R_m of [RFC 3448, 6.2] and so
* always check whether at least RTT time units were covered.
*/
- hcrx->x_recv = tfrc_rx_hist_x_recv(&hcrx->hist, hcrx->x_recv);
+ hcrx->x_recv = tfrc_sp_rx_hist_x_recv(&hcrx->hist, hcrx->x_recv);
break;
case TFRC_FBACK_PERIODIC:
/*
@@ -594,7 +671,7 @@
*/
if (hcrx->hist.bytes_recvd == 0)
goto prepare_for_next_time;
- hcrx->x_recv = tfrc_rx_hist_x_recv(&hcrx->hist, hcrx->x_recv);
+ hcrx->x_recv = tfrc_sp_rx_hist_x_recv(&hcrx->hist, hcrx->x_recv);
break;
default:
return;
@@ -613,7 +690,8 @@
static int ccid4_hc_rx_insert_options(struct sock *sk, struct sk_buff *skb)
{
- const struct tfrc_hc_rx_sock *hcrx = tfrc_hc_rx_sk(sk);
+ u16 dropped_length, loss_intervals_length;
+ struct tfrc_hc_rx_sock *hcrx = tfrc_hc_rx_sk(sk);
__be32 x_recv, pinv;
if (!(sk->sk_state == DCCP_OPEN || sk->sk_state == DCCP_PARTOPEN))
@@ -625,10 +703,24 @@
x_recv = htonl(hcrx->x_recv);
pinv = htonl(hcrx->p_inverse);
+ loss_intervals_length =
+ (hcrx->li_data.counter > TFRC_LOSS_INTERVALS_OPT_MAX_LENGTH) ?
+ TFRC_LOSS_INTERVALS_OPT_MAX_LENGTH : hcrx->li_data.counter;
+ dropped_length =
+ (hcrx->li_data.counter > TFRC_DROP_OPT_MAX_LENGTH) ?
+ TFRC_DROP_OPT_MAX_LENGTH : hcrx->li_data.counter;
+
+ tfrc_sp_ld_prepare_data(hcrx->hist.loss_count, &hcrx->li_data);
+
if (dccp_insert_option(sk, skb, TFRC_OPT_LOSS_EVENT_RATE,
&pinv, sizeof(pinv)) ||
dccp_insert_option(sk, skb, TFRC_OPT_RECEIVE_RATE,
- &x_recv, sizeof(x_recv)))
+ &x_recv, sizeof(x_recv)) ||
+ dccp_insert_option(sk, skb, TFRC_OPT_LOSS_INTERVALS,
+ &hcrx->li_data.loss_intervals_opts[0],
+ 1 + loss_intervals_length*9) ||
+ dccp_insert_option(sk, skb, TFRC_OPT_DROPPED_PACKETS,
+ &hcrx->li_data.drop_opts[0], dropped_length*3))
return -1;
return 0;
@@ -657,12 +749,12 @@
if (unlikely(hcrx->feedback == TFRC_FBACK_NONE))
return 5;
- x_recv = tfrc_rx_hist_x_recv(&hcrx->hist, hcrx->x_recv);
+ x_recv = tfrc_sp_rx_hist_x_recv(&hcrx->hist, hcrx->x_recv);
if (x_recv == 0)
goto failed;
fval = scaled_div32(scaled_div(NOM_PACKET_SIZE, rtt), x_recv);
- p = tfrc_calc_x_reverse_lookup(fval);
+ p = tfrc_sp_calc_x_reverse_lookup(fval);
ccid4_pr_debug("%s(%p), receive rate=%u bytes/s, implied "
"loss rate=%u\n", dccp_role(sk), sk, x_recv, p);
@@ -682,8 +774,9 @@
/*
* Perform loss detection and handle pending losses
*/
- if (tfrc_rx_congestion_event(&hcrx->hist, &hcrx->li_hist,
- skb, ndp, ccid4_first_li, sk))
+ if (tfrc_sp_rx_congestion_event(&hcrx->hist, &hcrx->li_hist,
+ &hcrx->li_data,
+ skb, ndp, ccid4_first_li, sk))
ccid4_hc_rx_send_feedback(sk, skb, TFRC_FBACK_PARAM_CHANGE);
/*
* Feedback for first non-empty data packet (RFC 3448, 6.3)
@@ -703,15 +796,18 @@
struct tfrc_hc_rx_sock *hcrx = ccid_priv(ccid);
tfrc_lh_init(&hcrx->li_hist);
- return tfrc_rx_hist_init(&hcrx->hist, sk);
+ tfrc_ld_init(&hcrx->li_data);
+
+ return tfrc_sp_rx_hist_init(&hcrx->hist, sk);
}
static void ccid4_hc_rx_exit(struct sock *sk)
{
struct tfrc_hc_rx_sock *hcrx = tfrc_hc_rx_sk(sk);
- tfrc_rx_hist_purge(&hcrx->hist);
- tfrc_lh_cleanup(&hcrx->li_hist);
+ tfrc_sp_rx_hist_purge(&hcrx->hist);
+ tfrc_sp_lh_cleanup(&hcrx->li_hist);
+ tfrc_sp_ld_cleanup(&hcrx->li_data);
}
static void ccid4_hc_rx_get_info(struct sock *sk, struct tcp_info *info)
@@ -733,7 +829,7 @@
return -EINVAL;
rx_info.tfrcrx_x_recv = hcrx->x_recv;
rx_info.tfrcrx_rtt = tfrc_rx_hist_rtt(&hcrx->hist);
- rx_info.tfrcrx_p = tfrc_invert_loss_event_rate(hcrx->p_inverse);
+ rx_info.tfrcrx_p = tfrc_sp_invert_loss_event_rate(hcrx->p_inverse);
len = sizeof(rx_info);
val = &rx_info;
break;
@@ -755,7 +851,7 @@
.ccid_hc_tx_exit = ccid4_hc_tx_exit,
.ccid_hc_tx_send_packet = ccid4_hc_tx_send_packet,
.ccid_hc_tx_packet_sent = ccid4_hc_tx_packet_sent,
- .ccid_hc_tx_probe = tfrc_hc_tx_probe,
+ .ccid_hc_tx_probe = tfrc_sp_hc_tx_probe,
.ccid_hc_tx_packet_recv = ccid4_hc_tx_packet_recv,
.ccid_hc_tx_parse_options = ccid4_hc_tx_parse_options,
.ccid_hc_rx_obj_size = sizeof(struct tfrc_hc_rx_sock),
Index: dccp_tree_work04/net/dccp/ccids/Kconfig
===================================================================
--- dccp_tree_work04.orig/net/dccp/ccids/Kconfig 2009-10-12 20:02:20.807391426 -0300
+++ dccp_tree_work04/net/dccp/ccids/Kconfig 2009-10-12 20:02:47.843653027 -0300
@@ -160,7 +160,10 @@
endif # IP_DCCP_CCID4
config IP_DCCP_TFRC_LIB
- def_bool y if (IP_DCCP_CCID3 || IP_DCCP_CCID4)
+ def_bool y if IP_DCCP_CCID3
+
+config IP_DCCP_TFRC_SP_LIB
+ def_bool y if IP_DCCP_CCID4
config IP_DCCP_TFRC_DEBUG
def_bool y if (IP_DCCP_CCID3_DEBUG || IP_DCCP_CCID4_DEBUG)
^ permalink raw reply
* Re: [PATCH] net: Add netdev_alloc_skb_ip_align() helper
From: Stephen Hemminger @ 2009-10-13 17:30 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <4AD49DFC.9020406@gmail.com>
On Tue, 13 Oct 2009 17:34:20 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> David Miller a écrit :
> > From: Eric Dumazet <eric.dumazet@gmail.com>
> > Date: Thu, 08 Oct 2009 05:11:23 +0200
> >
> >> [PATCH] net: Add netdev_alloc_skb_ip_align() helper
> >>
> >> Instead of hardcoding NET_IP_ALIGN stuff in various network drivers, we can
> >> add a helper around netdev_alloc_skb()
> >>
> >> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> >
> > Applied to net-next-2.6
>
> Thanks, here is the followup cleanup patch to use this new helper
>
> [PATCH net-next-2.6] net: Use netdev_alloc_skb_ip_align()
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Name_is_getting_too_damn_long can we think of something beter.
Also, it isn't really ip alignment but compensating for the ethernet
header.
alloc_ether_skb?
^ permalink raw reply
* [PATCH 1/2] Adds ccid4 to DCCP test tree.
From: Ivo Calado @ 2009-10-13 17:30 UTC (permalink / raw)
To: dccp; +Cc: netdev, ivocalado
Adds ccid4 to DCCP test tree.
Changes:
- Adds ccid4, changing ccid3 code as necessary to keep common symbols separated
Following the rule #8 in Documentation/SubmittingPatches the patch is
stored at
http://embedded.ufcg.edu.br/~ivocalado/dccp/patches/patches_tfrc_sp_ccid4-v1/ccid4.patch
^ permalink raw reply
* [PATCH 0/2] Add implementation of CCID4 into the DCCP test tree
From: Ivo Calado @ 2009-10-13 17:27 UTC (permalink / raw)
To: dccp; +Cc: netdev, ivocalado
These patches add implementation of CCID4 into the DCCP test tree.
Patch #1: Adds ccid4 to DCCP test tree.
Patch #2: Modifies CCID4 in order to work with tfrc-sp.
--
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
* [PATCH 4/4] Implement loss intervals option
From: Ivo Calado @ 2009-10-13 17:27 UTC (permalink / raw)
To: dccp; +Cc: netdev, ivocalado
Implement loss intervals option. Similar to dropped packets option implementation, reference it.
Changes:
- Adds tfrc_sp_parse_loss_intervals_opt, that parses loss intervals option received data
Signed-off-by: Ivo Calado <ivocalado@embedded.ufcg.edu.br>
Signed-off-by: Erivaldo Xavier <desadoc@gmail.com>
Signed-off-by: Leandro Sales <leandroal@gmail.com>
Index: dccp_tree_work03/net/dccp/ccids/lib/loss_interval_sp.c
===================================================================
--- dccp_tree_work03.orig/net/dccp/ccids/lib/loss_interval_sp.c 2009-10-08 22:59:38.114908156 -0300
+++ dccp_tree_work03/net/dccp/ccids/lib/loss_interval_sp.c 2009-10-08 22:59:43.986408220 -0300
@@ -550,6 +550,46 @@
li_data->dropped_packets_data[0] = optlen/3;
}
+/*
+ * tfrc_sp_parse_loss_intervals_opt - parses loss interval option
+ * li_data: used to store parsed data
+ * optval: option data
+ * optlen: option length
+ */
+void tfrc_sp_parse_loss_intervals_opt(struct tfrc_tx_li_data *li_data,
+ u8 *optval, u8 optlen)
+{
+ u8 pos;
+ u32 length;
+
+ if ((optlen%9) != 1) {
+ li_data->loss_interval_data[0] = 0;
+ return;
+ }
+
+ pos = 1;
+ optval++;
+
+ while (pos < optlen) {
+ length = ntohl(((*((u32 *)optval)) & 0xFFFFFF00) >> 8);
+ pos += 3;
+ optval += 3;
+
+ length += ntohl(((*((u32 *)optval))&0x7FFFFF00) >> 8);
+ pos += 6;
+ optval += 6;
+
+ li_data->loss_interval_data[(pos-1)%9] = length;
+
+ if ((pos/9) == 9) {
+ li_data->loss_interval_data[0] = 9;
+ return;
+ }
+ }
+
+ li_data->loss_interval_data[0] = (optlen-1)/9;
+}
+
static void tfrc_sp_lh_calc_i_mean(struct tfrc_loss_hist *lh, __u8 curr_ccval)
{
u32 i_i, i_tot0 = 0, i_tot1 = 0, w_tot = 0;
Index: dccp_tree_work03/net/dccp/ccids/lib/loss_interval_sp.h
===================================================================
--- dccp_tree_work03.orig/net/dccp/ccids/lib/loss_interval_sp.h 2009-10-08 22:59:38.114908156 -0300
+++ dccp_tree_work03/net/dccp/ccids/lib/loss_interval_sp.h 2009-10-08 22:59:43.986408220 -0300
@@ -177,6 +177,8 @@
u8 curr_ccval, u64 seqno);
extern void tfrc_sp_parse_dropped_packets_opt(struct tfrc_tx_li_data *li_data,
u8 *optval, u8 optlen);
+extern void tfrc_sp_parse_loss_intervals_opt(struct tfrc_tx_li_data *li_data,
+ u8 *optval, u8 optlen);
extern void tfrc_sp_tx_ld_cleanup(struct tfrc_ecn_echo_sum_entry **);
#endif /* _DCCP_LI_HIST_SP_ */
^ permalink raw reply
* [PATCH 2/2] net: smsc911x: allow platform_data to specify mac address
From: Manuel Lauss @ 2009-10-13 17:25 UTC (permalink / raw)
To: netdev; +Cc: Steve Glendinning, Manuel Lauss
In-Reply-To: <1255454749-26895-1-git-send-email-manuel.lauss@gmail.com>
Extend the driver to accept a MAC address specified in platform_data.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
---
drivers/net/smsc911x.c | 3 +++
include/linux/smsc911x.h | 1 +
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/smsc911x.c b/drivers/net/smsc911x.c
index ccdd196..6a9f51d 100644
--- a/drivers/net/smsc911x.c
+++ b/drivers/net/smsc911x.c
@@ -2071,6 +2071,9 @@ static int __devinit smsc911x_drv_probe(struct platform_device *pdev)
if (is_valid_ether_addr(dev->dev_addr)) {
smsc911x_set_hw_mac_address(pdata, dev->dev_addr);
SMSC_TRACE(PROBE, "MAC Address is specified by configuration");
+ } else if (is_valid_ether_addr(pdata->config.mac)) {
+ memcpy(dev->dev_addr, pdata->config.mac, 6);
+ SMSC_TRACE(PROBE, "MAC Address specified by platform data");
} else {
/* Try reading mac address from device. if EEPROM is present
* it will already have been set */
diff --git a/include/linux/smsc911x.h b/include/linux/smsc911x.h
index 5241e4f..7144e8a 100644
--- a/include/linux/smsc911x.h
+++ b/include/linux/smsc911x.h
@@ -30,6 +30,7 @@ struct smsc911x_platform_config {
unsigned int irq_type;
unsigned int flags;
phy_interface_t phy_interface;
+ unsigned char mac[6];
};
/* Constants for platform_device irq polarity configuration */
--
1.6.5.rc2
^ permalink raw reply related
* [PATCH 1/2] net: enable smsc911x on MIPS
From: Manuel Lauss @ 2009-10-13 17:25 UTC (permalink / raw)
To: netdev; +Cc: Steve Glendinning, Manuel Lauss
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
---
drivers/net/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 7127760..d9772af 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1001,7 +1001,7 @@ config SMC911X
config SMSC911X
tristate "SMSC LAN911x/LAN921x families embedded ethernet support"
- depends on ARM || SUPERH || BLACKFIN
+ depends on ARM || SUPERH || BLACKFIN || MIPS
select CRC32
select MII
select PHYLIB
--
1.6.5.rc2
^ permalink raw reply related
* [PATCH 3/4] Implement dropped packets option
From: Ivo Calado @ 2009-10-13 17:25 UTC (permalink / raw)
To: dccp; +Cc: netdev, ivocalado
Implement dropped packets option. First we parse the received option and store the data, then we check the ecn sum along
the intervals described. The last step calcs 'p' from the option data and only suceeds if loss interval data was parsed before
and is ready to be consumed.
Changes:
- Adds tfrc_sp_check_ecn_sum, that checks ecn in the received option
- Adds tfrc_sp_p_from_loss_intervals_opt, do 'p' calc from parsed and stored option data
- Adds tfrc_sp_parse_dropped_packets_opt, that do the parsing of received option, storing data
Signed-off-by: Ivo Calado <ivocalado@embedded.ufcg.edu.br>
Signed-off-by: Erivaldo Xavier <desadoc@gmail.com>
Signed-off-by: Leandro Sales <leandroal@gmail.com>
Index: dccp_tree_work03/net/dccp/ccids/lib/loss_interval_sp.c
===================================================================
--- dccp_tree_work03.orig/net/dccp/ccids/lib/loss_interval_sp.c 2009-10-08 22:59:26.926501680 -0300
+++ dccp_tree_work03/net/dccp/ccids/lib/loss_interval_sp.c 2009-10-08 22:59:38.114908156 -0300
@@ -350,6 +350,206 @@
h->ecn_nonce_sum = !h->ecn_nonce_sum;
}
+/*
+ * tfrc_sp_check_ecn_sum - check received ecn sum parsed from
+ * loss interval option
+ * li_data: data parsed from options
+ * optval: data from option
+ * optlen: option data length
+ * skb: last received packet
+ */
+bool tfrc_sp_check_ecn_sum(struct tfrc_tx_li_data *li_data, u8 *optval,
+ u8 optlen, struct sk_buff *skb)
+{
+ u8 skip_length;
+ u32 data_length;
+ u8 sum0, sum1, li_sum;
+ struct tfrc_ecn_echo_sum_entry *entry;
+ u64 seqn;
+
+ if ((optlen < 10) || ((optlen - 1)%3 != 0))
+ return false;
+
+ if (li_data == NULL)
+ return true;
+
+ entry = li_data->ecn_sums_head;
+
+ if (entry == NULL)
+ return true;
+
+ seqn = dccp_hdr_ack_seq(skb);
+
+ while (entry->seq_num != seqn) {
+ entry = entry->previous;
+
+ if (entry == NULL)
+ return true;
+ }
+
+ skip_length = *optval;
+ optval++;
+ optlen--;
+
+ while (skip_length--) {
+ entry = entry->previous;
+
+ if (entry == NULL)
+ return false;
+ }
+
+ optval += 3;
+ optlen -= 3;
+
+ do {
+ sum0 = entry->ecn_echo_sum;
+
+ li_sum = (*((u32 *)optval)&0x80000000) ? 1 : 0;
+
+ optval += 3;
+ optlen -= 3;
+
+ data_length = ntohl((*((u32 *)optval) & 0xFFFFFF00) >> 8);
+
+ while (--data_length) {
+ entry = entry->previous;
+
+ if (entry == NULL)
+ return true;
+ }
+
+ sum1 = entry->ecn_echo_sum;
+
+ if (((sum0+sum1) & 0x1) != li_sum)
+ return false;
+
+ optval += 6;
+ optlen -= 6;
+
+ } while (optlen >= 9);
+
+ if (entry != NULL)
+ tfrc_sp_tx_ld_cleanup(&entry->previous);
+
+ return true;
+}
+
+static struct tfrc_tx_hist_entry*
+ tfrc_sp_seek_tx_entry(struct tfrc_tx_hist_entry *head,
+ u64 seqno, u32 backward)
+{
+ if (head == NULL)
+ return NULL;
+
+ while (head->seqno != seqno) {
+ head = head->next;
+
+ if (head == NULL)
+ return NULL;
+ }
+
+ while (backward-- > 0) {
+ head = head->next;
+
+ if (head == NULL)
+ return NULL;
+ }
+
+ return head;
+}
+
+/*
+ * tfrc_sp_p_from_loss_intervals_opt - calcs p from loss interval option
+ * li_data: data parsed from options
+ * head: contains ccval info
+ * curr_ccval: current ccval
+ * seqno: last acked seqno
+ */
+u32 tfrc_sp_p_from_loss_intervals_opt(struct tfrc_tx_li_data *li_data,
+ struct tfrc_tx_hist_entry *head,
+ u8 curr_ccval, u64 seqno)
+{
+ int i, k;
+ u8 ccval;
+ u32 i_i, i_tot0, i_tot1, w_tot, i_totl, losses, mean;
+ i_tot0 = i_tot1 = w_tot = i_totl = 0;
+
+ if (li_data->loss_interval_data[0] == 0)
+ return 0;
+
+ if (li_data->loss_interval_data[0] < li_data->dropped_packets_data[0])
+ return 0;
+
+ k = li_data->loss_interval_data[0];
+
+ for (i = 1; i <= k; i++) {
+ i_i = li_data->loss_interval_data[i];
+ i_totl += i_i;
+ ccval = tfrc_sp_seek_tx_entry(head, seqno, i_totl - 1)->ccval;
+
+ if (SUB16(curr_ccval, ccval) <= 8) {
+ losses = li_data->dropped_packets_data[i];
+
+ if (losses > 0)
+ i_i = div64_u64(i_i, losses);
+ }
+
+ if (i != k) {
+ i_tot0 += i_i * tfrc_lh_weights[i-1];
+ w_tot += tfrc_lh_weights[i-1];
+ }
+
+ if (i > 1)
+ i_tot1 += i_i * tfrc_lh_weights[i-2];
+ }
+
+ ccval = tfrc_sp_seek_tx_entry(head, seqno,
+ li_data->loss_interval_data[1] - 1)->ccval;
+
+ if (SUB16(curr_ccval, ccval) > 8)
+ mean = max(i_tot0, i_tot1) / w_tot;
+ else
+ mean = i_tot1 / w_tot;
+
+ return tfrc_sp_invert_loss_event_rate(mean);
+
+ return 0;
+}
+
+/*
+ * tfrc_sp_parse_dropped_packets_opt - parses received dropped packets option
+ * li_data: used to store parsed data
+ * optval: option data
+ * optlen: option length
+ */
+void tfrc_sp_parse_dropped_packets_opt(struct tfrc_tx_li_data *li_data,
+ u8 *optval, u8 optlen)
+{
+ u8 pos;
+ u32 dropped;
+
+ if ((optlen%3) != 0) {
+ li_data->dropped_packets_data[0] = 0;
+ return;
+ }
+
+ pos = 0;
+
+ while (pos < optlen) {
+ dropped = ntohl(((*((u32 *)(optval + pos))) & 0xFFFFFF00) >> 8);
+ li_data->dropped_packets_data[1 + (pos/3)] = dropped;
+
+ if ((pos/3) == 9) {
+ li_data->dropped_packets_data[0] = 9;
+ return;
+ }
+
+ pos += 3;
+ }
+
+ li_data->dropped_packets_data[0] = optlen/3;
+}
+
static void tfrc_sp_lh_calc_i_mean(struct tfrc_loss_hist *lh, __u8 curr_ccval)
{
u32 i_i, i_tot0 = 0, i_tot1 = 0, w_tot = 0;
@@ -400,7 +600,10 @@
if (cur == NULL) /* not initialised */
return;
- /* FIXME: should probably also count non-data packets (RFC 4342, 6.1) */
+ /*
+ * FIXME: should probably also count non-data packets
+ * (RFC 4342, 6.1)
+ */
if (!dccp_data_packet(skb))
return;
Index: dccp_tree_work03/net/dccp/ccids/lib/loss_interval_sp.h
===================================================================
--- dccp_tree_work03.orig/net/dccp/ccids/lib/loss_interval_sp.h 2009-10-08 22:59:26.926501680 -0300
+++ dccp_tree_work03/net/dccp/ccids/lib/loss_interval_sp.h 2009-10-08 22:59:38.114908156 -0300
@@ -169,6 +169,14 @@
extern void tfrc_sp_ld_cleanup(struct tfrc_loss_data *ld);
extern void tfrc_sp_ld_prepare_data(u8 loss_count, struct tfrc_loss_data *ld);
extern int tfrc_sp_get_random_ect(struct tfrc_tx_li_data *li_data, u64 seqn);
+extern bool tfrc_sp_check_ecn_sum(struct tfrc_tx_li_data *li_data, u8 *optval,
+ u8 optlen, struct sk_buff *skb);
+struct tfrc_tx_hist_entry;
+extern u32 tfrc_sp_p_from_loss_intervals_opt(struct tfrc_tx_li_data *li_data,
+ struct tfrc_tx_hist_entry *head,
+ u8 curr_ccval, u64 seqno);
+extern void tfrc_sp_parse_dropped_packets_opt(struct tfrc_tx_li_data *li_data,
+ u8 *optval, u8 optlen);
extern void tfrc_sp_tx_ld_cleanup(struct tfrc_ecn_echo_sum_entry **);
#endif /* _DCCP_LI_HIST_SP_ */
^ permalink raw reply
* [PATCH 2/4] Implement function that allows to keep track of packets sent in last 2 rtt
From: Ivo Calado @ 2009-10-13 17:24 UTC (permalink / raw)
To: dccp; +Cc: netdev, ivocalado
Implement function that allows to keep track of packets sent in last 2 rtt
Changes:
- Creates tfrc_tx_hist_two_rtt_old, that return the first list node at least 2 rtt old
Signed-off-by: Ivo Calado <ivocalado@embedded.ufcg.edu.br>
Signed-off-by: Erivaldo Xavier <desadoc@gmail.com>
Signed-off-by: Leandro Sales <leandroal@gmail.com>
Index: dccp_tree_work03/net/dccp/ccids/lib/packet_history_sp.c
===================================================================
--- dccp_tree_work03.orig/net/dccp/ccids/lib/packet_history_sp.c 2009-10-08 22:59:20.526408512 -0300
+++ dccp_tree_work03/net/dccp/ccids/lib/packet_history_sp.c 2009-10-08 22:59:32.582408479 -0300
@@ -65,7 +65,7 @@
}
}
-int tfrc_sp_tx_hist_add(struct tfrc_tx_hist_entry **headp, u64 seqno)
+int tfrc_sp_tx_hist_add(struct tfrc_tx_hist_entry **headp, u64 seqno, u8 ccval)
{
struct tfrc_tx_hist_entry *entry =
kmem_cache_alloc(tfrc_tx_hist_slab, gfp_any());
@@ -73,6 +73,7 @@
if (entry == NULL)
return -ENOBUFS;
entry->seqno = seqno;
+ entry->ccval = ccval;
entry->stamp = ktime_get_real();
entry->next = *headp;
*headp = entry;
Index: dccp_tree_work03/net/dccp/ccids/lib/packet_history_sp.h
===================================================================
--- dccp_tree_work03.orig/net/dccp/ccids/lib/packet_history_sp.h 2009-10-08 22:59:20.526408512 -0300
+++ dccp_tree_work03/net/dccp/ccids/lib/packet_history_sp.h 2009-10-08 22:59:32.582408479 -0300
@@ -57,6 +57,7 @@
struct tfrc_tx_hist_entry {
struct tfrc_tx_hist_entry *next;
u64 seqno;
+ u8 ccval:4;
ktime_t stamp;
};
@@ -69,13 +70,27 @@
}
#endif
-extern int tfrc_sp_tx_hist_add(struct tfrc_tx_hist_entry **headp, u64 seqno);
+extern int tfrc_sp_tx_hist_add(struct tfrc_tx_hist_entry **headp,
+ u64 seqno, u8 ccval);
extern void tfrc_sp_tx_hist_purge(struct tfrc_tx_hist_entry **headp);
#ifndef _DCCP_PKT_HIST_
/* Subtraction a-b modulo-16, respects circular wrap-around */
#define SUB16(a, b) (((a) + 16 - (b)) & 0xF)
+/*
+ * tfrc_tx_hist_two_rtt_old - returns entry at least two rtt old
+ * head: list of tx history entries
+ * cur_ccval: current ccval
+ */
+static inline struct tfrc_tx_hist_entry *
+ tfrc_tx_hist_two_rtt_old(struct tfrc_tx_hist_entry *head, u8 cur_ccval)
+{
+ while ((head != NULL) && (SUB16(cur_ccval, head->ccval) <= 8))
+ head = head->next;
+ return head;
+}
+
/* Number of packets to wait after a missing packet (RFC 4342, 6.1) */
#define TFRC_NDUPACK 3
^ permalink raw reply
* [PATCH 1/4] Adds random ect generation to tfrc-sp sender side
From: Ivo Calado @ 2009-10-13 17:23 UTC (permalink / raw)
To: dccp; +Cc: netdev, ivocalado
Adds random ect generation to tfrc-sp sender side. Before sending the packet, TFRC-SP chooses randomly
one ect codepoint, returns it and register at the ect history list.
Changes:
- Creates tfrc_sp_get_random_ect, that uses random.h to choose one ect codepoint
- Defines tfrc_tx_li_data, that stores data parsed from options loss intervals and dropped packets, and ecn nonce history
- Defines tfrc_ecn_echo_sum_entry, type of entries of ecn nonce history list
- Adds memory manage routines and code to these structures
Signed-off-by: Ivo Calado <ivocalado@embedded.ufcg.edu.br>
Signed-off-by: Erivaldo Xavier <desadoc@gmail.com>
Signed-off-by: Leandro Sales <leandroal@gmail.com>
Index: dccp_tree_work03/net/dccp/ccids/lib/loss_interval_sp.c
===================================================================
--- dccp_tree_work03.orig/net/dccp/ccids/lib/loss_interval_sp.c 2009-10-08 22:59:20.526408512 -0300
+++ dccp_tree_work03/net/dccp/ccids/lib/loss_interval_sp.c 2009-10-08 22:59:26.926501680 -0300
@@ -15,6 +15,7 @@
static struct kmem_cache *tfrc_lh_slab __read_mostly;
static struct kmem_cache *tfrc_ld_slab __read_mostly;
+static struct kmem_cache *tfrc_ecn_echo_sum_slab __read_mostly;
/* Loss Interval weights from [RFC 3448, 5.4], scaled by 10 */
static const int tfrc_lh_weights[NINTERVAL] = { 10, 10, 10, 10, 8, 6, 4, 2 };
@@ -84,6 +85,48 @@
}
/*
+ * tfrc_sp_get_random_ect - return random ect codepoint
+ * li_data: data where to register ect sent
+ * seqn: packet's sequence number
+ */
+int tfrc_sp_get_random_ect(struct tfrc_tx_li_data *li_data, u64 seqn)
+{
+ int ect;
+ struct tfrc_ecn_echo_sum_entry *sum;
+
+ /* TODO: implement random ect*/
+ ect = INET_ECN_ECT_0;
+
+ sum = kmem_cache_alloc(tfrc_ecn_echo_sum_slab, GFP_ATOMIC);
+
+ sum->previous = li_data->ecn_sums_head;
+ sum->ecn_echo_sum = (sum->previous->ecn_echo_sum) ? !ect : ect;
+ sum->seq_num = seqn;
+
+ li_data->ecn_sums_head = sum;
+
+ return ect;
+}
+
+/*
+ * tfrc_sp_tx_ld_cleanup - free all entries
+ * echo_sums_data: head of the list
+ */
+void tfrc_sp_tx_ld_cleanup(struct tfrc_ecn_echo_sum_entry **echo_sums_data)
+{
+ struct tfrc_ecn_echo_sum_entry *e, *previous;
+ e = *echo_sums_data;
+
+ while (e != NULL) {
+ previous = e->previous;
+ kmem_cache_free(tfrc_ecn_echo_sum_slab, e);
+ e = previous;
+ }
+
+ *echo_sums_data = NULL;
+}
+
+/*
* Allocation routine for new entries of loss interval data
*/
static struct tfrc_loss_data_entry *tfrc_ld_add_new(struct tfrc_loss_data *ld)
@@ -493,8 +536,13 @@
tfrc_ld_slab = kmem_cache_create("tfrc_sp_li_data",
sizeof(struct tfrc_loss_data_entry), 0,
SLAB_HWCACHE_ALIGN, NULL);
-
- if ((tfrc_lh_slab != NULL) && (tfrc_ld_slab != NULL))
+ tfrc_ecn_echo_sum_slab = kmem_cache_create("tfrc_sp_ecn_echo_sum",
+ sizeof(struct tfrc_ecn_echo_sum_entry), 0,
+ SLAB_HWCACHE_ALIGN, NULL);
+
+ if ((tfrc_lh_slab != NULL) &&
+ (tfrc_ld_slab != NULL) &&
+ (tfrc_ecn_echo_sum_slab != NULL))
return 0;
if (tfrc_lh_slab != NULL) {
@@ -507,6 +555,11 @@
tfrc_ld_slab = NULL;
}
+ if (tfrc_ecn_echo_sum_slab != NULL) {
+ kmem_cache_destroy(tfrc_ecn_echo_sum_slab);
+ tfrc_ecn_echo_sum_slab = NULL;
+ }
+
return -ENOBUFS;
}
@@ -521,4 +574,9 @@
kmem_cache_destroy(tfrc_ld_slab);
tfrc_ld_slab = NULL;
}
+
+ if (tfrc_ecn_echo_sum_slab != NULL) {
+ kmem_cache_destroy(tfrc_ecn_echo_sum_slab);
+ tfrc_ecn_echo_sum_slab = NULL;
+ }
}
Index: dccp_tree_work03/net/dccp/ccids/lib/loss_interval_sp.h
===================================================================
--- dccp_tree_work03.orig/net/dccp/ccids/lib/loss_interval_sp.h 2009-10-08 22:59:20.526408512 -0300
+++ dccp_tree_work03/net/dccp/ccids/lib/loss_interval_sp.h 2009-10-08 22:59:26.926501680 -0300
@@ -128,6 +128,31 @@
memset(ld, 0, sizeof(*ld));
}
+/*
+ * tfrc_ecn_echo_sum_entry - store sent ecn codepoint info
+ * ecn_echo_sum: ecn echo sum up to that packet
+ * seq_num: sequence number of packet
+ * previous: previous sent packet info
+ */
+struct tfrc_ecn_echo_sum_entry {
+ u8 ecn_echo_sum:1;
+ u64 seq_num:48;
+ struct tfrc_ecn_echo_sum_entry *previous;
+};
+
+/*
+ * tfrc_tx_li_data - data about sent ecn and parsed options
+ * ecn_sums_head: ecn data list
+ * seq_num: sequence number of packet
+ * previous: previous sent packet info
+ */
+struct tfrc_tx_li_data {
+ struct tfrc_ecn_echo_sum_entry *ecn_sums_head;
+ u32 dropped_packets_data[1 + 9];
+ u32 loss_interval_data[1 + 9];
+ u8 skip_length;
+};
+
struct tfrc_rx_hist;
extern bool tfrc_sp_lh_interval_add(struct tfrc_loss_hist *,
@@ -143,6 +168,8 @@
extern void tfrc_sp_lh_cleanup(struct tfrc_loss_hist *lh);
extern void tfrc_sp_ld_cleanup(struct tfrc_loss_data *ld);
extern void tfrc_sp_ld_prepare_data(u8 loss_count, struct tfrc_loss_data *ld);
+extern int tfrc_sp_get_random_ect(struct tfrc_tx_li_data *li_data, u64 seqn);
+extern void tfrc_sp_tx_ld_cleanup(struct tfrc_ecn_echo_sum_entry **);
#endif /* _DCCP_LI_HIST_SP_ */
Index: dccp_tree_work03/net/dccp/ccids/lib/tfrc_ccids_sp.h
===================================================================
--- dccp_tree_work03.orig/net/dccp/ccids/lib/tfrc_ccids_sp.h 2009-10-08 22:59:20.526408512 -0300
+++ dccp_tree_work03/net/dccp/ccids/lib/tfrc_ccids_sp.h 2009-10-08 22:59:26.926501680 -0300
@@ -85,6 +85,7 @@
ktime_t t_ld;
ktime_t t_nom;
struct tfrc_tx_hist_entry *hist;
+ struct tfrc_tx_li_data li_data;
};
static inline struct tfrc_hc_tx_sock *tfrc_hc_tx_sk(const struct sock *sk)
^ permalink raw reply
* Re: [PATCH 0/8] gianfar: Add support for hibernation
From: Andy Fleming @ 2009-10-13 17:22 UTC (permalink / raw)
To: David Miller; +Cc: scottwood, linuxppc-dev, netdev
In-Reply-To: <20091012.235747.195783342.davem@davemloft.net>
On Oct 13, 2009, at 1:57 AM, David Miller wrote:
> From: Anton Vorontsov <avorontsov@ru.mvista.com>
> Date: Mon, 12 Oct 2009 20:00:00 +0400
>
>> Here are few patches that add support for hibernation for gianfar
>> driver.
>>
>> Technically, we could just do gfar_close() and then gfar_enet_open()
>> sequence to restore gianfar functionality after hibernation, but
>> close/open does so many unneeded things (e.g. BDs buffers freeing and
>> allocation, IRQ freeing and requesting), that I felt it would be much
>> better to cleanup and refactor some code to make the hibernation [and
>> not only hibernation] code a little bit prettier.
>
> I applied all of this, it's a really nice patch set. If there are any
> problems we can deal with it using follow-on fixups.
>
> I noticed something, in patch #3 where you remove the spurious wrap
> bit setting in startup_gfar(). It looks like that was not only
> spurious but it was doing it wrong too.
>
> It's writing garbage into the status word, because it's not using the
> BD_LFLAG() macro to shift the value up 16 bits.
>
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.
Andy
^ 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