Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(shwap/bitswap): Blockstore.GetSize: getting size with no compute #3894

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

Wondertan
Copy link
Member

@Wondertan Wondertan commented Oct 28, 2024

Bitswap prioritizes peers based on their active/pending work and the priority that peers set for requests(work) themselves. The prioritization happens on the Get operation of Blockstore not GetSize. However, we currently do the most expensive work in GetSize followed by Get. It is still part of the same WANT_BLOCK request(since #3813), and GetSize work is usually cached for Get to catch it. Still, the prioritization makes it so that the time between GetSize and Get can be pretty long, inducing cache misses and redoing the same work again, which is confirmed by profiles. Also, doing the expensive part in GetSize avoids Bitswap server's rate limiting.

All this brings the need to make GetSize as lightweight as possible, leaving actual proof computed to Get. This PR achieves this by only opening EDS and reading up its size, and then computing the expected size based on constants. The GetSize still does expensive file opening but avoids the precious computing to simply report the size of the data.

P.S. The RowNamespaceDataBlock still does the expensive compute as previously, as there is no easy way to get the size of RND data besides reading it. We could only do the reading part tho without computing rn by adding a new method to Accessor, but that's not worth it ATM.


🎱 mb blonks certified

@Wondertan Wondertan added the kind:fix Attached to bug-fixing PRs label Oct 28, 2024
@Wondertan Wondertan self-assigned this Oct 28, 2024
@Wondertan Wondertan force-pushed the shwap-bitswap-get-size branch 2 times, most recently from 2d98169 to 2bef3ec Compare October 28, 2024 14:42
@walldiss
Copy link
Member

If GetSize is used only for prioritisation of bitswap server hanling of requests, perhaps don't really need to calculate sizes. Alternative could be to return const values depending on type of the cid and our estimate of proper priority / load of handling. For examples:

  • samples: 100
  • rows: 10000 (much heavier and less important than namespace data)
  • namespace data: 5000

This would allow us to remove the need for heavy reads to get the priority for serving of requests and will easy the pressure on cache.

@Wondertan
Copy link
Member Author

In sync, we agreed to keep the Size computation based on real blocksize to be safe. Making all sizes fixed to max block size may limit bitswap's throughput for small block sizes.

Copy link
Member

@renaynay renaynay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you need additional tests for this? Are the changes already covered by some test suite?

@@ -71,6 +74,12 @@ func (sb *SampleBlock) Height() uint64 {
return sb.ID.Height
}

func (sb *SampleBlock) Size(ctx context.Context, acc eds.Accessor) (int, error) {
squareSize := acc.Size(ctx)
sampleSize := libshare.ShareSize + share.AxisRootSize*int(math.Log2(float64(squareSize)))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there no helper util we can use to determine proof size for a share based on dah?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not aware of such

@Wondertan
Copy link
Member Author

It is covered

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind:fix Attached to bug-fixing PRs
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants