Date:	Mon, 18 Sep 2000 21:31:17 -0400 (EDT)
From:	jamal <hadi@cyberus.ca>
To:	davem@redhat.com, kuznet@ms2.inr.ac.ru
Subject: [PATCH/RFC] (long) network interface changes

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

---559023410-851401618-969327077=:3641
Content-Type: TEXT/PLAIN; charset=US-ASCII



I apologize for the over 10K email.. consider this documentation ;->
This is cross-posted to l-k; i would prefer the discussions on netdev
or cc netdev (i am not subscribed to l-k)

This is a port against 2.4.0-test8 based on the OLS presentation i made 
"Fast Forwarding the Bird" available at:
http://robur.slu.se/Linux/net-development/jamal/FF-html/

There are lotsa improvements since OLS in a collaboration involving 
Robert Olsson and myself. 

Current snapshot is available via ftp from:
ftp://robur.slu.se:/pub/Linux/net-development/FF-bird-current.tgz
This includes a patched tulip driver; tested only on a DEC21143-based
4-port cards.

This RFC at:
ftp://robur.slu.se:/pub/Linux/net-development/README-FF

To make things interesting robur.slu.se is currently running these patches.

Acknowledgements
-----------------

1) Alexey Kuznetsov : Without his FF and FC these thoughts might never have
been born. Alexey is still involved whenever time permits.
2) Robert Olsson : Many insights and current partner-in-crime
3) Donald Becker : Well thought network driver design.

-----------------------------
Test updates September/2000:
-----------------------------

Robert Olson and I decided after the OLS that we were going to try to
hit the 100Mbps(148.8Kpps) routing peak by year end. I am afraid the
bar has been raised. Robert is already hitting with 2.4.0-test7 ~148Kpps
with a ASUS CUBX motherboard carrying PIII 700 MHZ coppermine with 
about 65% CPU utilization.
With a single PII based Dell machine i was able to get a consistent value of
110Kpps.

So the new goal is to go to about 500Kpps ;-> (maybe not by year end, but
surely by that next random Linux hacker conference)

A sample modified tulip driver (hacked by Alexey for 2.2 and mod'ed by Robert
and myself over a period of time) is supplied as an example on how to use the
feedback values.


General blurb
-------------

To begin, i have to say that forwarding 100Mbps of 64byte packets is _not_
a problem at all in Linux; Alexey's Fast Forwarding does a fine job.

FF, like in routers is _not_ subjected to Firewalling (eg CISCO Fast routing).
So the challenge was to try and do it without FF turned on so we could do 
firewalling.

** Very important to note:
Although the tests and improvements were for packet forwarding, the technique
used applies for servers under a heavy load. System congestion is moved down
to the hardware therefore alleviating the system overload. 
I believe we could have done better with the mindcraft tests with these 
changes in 2.2 (and HW FC turned on). 
[Fact is, HW FC was there but i suppose no-one knew you could
use Alexey's hacked version of the Tulip ;->]

The changes proposed below are transparent to drivers that dont use them. 
It is however highly encouraged they take advantage of the supplied 
interface. This does not break anything in 2.4. It is a clean patch.

- This is a first cut, hopefully discussions will ensue and maybe a 
revision of the patch. In particular of interest are the recent weird
requirements by the X.25 code.
Refer to thread on l-k "Re: Q: sock output serialization"
Henner, hoping to hear from you.

- I intend on submitting this patch for inclusion in 2.4 since it is 
non-intrusive. I suspect there will be about one more revision.

*** Proposed changes:

Change 1) 
---------

netif_rx() now returns a value to the driver (change from void).

The queue is divided into 4 configurable threshold regions:
*no congestion zone
*low congestion zone
*moderate congestion
*A high congestion zone.
*A drop zone where packets are dropped.
(the configuration interface is via /proc/sys/net/core/)

A positive value (different for each of the regions) implies that the packet 
was successfully queued whereas a negative value implies it was dropped.

The default congestion threshold values are based on engineering 
experimentation and not on theoretical scientific proofs. There are 
probably better ways of drawing up the associated thresholds.

I would like to add that the HW FC feature is _a neccessary requirement_
to complement this. Maybe i should say this complements HW FC.
If a driver keeps sending packets up to netif_rx() even when its been given 
feedback to stop, HW FC kicks in and the device is shut up; "sent to its room" 
so to speak. So the HW FC is considered the "when all else fails" rule.
A separate document will describe how to use HW FC for driver authors.
I think it should be a *mandantory* interface to drivers.

The netif_rx() feedback helps the driver get 2 insights:
i) understand the fate of the packets it sent up the stack. No point
in continuing to blast packets to the stack when they are being dropped.
(which happens today)
ii) smartly gauge the congestion level on the stack and adjust the
rate at which packets are being sent to the stack to reduce overall
system load. A scheme which moves the congestion away from the system and
onto the driver is considered a bonus. The tulip does this in two ways
selectable at compile: 1) Kill the rx thread or 2) kill the rx_interupt.
Both which work extremely well. 
[The sample tulip driver can be made to use 2) by undefining D_INT in
tulip.h ]

The driver uses the feedback information to intelligently adjust its 
sending rate.  (i.e reduce or increase calls to netif_rx() or send a 
congestion-experienced frame to its peer eg in X.25). 
In the sample tulip driver, dynamic mitigation based on congestion feedback 
is used. Under low congestion, the mitigation parameters are turned off 
(default behavior as is today); under heavy congestion we dynamically move 
up to 16 packet times. It is not mandatory to use this scheme; however, 
it serves as a good example. A word of caution: This scheme is still being
experimented on; we feel we could do better. Look at the code.

change 2) 
---------

The backlog queue is now getting sampled.
This helps in detecting incipient congestion by the top layer. 
Essentially, the sampler is a low-pass filter which weeds out 
"congestion detected" wolf-cries due to sudden short bursts which
fill the backlog. 

I have experimented with two schemes: one which samples the queue via 
a timer and one which does it per-packet and found that the per-packet
sampler gave better results (more samples, Shannon's theorem applies).
It didnt matter whether HZ was 100 or 1024 during the tests.
The measure of "better" was throughput.

change 3) 
---------

Introduce a scheme which does occasionaly send a "random-lie"
when around moderate to high congestions; 
The motivation for this is to improve unfairness issues of many devices
sharing the same backlog queue.
e.g if eth0 is blasting 70Kpps to the backlog queue and eth1 is merely 
sending 10pps, then under the current system setup, eth0 will pretty
much fill up the backlog (every time it gets drained) and have a
very small opportunities to queue for eth1. Imagine scaling this to over 
10 interfaces with eth0 blasting at that rate.

Solution i have devised:
- Randomly lie in the feedback to the driver when under moderate to high
congestion levels (tell device there is a higher congestion than really is).
Theory is that "the harder they come, the harder they fall". It is more
than likely that eth0s packets from the above example will be hit than 
say eth1 by the randomness (simply because there is more of them to take 
target shots at)

My testing with the included scheme (#ifdef RAND_LIE) indicates that fairness 
infact goes up; however, the overall throughput when only one interface
is utilizing the system goes down under heavy to moderate congestion.
I am including it here as a way to highlight the problem. I think there could
be better ways to do this.
Code is included and can be turned on by defining RAND_LIE in dev.c

change 4) 
---------

After a brief talk with Alexey and Robert at the OLS, i am withdrawing this 
change proposal.
Currently after netdev_dropping is raised, all incoming packets to the
backlog are dropped even if there was only a single packet on the queue. 
I had proposed removing that check. In a world with good driver-zens 
(system-zens?) where every driver backs off once system congestion is detected,
the change would make sense. It is, however, unfair to good citizens to backoff
while the bad guys are filling the backlog which is what would happen if the
change is made.


cheers,
jamal

---559023410-851401618-969327077=:3641
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=FF-patch-test8
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.GSO.4.20.0009182131170.3641@shell.cyberus.ca>
Content-Description: 
Content-Disposition: attachment; filename=FF-patch-test8

LS0tIGxpbnV4L25ldC9jb3JlL2Rldi5jLm9yaWcJVGh1IFNlcCAgNyAxMToz
MjowMSAyMDAwDQorKysgbGludXgvbmV0L2NvcmUvZGV2LmMJVHVlIFNlcCAx
MiAyMDowMjoyMCAyMDAwDQpAQCAtOTcsNiArOTcsOSBAQA0KIGV4dGVybiBp
bnQgcGxpcF9pbml0KHZvaWQpOw0KICNlbmRpZg0KIA0KKy8qDQorI2RlZmlu
ZSBSQU5EX0xJRSAxDQorKi8NCiBORVRfUFJPRklMRV9ERUZJTkUoZGV2X3F1
ZXVlX3htaXQpDQogTkVUX1BST0ZJTEVfREVGSU5FKHNvZnRuZXRfcHJvY2Vz
cykNCiANCkBAIC0xMzMsNiArMTM2LDExIEBADQogc3RhdGljIHN0cnVjdCBw
YWNrZXRfdHlwZSAqcHR5cGVfYmFzZVsxNl07CQkvKiAxNiB3YXkgaGFzaGVk
IGxpc3QgKi8NCiBzdGF0aWMgc3RydWN0IHBhY2tldF90eXBlICpwdHlwZV9h
bGwgPSBOVUxMOwkJLyogVGFwcyAqLw0KIA0KKyNpZmRlZiBvZmZsaW5lX3Nh
bXBsZQ0KK3N0YXRpYyB2b2lkIHNhbXBsZV9xdWV1ZSh1bnNpZ25lZCBsb25n
IGR1bW15KTsNCitzdGF0aWMgc3RydWN0IHRpbWVyX2xpc3Qgc2FtcF90aW1l
ciA9IHsgeyBOVUxMLCBOVUxMIH0sIDAsIDAsICZzYW1wbGVfcXVldWUgfTsN
CisjZW5kaWYNCisNCiAvKg0KICAqCU91ciBub3RpZmllciBsaXN0DQogICov
DQpAQCAtOTUxLDEyICs5NTksMjUgQEANCiAgID09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09Ki8NCiANCiBpbnQgbmV0ZGV2X21heF9iYWNrbG9nID0gMzAw
Ow0KKy8qIHRoZXNlIG51bWJlcnMgYXJlIHNlbGVjdGVkIGJhc2VkIG9uIGlu
dHVpdGlvbiBhbmQgc29tZQ0KK2V4cGVyaW1lbnRhdGlvbSwgaWYgeW91IGhh
dmUgbW9yZSBzY2llbnRpZmljIHdheSBvZiBkb2luZyB0aGlzDQorcGxlYXNl
IGdvIGFoZWFkIGFuZCBmaXggdGhpbmdzDQorKi8NCitpbnQgbm9fY29uZ190
aHJlc2g9MTA7DQoraW50IG5vX2Nvbmc9MjA7DQoraW50IGxvX2Nvbmc9MTAw
Ow0KK2ludCBtb2RfY29uZz0yOTA7DQorDQorDQogDQogc3RydWN0IG5ldGlm
X3J4X3N0YXRzIG5ldGRldl9yeF9zdGF0W05SX0NQVVNdOw0KIA0KIA0KICNp
ZmRlZiBDT05GSUdfTkVUX0hXX0ZMT1dDT05UUk9MDQorLyoNCiBzdGF0aWMg
YXRvbWljX3QgbmV0ZGV2X2Ryb3BwaW5nID0gQVRPTUlDX0lOSVQoMCk7DQor
Ki8NCithdG9taWNfdCBuZXRkZXZfZHJvcHBpbmcgPSBBVE9NSUNfSU5JVCgw
KTsNCiBzdGF0aWMgdW5zaWduZWQgbG9uZyBuZXRkZXZfZmNfbWFzayA9IDE7
DQogdW5zaWduZWQgbG9uZyBuZXRkZXZfZmNfeG9mZiA9IDA7DQogc3Bpbmxv
Y2tfdCBuZXRkZXZfZmNfbG9jayA9IFNQSU5fTE9DS19VTkxPQ0tFRDsNCkBA
IC0xMDE0LDYgKzEwMzUsNTYgQEANCiB9DQogI2VuZGlmDQogDQorc3RhdGlj
IHZvaWQgZ2V0X3NhbXBsZV9zdGF0cyhpbnQgY3B1KQ0KK3sNCisjaWZkZWYg
UkFORF9MSUUNCisJdW5zaWduZWQgbG9uZyByZDsNCisJaW50IHJxOw0KKyNl
bmRpZg0KKwlpbnQgYmxvZz1zb2Z0bmV0X2RhdGFbY3B1XS5pbnB1dF9wa3Rf
cXVldWUucWxlbjsNCisJaW50IGF2Z19ibG9nPXNvZnRuZXRfZGF0YVtjcHVd
LmF2Z19ibG9nOw0KKw0KKwlhdmdfYmxvZz0oYXZnX2Jsb2cgPj4gMSkrIChi
bG9nPj4xKTsNCisNCisJaWYgKGF2Z19ibG9nID4gbW9kX2NvbmcpIHsNCisv
KiAgYWJvdmUgbW9kZXJhdGUgY29uZ2VzdGlvbiBsZXZlbHMgKi8NCisJCXNv
ZnRuZXRfZGF0YVtjcHVdLmNuZ19sZXZlbD0gQkxHX0NOR19ISUdIOw0KKyNp
ZmRlZiBSQU5EX0xJRQ0KKwkJcmQ9bmV0X3JhbmRvbSgpOw0KKwkJcnE9cmQl
IG5ldGRldl9tYXhfYmFja2xvZzsNCisJCWlmIChycSA8IGF2Z19ibG9nKSAv
KiB1bmx1Y2t5IGJhc3RhcmQgKi8NCisJCQlzb2Z0bmV0X2RhdGFbY3B1XS5j
bmdfbGV2ZWw9QkxHX0NOR19EUk9QOw0KKyNlbmRpZg0KKwl9IGVsc2UgaWYg
KGF2Z19ibG9nID4gbG9fY29uZykgew0KKwkJc29mdG5ldF9kYXRhW2NwdV0u
Y25nX2xldmVsPSBCTEdfQ05HX01PRDsNCisjaWZkZWYgUkFORF9MSUUNCisJ
CXJkPW5ldF9yYW5kb20oKTsNCisJCXJxPXJkJSBuZXRkZXZfbWF4X2JhY2ts
b2c7DQorCQkJaWYgKHJxIDwgYXZnX2Jsb2cpIC8qIHVubHVja3kgYmFzdGFy
ZCAqLw0KKwkJCQlzb2Z0bmV0X2RhdGFbY3B1XS5jbmdfbGV2ZWw9QkxHX0NO
R19ISUdIOw0KKyNlbmRpZg0KKwl9IGVsc2UgaWYgKGF2Z19ibG9nID4gbm9f
Y29uZykgDQorCQlzb2Z0bmV0X2RhdGFbY3B1XS5jbmdfbGV2ZWw9IEJMR19D
TkdfTE9XOw0KKwllbHNlICAvKiBubyBjb25nZXN0aW9uICovDQorCQlzb2Z0
bmV0X2RhdGFbY3B1XS5jbmdfbGV2ZWw9QkxHX0NOR19OT05FOw0KKw0KKwlz
b2Z0bmV0X2RhdGFbY3B1XS5hdmdfYmxvZz1hdmdfYmxvZzsNCisNCit9DQor
DQorI2lmZGVmIG9mZmxpbmVfc2FtcA0KK3N0YXRpYyB2b2lkIHNhbXBsZV9x
dWV1ZSh1bnNpZ25lZCBsb25nIGR1bW15KQ0KK3sNCisvKiAxMCBtcyAwciAx
bXMgLS0gaSBkb250IGNhcmUgLS0gSkhTICovDQorCWludCBuZXh0X3RpY2s9
MTsNCisJaW50IGNwdT1zbXBfcHJvY2Vzc29yX2lkKCk7DQorCWdldF9zYW1w
bGVfc3RhdHMoY3B1KTsNCisJbmV4dF90aWNrKz1qaWZmaWVzOw0KKwltb2Rf
dGltZXIoJnNhbXBfdGltZXIsIG5leHRfdGljayk7DQorfQ0KKyNlbmRpZg0K
Kw0KKw0KIC8qKg0KICAqCW5ldGlmX3J4CS0JcG9zdCBidWZmZXIgdG8gdGhl
IG5ldHdvcmsgY29kZQ0KICAqCUBza2I6IGJ1ZmZlciB0byBwb3N0DQpAQCAt
MTAyMiw5ICsxMDkzLDE4IEBADQogICoJdGhlIHVwcGVyIChwcm90b2NvbCkg
bGV2ZWxzIHRvIHByb2Nlc3MuICBJdCBhbHdheXMgc3VjY2VlZHMuIFRoZSBi
dWZmZXINCiAgKgltYXkgYmUgZHJvcHBlZCBkdXJpbmcgcHJvY2Vzc2luZyBm
b3IgY29uZ2VzdGlvbiBjb250cm9sIG9yIGJ5IHRoZSANCiAgKglwcm90b2Nv
bCBsYXllcnMuDQorICogICAgICANCisgKglyZXR1cm4gdmFsdWVzOg0KKyAq
CUJMR19DTkdfTk9ORQkobm8gY29uZ2VzdGlvbikgICAgICAgICAgIA0KKyAq
CUJMR19DTkdfTE9XICAgICAobG93IGNvbmdlc3Rpb24pIA0KKyAqCUJMR19D
TkdfTU9EICAgICAobW9kZXJhdGUgY29uZ2VzdGlvbikNCisgKglCTEdfQ05H
X0hJR0ggICAgKGhpZ2ggY29uZ2VzdGlvbikgDQorICoJQkxHX0NOR19EUk9Q
ICAgIChwYWNrZXQgd2FzIGRyb3BwZWQpDQorICogICAgICANCisgKiAgICAg
IA0KICAqLw0KIA0KLXZvaWQgbmV0aWZfcngoc3RydWN0IHNrX2J1ZmYgKnNr
YikNCitpbnQgbmV0aWZfcngoc3RydWN0IHNrX2J1ZmYgKnNrYikNCiB7DQog
CWludCB0aGlzX2NwdSA9IHNtcF9wcm9jZXNzb3JfaWQoKTsNCiAJc3RydWN0
IHNvZnRuZXRfZGF0YSAqcXVldWU7DQpAQCAtMTA0Myw2ICsxMTIzLDcgQEAN
CiAJbmV0ZGV2X3J4X3N0YXRbdGhpc19jcHVdLnRvdGFsKys7DQogCWlmIChx
dWV1ZS0+aW5wdXRfcGt0X3F1ZXVlLnFsZW4gPD0gbmV0ZGV2X21heF9iYWNr
bG9nKSB7DQogCQlpZiAocXVldWUtPmlucHV0X3BrdF9xdWV1ZS5xbGVuKSB7
DQorDQogCQkJaWYgKHF1ZXVlLT50aHJvdHRsZSkNCiAJCQkJZ290byBkcm9w
Ow0KIA0KQEAgLTEwNTQsMTEgKzExMzUsMTYgQEANCiAJCQlfX3NrYl9xdWV1
ZV90YWlsKCZxdWV1ZS0+aW5wdXRfcGt0X3F1ZXVlLHNrYik7DQogCQkJX19j
cHVfcmFpc2Vfc29mdGlycSh0aGlzX2NwdSwgTkVUX1JYX1NPRlRJUlEpOw0K
IAkJCWxvY2FsX2lycV9yZXN0b3JlKGZsYWdzKTsNCi0JCQlyZXR1cm47DQor
I2lmbmRlZiBvZmZsaW5lX3NhbXANCisJCQlnZXRfc2FtcGxlX3N0YXRzKHRo
aXNfY3B1KTsNCisjZW5kaWYNCisJCQlyZXR1cm4gc29mdG5ldF9kYXRhW3Ro
aXNfY3B1XS5jbmdfbGV2ZWw7DQorDQogCQl9DQogDQogCQlpZiAocXVldWUt
PnRocm90dGxlKSB7DQogCQkJcXVldWUtPnRocm90dGxlID0gMDsNCisNCiAj
aWZkZWYgQ09ORklHX05FVF9IV19GTE9XQ09OVFJPTA0KIAkJCWlmIChhdG9t
aWNfZGVjX2FuZF90ZXN0KCZuZXRkZXZfZHJvcHBpbmcpKQ0KIAkJCQluZXRk
ZXZfd2FrZXVwKCk7DQpAQCAtMTA4MCw2ICsxMTY2LDggQEANCiAJbG9jYWxf
aXJxX3Jlc3RvcmUoZmxhZ3MpOw0KIA0KIAlrZnJlZV9za2Ioc2tiKTsNCisJ
cmV0dXJuIEJMR19DTkdfRFJPUDsNCisNCiB9DQogDQogLyogRGVsaXZlciBz
a2IgdG8gYW4gb2xkIHByb3RvY29sLCB3aGljaCBpcyBub3QgdGhyZWFkZWQg
d2VsbA0KQEAgLTEyOTIsMTIgKzEzODAsMjggQEANCiANCiAJCWlmIChidWdk
ZXQtLSA8IDAgfHwgamlmZmllcyAtIHN0YXJ0X3RpbWUgPiAxKQ0KIAkJCWdv
dG8gc29mdG5ldF9icmVhazsNCisNCisvKiANCisqLw0KKyNpZmRlZiBDT05G
SUdfTkVUX0hXX0ZMT1dDT05UUk9MDQorCWlmIChxdWV1ZS0+dGhyb3R0bGUg
JiYgcXVldWUtPmlucHV0X3BrdF9xdWV1ZS5xbGVuIDwgbm9fY29uZ190aHJl
c2ggKSB7DQorCQlpZiAoYXRvbWljX2RlY19hbmRfdGVzdCgmbmV0ZGV2X2Ry
b3BwaW5nKSkgIHsNCisJCQlxdWV1ZS0+dGhyb3R0bGUgPSAwOw0KKwkJCW5l
dGRldl93YWtldXAoKTsNCisJCQlnb3RvIHNvZnRuZXRfYnJlYWs7DQorCQl9
DQorDQorCX0NCisjZW5kaWYNCisNCisNCiAJfQ0KIAlicl9yZWFkX3VubG9j
ayhCUl9ORVRQUk9UT19MT0NLKTsNCiANCiAJbG9jYWxfaXJxX2Rpc2FibGUo
KTsNCiAJaWYgKHF1ZXVlLT50aHJvdHRsZSkgew0KIAkJcXVldWUtPnRocm90
dGxlID0gMDsNCisNCiAjaWZkZWYgQ09ORklHX05FVF9IV19GTE9XQ09OVFJP
TA0KIAkJaWYgKGF0b21pY19kZWNfYW5kX3Rlc3QoJm5ldGRldl9kcm9wcGlu
ZykpDQogCQkJbmV0ZGV2X3dha2V1cCgpOw0KQEAgLTI0MTgsNiArMjUyMiw3
IEBADQogaW50IF9faW5pdCBuZXRfZGV2X2luaXQodm9pZCkNCiB7DQogCXN0
cnVjdCBuZXRfZGV2aWNlICpkZXYsICoqZHA7DQorDQogCWludCBpOw0KIA0K
ICNpZmRlZiBDT05GSUdfTkVUX1NDSEVEDQpAQCAtMjQzNCw2ICsyNTM5LDgg
QEANCiAJCXF1ZXVlID0gJnNvZnRuZXRfZGF0YVtpXTsNCiAJCXNrYl9xdWV1
ZV9oZWFkX2luaXQoJnF1ZXVlLT5pbnB1dF9wa3RfcXVldWUpOw0KIAkJcXVl
dWUtPnRocm90dGxlID0gMDsNCisJCXF1ZXVlLT5jbmdfbGV2ZWwgPSAwOw0K
KwkJcXVldWUtPmF2Z19ibG9nID0gMTA7IC8qIGFyYml0cmFyeSBub24temVy
byAqLw0KIAkJcXVldWUtPmNvbXBsZXRpb25fcXVldWUgPSBOVUxMOw0KIAl9
DQogCQ0KQEAgLTI0NDIsNiArMjU0OSwxMiBAQA0KIAlORVRfUFJPRklMRV9S
RUdJU1RFUihkZXZfcXVldWVfeG1pdCk7DQogCU5FVF9QUk9GSUxFX1JFR0lT
VEVSKHNvZnRuZXRfcHJvY2Vzcyk7DQogI2VuZGlmDQorDQorI2lmZGVmIG9m
ZmxpbmVfc2FtcA0KKwlzYW1wX3RpbWVyLmV4cGlyZXM9amlmZmllcysoMTAg
KiBIWik7DQorCWFkZF90aW1lcigmc2FtcF90aW1lcik7DQorI2VuZGlmDQor
DQogCS8qDQogCSAqCUFkZCB0aGUgZGV2aWNlcy4NCiAJICoJSWYgdGhlIGNh
bGwgdG8gZGV2LT5pbml0IGZhaWxzLCB0aGUgZGV2IGlzIHJlbW92ZWQNCkBA
IC0yNDk5LDYgKzI2MTIsNyBAQA0KICNpZmRlZiBDT05GSUdfUFJPQ19GUw0K
IAlwcm9jX25ldF9jcmVhdGUoImRldiIsIDAsIGRldl9nZXRfaW5mbyk7DQog
CWNyZWF0ZV9wcm9jX3JlYWRfZW50cnkoIm5ldC9zb2Z0bmV0X3N0YXQiLCAw
LCAwLCBkZXZfcHJvY19zdGF0cywgTlVMTCk7DQorDQogI2lmZGVmIFdJUkVM
RVNTX0VYVA0KIAlwcm9jX25ldF9jcmVhdGUoIndpcmVsZXNzIiwgMCwgZGV2
X2dldF93aXJlbGVzc19pbmZvKTsNCiAjZW5kaWYJLyogV0lSRUxFU1NfRVhU
ICovDQotLS0gbGludXgvaW5jbHVkZS9saW51eC9uZXRkZXZpY2UuaC5vcmln
CUZyaSBTZXAgIDggMTU6NTM6NTMgMjAwMA0KKysrIGxpbnV4L2luY2x1ZGUv
bGludXgvbmV0ZGV2aWNlLmgJVHVlIFNlcCAxMiAyMDowMToyNSAyMDAwDQpA
QCAtNDcsNiArNDcsMTMgQEANCiAJCQkJCSAgIChUQyB1c2Ugb25seSAtIGRl
dl9xdWV1ZV94bWl0DQogCQkJCQkgICByZXR1cm5zIHRoaXMgYXMgTkVUX1hN
SVRfU1VDQ0VTUykgKi8NCiANCisvKiBCYWNrbG9nIGNvbmdlc3Rpb24gbGV2
ZWxzICovDQorI2RlZmluZSBCTEdfQ05HX05PTkUJCTEgICAvKiBrZWVwICdl
bSBjb21pbmcsIGJhYnkgKi8NCisjZGVmaW5lIEJMR19DTkdfTE9XCQkyICAg
Lyogc3Rvcm0gYWxlcnQsIGp1c3QgaW4gY2FzZSAqLw0KKyNkZWZpbmUgQkxH
X0NOR19NT0QJCTMgICAvKiBTdG9ybSBvbiBpdHMgd2F5ISAqLw0KKyNkZWZp
bmUgQkxHX0NOR19ISUdICQk1ICAgLyogVGhlIFRzdW5hbWkgaXMgaGVyZSwg
Ym95cyBhbmQgZ2lybHMgKi8NCisjZGVmaW5lIEJMR19DTkdfRFJPUAkJLTEg
IC8qIHRvbyBsYXRlLG1vbiBhbWkhIHBhY2tldCBkcm9wcGVkICovDQorDQog
I2RlZmluZSBuZXRfeG1pdF9lcnJubyhlKQkoKGUpICE9IE5FVF9YTUlUX0NO
ID8gLUVOT0JVRlMgOiAwKQ0KIA0KICNlbmRpZg0KQEAgLTQ0MCw2ICs0NDcs
OCBAQA0KIHN0cnVjdCBzb2Z0bmV0X2RhdGENCiB7DQogCWludAkJCXRocm90
dGxlOw0KKwlpbnQJCQljbmdfbGV2ZWw7DQorCWludAkJCWF2Z19ibG9nOw0K
IAlzdHJ1Y3Qgc2tfYnVmZl9oZWFkCWlucHV0X3BrdF9xdWV1ZTsNCiAJc3Ry
dWN0IG5ldF9kZXZpY2UJKm91dHB1dF9xdWV1ZTsNCiAJc3RydWN0IHNrX2J1
ZmYJCSpjb21wbGV0aW9uX3F1ZXVlOw0KQEAgLTUyNiw3ICs1MzUsNyBAQA0K
IA0KIGV4dGVybiB2b2lkCQluZXRfY2FsbF9yeF9hdG9taWModm9pZCAoKmZu
KSh2b2lkKSk7DQogI2RlZmluZSBIQVZFX05FVElGX1JYIDENCi1leHRlcm4g
dm9pZAkJbmV0aWZfcngoc3RydWN0IHNrX2J1ZmYgKnNrYik7DQorZXh0ZXJu
IGludAkJbmV0aWZfcngoc3RydWN0IHNrX2J1ZmYgKnNrYik7DQogZXh0ZXJu
IGludAkJZGV2X2lvY3RsKHVuc2lnbmVkIGludCBjbWQsIHZvaWQgKik7DQog
ZXh0ZXJuIGludAkJZGV2X2NoYW5nZV9mbGFncyhzdHJ1Y3QgbmV0X2Rldmlj
ZSAqLCB1bnNpZ25lZCk7DQogZXh0ZXJuIHZvaWQJCWRldl9xdWV1ZV94bWl0
X25pdChzdHJ1Y3Qgc2tfYnVmZiAqc2tiLCBzdHJ1Y3QgbmV0X2RldmljZSAq
ZGV2KTsNCkBAIC02MjgsNiArNjM3LDcgQEANCiBleHRlcm4gdm9pZAkJbmV0
ZGV2X3VucmVnaXN0ZXJfZmMoaW50IGJpdCk7DQogZXh0ZXJuIGludAkJbmV0
ZGV2X21heF9iYWNrbG9nOw0KIGV4dGVybiB1bnNpZ25lZCBsb25nCW5ldGRl
dl9mY194b2ZmOw0KK2V4dGVybiBhdG9taWNfdCBuZXRkZXZfZHJvcHBpbmc7
DQogZXh0ZXJuIGludAkJbmV0ZGV2X3NldF9tYXN0ZXIoc3RydWN0IG5ldF9k
ZXZpY2UgKmRldiwgc3RydWN0IG5ldF9kZXZpY2UgKm1hc3Rlcik7DQogI2lm
ZGVmIENPTkZJR19ORVRfRkFTVFJPVVRFDQogZXh0ZXJuIGludAkJbmV0ZGV2
X2Zhc3Ryb3V0ZTsNCi0tLSAvdXNyL3NyYy9saW51eC9uZXQvbmV0c3ltcy5j
CTIwMDAvMDkvMTYgMjM6MDA6MzMJMS4xDQorKysgL3Vzci9zcmMvbGludXgv
bmV0L25ldHN5bXMuYwkyMDAwLzA5LzE2IDIzOjAxOjI4DQpAQCAtNDkwLDYg
KzQ5MCw3IEBADQogRVhQT1JUX1NZTUJPTChkZXZfaW9jdGwpOw0KIEVYUE9S
VF9TWU1CT0woZGV2X3F1ZXVlX3htaXQpOw0KICNpZmRlZiBDT05GSUdfTkVU
X0hXX0ZMT1dDT05UUk9MDQorRVhQT1JUX1NZTUJPTChuZXRkZXZfZHJvcHBp
bmcpOw0KIEVYUE9SVF9TWU1CT0wobmV0ZGV2X3JlZ2lzdGVyX2ZjKTsNCiBF
WFBPUlRfU1lNQk9MKG5ldGRldl91bnJlZ2lzdGVyX2ZjKTsNCiBFWFBPUlRf
U1lNQk9MKG5ldGRldl9mY194b2ZmKTsNCg==
---559023410-851401618-969327077=:3641--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/