bitswap: Bitswap now sends multiple blocks per message by taylormike · Pull Request #5 · ipfs/go-bitswap

taylormike · 2018-08-13T08:49:39Z

Updated PeerRequestTask to hold multiple wantlist.Entry(s). This allows Bitswap to send multiple blocks in bulk per a Peer's request. Also, added a metric for how many blocks to put in a given message. Currently: 512 * 1024 bytes.
Fixes #4378
@whyrusleeping @Stebalien

whyrusleeping · 2018-08-30T05:01:41Z

Hey @taylormike, sorry for the wait. New repos mean i wasnt watching for notifications.

Stebalien · 2018-08-21T22:59:17Z

decision/engine.go

 				newWorkExists = true
+				if blockSize, _ = e.bs.GetSize(entry.Cid); blockSize == -1 {
+					// Force Update Size Cache
+					e.bs.Get(entry.Cid)


This really shouldn't be necessary. GetSize should always work (even if it isn't cached).

@Stebalien I agree, I removed the 'GetSize, then Get, then GetSize sequence'
This is done. I pushed out these changes and squashed into a single commit.

Stebalien · 2018-08-21T23:00:45Z

decision/engine.go

+					activeEntries = []*wl.Entry{}
+					msgSize = 0
+				}
+				activeEntries = append(activeEntries, entry.Entry)


Shouldn't this be in an else condition?

This is intentional.
That being said, I can rewrite it as such:

if msgSize + blockSize < maxMessageSize { activeEntries = append(activeEntries, entry.Entry) msgSize += blockSize } else { e.peerRequestQueue.Push(p, activeEntries...) activeEntries = []*wl.Entry{} msgSize = 0 }

Stebalien · 2018-08-21T23:07:37Z

decision/peer_request_queue.go


 // Push currently adds a new peerRequestTask to the end of the list
-func (tl *prq) Push(entry *wantlist.Entry, to peer.ID) {
+func (tl *prq) Push(entries []*wantlist.Entry, to peer.ID) {


API nit: While we're changing this, I'd change it to Push(to peer.ID, entries ...*wantlist.Entry).

@Stebalien I agree.
This is done. I pushed out these changes and squashed into a single commit.

schomatis

Very clean, nice. The message size logic seems OK. (I'm not familiarized with the rest of the code.)

whyrusleeping · 2018-08-31T00:56:15Z

decision/engine.go

 		l.wantList = wl.New()
 	}

+	blockSize, msgSize := 0, 0


cleaner to write:

var blockSize, msgSize int

@whyrusleeping I agree.
This is done. I pushed out these changes and squashed into a single commit.

whyrusleeping · 2018-08-31T01:04:06Z

decision/engine.go

 			if exists, err := e.bs.Has(entry.Cid); err == nil && exists {
-				e.peerRequestQueue.Push(entry.Entry, p)
 				newWorkExists = true
+				if blockSize, _ = e.bs.GetSize(entry.Cid); blockSize == -1 {


I wouldnt throw away an error. If this actually errors, something seems pretty wrong. It's worthy of logging IMO

There was a previous mention from @Stebalien that GetSize wouldn't fail, but maybe we could add a comment there explaining it, since yes, that silent error seems suspicious.

This really shouldn't be necessary. GetSize should always work (even if it isn't cached).

Sorry, that statement was a bit confusing. I meant that if the Get worked, the GetSize should have worked. That is, we can just call:

size, err := e.bs.GetSize(entry.Cid) if err != nil { /* we don't have it, *may* be an error, check if it's bs.ErrNotFound */ } else { // we have the block }

We don't need to call GetSize, then Get, then GetSize.

@whyrusleeping, @schomatis, @schomatis I agree.
I removed the 'GetSize, then Get, then GetSize sequence' and I'm now logging the error.

This is done. I pushed out these changes and squashed into a single commit.

taylormike · 2018-09-06T02:51:52Z

I pushed out the most recent code review feedback changes and squashed into a single commit.
I also updated bench_test, peer_request_queue_test, and engine_test accordingly.

Stebalien

One small performance nit ~~and one slightly larger concern.~~

When testing this, it didn't appear to have much impact until I upped the fetch concurrency quite a bit. However, I've been wanting to do that for a while anyways. Once I did that, I noticed a ~20% speedup (not counting the speedup from the increased parallelism).

Also, I wasn't able to test in a real system. I expect this'll have quite a bit more impact on a network with many peers.

Stebalien · 2018-09-06T03:10:13Z

decision/engine.go

 			if exists, err := e.bs.Has(entry.Cid); err == nil && exists {
-				e.peerRequestQueue.Push(entry.Entry, p)
 				newWorkExists = true
+				if blockSize, err = e.bs.GetSize(entry.Cid); err != nil {


Actually, we should probably just use GetSize instead of Has. That way, we only make one request.

(that is, we can replace the Has check in the condition)

@Stebalien
I agree, I pushed out this change and squashed into a single commit.

Stebalien · 2018-09-06T03:36:48Z

decision/peer_request_queue.go

-func taskKey(p peer.ID, k *cid.Cid) string {
+func taskKey(p peer.ID, entries []*wantlist.Entry) string {
+	key := string(p)
+	for _, entry := range entries {


This is a bit unfortunate as it could grow quite large (very large). I wonder if we can switch to a different method for computing task keys.

Ah, I see. This isn't actually used. Mind removing it along with the Key() function?

@Stebalien Sorry for the delayed response.
This is done. I pushed out this change and squashed into a single commit.

Stebalien · 2018-09-06T04:18:52Z

I've tested this against go-ipfs and it doesn't appear to break anything.

Stebalien · 2018-09-06T04:28:51Z

It looks like the checkHandledInOrder test is broken.

taylormike · 2018-09-07T01:53:14Z

@Stebalien I'm looking into the checkHandledInOrder test failure.

taylormike · 2018-10-04T03:46:38Z

@Stebalien Sorry for the delayed response.
The checkHandledInOrder test failure is now resolved. I pushed out this change and squashed into a single commit.

Updated PeerRequestTask to hold multiple wantlist.Entry(s). This allows Bitswap to send multiple blocks in bulk per a Peer's request. Also, added a metric for how many blocks to put in a given message. Currently: 512 * 1024 bytes. License: MIT Signed-off-by: Jeromy <why@ipfs.io>

fixes bs.GetSize bug

Stebalien · 2018-10-04T17:10:56Z

Running the go-ipfs sharness tests now.

Stebalien · 2018-10-04T17:15:57Z

Looks good!

…dmultiple bitswap: Bitswap now sends multiple blocks per message This commit was moved from ipfs/go-bitswap@cbd7eb7

whyrusleeping requested review from Stebalien and schomatis August 30, 2018 05:01

whyrusleeping self-requested a review August 30, 2018 05:01

Stebalien reviewed Aug 30, 2018

View reviewed changes

schomatis approved these changes Aug 30, 2018

View reviewed changes

whyrusleeping reviewed Aug 31, 2018

View reviewed changes

taylormike force-pushed the feat/bitswap/sendmultiple branch from d501754 to 433f52e Compare September 6, 2018 02:14

Stebalien reviewed Sep 6, 2018

View reviewed changes

taylormike force-pushed the feat/bitswap/sendmultiple branch from 433f52e to bd8c0f4 Compare October 4, 2018 01:31

Stebalien force-pushed the feat/bitswap/sendmultiple branch from bd8c0f4 to eb0d1ff Compare October 4, 2018 16:08

ghost assigned Stebalien Oct 4, 2018

ghost added the status/in-progress In progress label Oct 4, 2018

gx: update go-ipfs-bitswap

409a3ec

fixes bs.GetSize bug

Stebalien merged commit cbd7eb7 into ipfs:master Oct 4, 2018

ghost removed the status/in-progress In progress label Oct 4, 2018

eingenito mentioned this pull request Oct 5, 2018

question: Why is single file transfer so slow ipfs/kubo#4838

Closed

Conversation

taylormike commented Aug 13, 2018

Uh oh!

whyrusleeping commented Aug 30, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

taylormike Sep 6, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

taylormike Sep 6, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

schomatis left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

taylormike commented Sep 6, 2018

Uh oh!

Stebalien left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Stebalien commented Sep 6, 2018

Uh oh!

Stebalien commented Sep 6, 2018

Uh oh!

taylormike commented Sep 7, 2018

Uh oh!

taylormike commented Oct 4, 2018

Uh oh!

Stebalien commented Oct 4, 2018

Uh oh!

Stebalien commented Oct 4, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

taylormike Sep 6, 2018 •

edited

Loading

taylormike Sep 6, 2018 •

edited

Loading

Stebalien left a comment •

edited

Loading