Name: Ultra Ethernet Thoát khỏi Sự Hỗn Loạn của Trật Tự do UEC trình bày (Ultra Ethernet Escaping the Chaos of Order presented by UEC)
Uploaded: 2025-11-15T01:18:07.000Z
Duration: 16 min 59 s
Description: Thousands of YouTube videos with English-Chinese subtitles! Now you can learn to understand native speakers, expand your vocabulary, and improve your pronunciation...

Được rồi, chào mừng mọi người.

We're getting started a little bit earlier today.

Hôm nay chúng ta bắt đầu sớm hơn một chút.

Let's spend a minute talking about ultra Ethernet and how we're approaching networking differently.

Hãy dành một phút để nói về ultra Ethernet và cách chúng ta tiếp cận networking khác đi.

Basically, since the dawn of networking, people have been designing end to end transport protocols that assume the network in the middle is ordered.

Về cơ bản, kể từ khi networking ra đời, mọi người đã thiết kế các end to end transport protocols dựa trên giả định rằng mạng ở giữa là có thứ tự.

And as soon as they make that assumption, as soon as the ink's dry on the specification, the network engineers say, hey, it'd be a lot easier if we didn't have to maintain order going across the network.

Và ngay khi họ đưa ra giả định đó, ngay khi bản specification khô mực, các network engineers nói rằng, này, sẽ dễ dàng hơn nhiều nếu chúng ta không phải duy trì thứ tự khi đi qua mạng.

Và chúng ta lặp lại chu kỳ đó hết lần này đến lần khác.

And so we did a little something different in ultra Ethernet.

Vì vậy, chúng tôi đã làm một điều hơi khác biệt trong ultra Ethernet.

Okay, so a little bit about the consortium.

Được rồi, nói một chút về consortium.

We were formed in 2022, announced in 2023, fairly quickly opened up to a broader way of members, and

Chúng tôi được thành lập vào năm 2022, công bố vào năm 2023, khá nhanh chóng mở cửa cho nhiều thành viên hơn, và

Wow, nó phát triển nhanh thật đấy.

All of a sudden we were at 100 companies and we could feel it in the working groups.

Đột nhiên chúng tôi có 100 công ty và chúng tôi có thể cảm nhận được điều đó trong các working groups.

Sự tham gia vào các cuộc gọi trở nên rất lớn.

Our mission was not quite as bold as this when we first started.

Nhiệm vụ của chúng tôi không hề táo bạo như thế này khi chúng tôi mới bắt đầu.

I do not think anybody actually walked into this thinking we were going to a high performance full stack architecture.

Tôi không nghĩ bất kỳ ai thực sự tham gia vào đây với suy nghĩ chúng tôi sẽ xây dựng một high performance full stack architecture.

Nhưng đó là nơi chúng tôi đang ở ngày hôm nay.

If we look at what's going On Inside the UEC, we have created our first specification, release 1.0 in June of this year.

Nếu chúng ta nhìn vào những gì đang diễn ra bên trong UEC, chúng tôi đã tạo ra specification đầu tiên của mình, release 1.0 vào tháng 6 năm nay.

There's software working group work, there's results from the transport working group, the link working group, the physical layer working group one specification.

Có công việc của software working group, có kết quả từ transport working group, link working group, physical layer working group một specification.

Now, okay, so when you give these talks on behalf of an organization, you get some boilerplate slides, and

Bây giờ, được rồi, vì vậy khi bạn thực hiện các bài thuyết trình này thay mặt cho một tổ chức, bạn sẽ nhận được một số boilerplate slides, và

The spec is really not that big compared to other existing standards.

Bản specification này thực sự không quá lớn so với các tiêu chuẩn hiện có khác.

So if you open Infiniband, it is a 2000 plus page specification for volume one.

Vì vậy, nếu bạn xem Infiniband, đó là một specification hơn 2000 trang cho tập một.

And we do that because we're built on top of an ecosystem.

Và chúng tôi làm được điều đó vì chúng tôi được xây dựng dựa trên một hệ sinh thái.

We leverage Ethernet, we leverage ip, we leverage the switch ecosystems and the software ecosystems that are built around that.

Chúng tôi tận dụng Ethernet, chúng tôi tận dụng ip, chúng tôi tận dụng các hệ sinh thái switch và các hệ sinh thái phần mềm được xây dựng xung quanh đó.

So the thousands of pages that make up 802.3, the thousands of pages that make up 802.1, the thousands of RFCs that are out there from ITF, we build on top of that legacy and leverage that infrastructure.

Vì vậy, hàng nghìn trang tạo nên 802.3, hàng nghìn trang tạo nên 802.1, hàng nghìn RFC có sẵn từ ITF, chúng tôi xây dựng dựa trên di sản đó và tận dụng cơ sở hạ tầng đó.

So a little bit on why we exist, you know, RDMA is.

Vậy một chút về lý do chúng tôi tồn tại, bạn biết đấy, RDMA là.

Well, RDMA as we know it in verbs today is 25 years old now.

Chà, RDMA như chúng ta biết ngày nay với verbs đã 25 tuổi rồi.

Remote memory access has been around a lot longer than that.

Truy cập bộ nhớ từ xa đã có từ lâu hơn thế nhiều.

HPC has had remote memory access concepts baked into it for basically as long as there's been HPC networking.

HPC đã tích hợp các khái niệm truy cập bộ nhớ từ xa vào đó gần như là từ khi có mạng HPC.

There's a lot of performance to be achieved by Doing kernel bypass, networking hardware implementations of the whole protocol stack really low overhead things in the host.

Có rất nhiều hiệu suất có thể đạt được bằng cách bỏ qua kernel, các triển khai phần cứng mạng của toàn bộ ngăn xếp giao thức, những thứ có chi phí rất thấp trên máy chủ.

Rocky B2 is the RDMA over IP version of that story.

Rocky B2 là phiên bản RDMA qua IP của câu chuyện đó.

It was based on the InfiniBand specification which was standardized in 2000.

Nó dựa trên đặc tả InfiniBand được chuẩn hóa vào năm 2000.

And it has all the hallmarks of a network transport that was designed before the turn of the century.

Và nó có tất cả các đặc điểm của một phương thức truyền tải mạng được thiết kế trước khi bước sang thế kỷ mới.

Vì vậy, nó có thứ tự quay lại.

It does not have really a multi pathing definition.

Nó không có định nghĩa đa đường dẫn thực sự.

It doesn't include an integrated security Solution.

Nó không bao gồm giải pháp bảo mật tích hợp.

Back in 2000, nobody cared about security in high performance networks.

Vào năm 2000, không ai quan tâm đến bảo mật trong các mạng hiệu suất cao.

This was all designed in an era when transistors were precious.

Tất cả những thứ này được thiết kế trong một thời đại mà bóng bán dẫn còn rất quý giá.

And so you wanted to keep everything simple and it made sense at the time.

Vì vậy, bạn muốn giữ mọi thứ đơn giản và điều đó hợp lý vào thời điểm đó.

But as RDMA has aged, the industry had started to diverge in its solution space.

Nhưng khi RDMA đã cũ đi, ngành công nghiệp bắt đầu phân kỳ trong không gian giải pháp của mình.

So kind of the earliest thing you saw published in that domain was AWS with their SRD protocol spraying packets all over the network.

Vì vậy, thứ sớm nhất bạn thấy được công bố trong lĩnh vực đó là AWS với giao thức SRD của họ, gửi gói tin khắp mạng.

Google recently announced their Falcon protocol.

Google gần đây đã công bố giao thức Falcon của họ.

Those are not the only people who are building customized versions of rdma.

Đó không phải là những người duy nhất đang xây dựng các phiên bản RDMA tùy chỉnh.

And so it was time for new industry standard.

Vì vậy, đã đến lúc cần một tiêu chuẩn công nghiệp mới.

And everybody wants that standard to look and feel and interoperate like Ethernet.

Và mọi người đều muốn tiêu chuẩn đó trông giống và hoạt động tương tự như Ethernet.

So the problem with ordering is that it makes a real mess in the network.

Vấn đề với việc sắp xếp thứ tự là nó gây ra sự lộn xộn thực sự trong mạng.

So ordering means that you really can't see, can't tell the difference between real congestion and false congestion places where flows happen to collide because it's not really easy to move those flows.

Vì vậy, việc sắp xếp thứ tự có nghĩa là bạn thực sự không thể nhìn thấy, không thể phân biệt được tình trạng tắc nghẽn thực sự với các điểm tắc nghẽn giả, nơi các luồng tình cờ va chạm vì không dễ dàng di chuyển các luồng đó.

A flow takes one path through the network.

Một luồng đi theo một đường dẫn qua mạng.

If it happens to hit somebody else, well, even if you did load balancing at the start, you're just kind of out of luck.

Nếu nó tình cờ đụng phải người khác, thì ngay cả khi bạn đã cân bằng tải ngay từ đầu, bạn cũng đành chịu.

So we can take a look at some examples here.

Vì vậy, chúng ta có thể xem xét một vài ví dụ ở đây.

If you noticed, I built my example factory here with seven port switches so that I can have a four to three taper.

Nếu bạn để ý, tôi đã xây dựng nhà máy ví dụ của mình ở đây với các switch bảy cổng để tôi có thể có tỷ lệ thu hẹp từ bốn xuống ba.

Vì vậy, tôi có thể đưa ra ví dụ này cho bạn.

So in the bandwidth taper case, everybody on one switch talks to everybody on the next switch that goes over three paths.

Vì vậy, trong trường hợp thu hẹp băng thông, mọi người trên một switch nói chuyện với mọi người trên switch tiếp theo đi qua ba đường dẫn.

For four flows, two of those flows are going to take the same path.

Đối với bốn luồng, hai trong số các luồng đó sẽ đi cùng một đường dẫn.

And so your application's going to run half as fast because two of those flows took the same path.

Và do đó, ứng dụng của bạn sẽ chạy chậm đi một nửa vì hai trong số các luồng đó đi cùng một đường dẫn.

And so they're effectively running half as fast.

Và vì vậy, chúng chạy chậm đi một nửa.

You can't tell the difference between NCAST and a bandwidth taper in this ordered network, that one is really going to run slower.

Bạn không thể phân biệt giữa NCAST và hiện tượng thu hẹp băng thông trong mạng có thứ tự này, cái này sẽ chạy chậm hơn nhiều.

Không còn cách nào khác bạn có thể làm.

You got false contention, you got two flows that just happen to pick the same uplink at the top of the network and now they're stuck because they're ordered flows.

Bạn gặp phải sự tranh chấp giả, hai luồng tình cờ chọn cùng một đường lên ở đỉnh mạng và giờ chúng bị kẹt vì chúng là các luồng có thứ tự.

And the reality is that people will tell you that you can stop and move flow and sure you can, but

Và thực tế là mọi người sẽ nói với bạn rằng bạn có thể dừng và di chuyển luồng và chắc chắn bạn có thể, nhưng

most of the flows, our notes so long that it's going to be a good idea to start a flow, realize there's contention, stop the flow, start the flow somewhere else and hope you didn't hit somebody else.

hầu hết các luồng, ghi chú của chúng tôi rất dài nên sẽ là một ý tưởng hay để bắt đầu một luồng, nhận ra có sự tranh chấp, dừng luồng, bắt đầu luồng ở nơi khác và hy vọng bạn không đụng ai khác.

Chúng ta đã đến đây bằng cách nào?

So kind of, why did we go and take a full stack approach to this problem?

Vậy tại sao chúng ta lại tiếp cận vấn đề này trên toàn bộ hệ thống?

Well, when you have a hammer, everything looks like a nail.

Chà, khi bạn có một cái búa, mọi thứ đều trông giống như một cái đinh.

So when you give an architect a connection, they're going to use it.

Vì vậy, khi bạn đưa cho một kiến trúc sư một kết nối, họ sẽ sử dụng nó.

They're going to use it and they're going to tangle it up with the semantics that are over top of it.

Họ sẽ sử dụng nó và họ sẽ làm rối nó với các ngữ nghĩa ở trên đó.

They're going to tangle it up with how you pick a buffer, they're going to tangle it up with how you manage resource exhaustion.

Họ sẽ làm rối nó với cách bạn chọn một bộ đệm, họ sẽ làm rối nó với cách bạn quản lý việc cạn kiệt tài nguyên.

There's no reason not to put the connection into an error state.

Không có lý do gì để không đặt kết nối vào trạng thái lỗi.

You've got one process connected to another process and it incurs some error, you might as well put the whole connection into an error state.

Bạn có một tiến trình kết nối với một tiến trình khác và nó gặp lỗi, bạn cũng nên đặt toàn bộ kết nối vào trạng thái lỗi.

You might as well couple the security to that connection state, because while you've got the connection there, you might as well use it.

Bạn cũng có thể ghép bảo mật vào trạng thái kết nối đó, bởi vì khi bạn có kết nối ở đó, bạn cũng có thể sử dụng nó.

Then when you make that connection ordered, well, then you'll get people who do clever things.

Sau đó, khi bạn làm cho kết nối đó có thứ tự, thì bạn sẽ có những người làm những điều thông minh.

I mean, you're going to use that ordering for liability.

Ý tôi là, bạn sẽ sử dụng việc sắp xếp thứ tự đó cho trách nhiệm pháp lý.

Bởi vì đó là điều đơn giản nhất để làm.

And then somebody's going to say, well, I don't really need this entire header on every packet and I can get 1% more efficiency by putting a different header on my first packet than my second packet and my third packet.

Và sau đó ai đó sẽ nói, ừm, tôi không thực sự cần toàn bộ tiêu đề này trên mọi gói tin và tôi có thể đạt hiệu quả thêm 1% bằng cách đặt một tiêu đề khác trên gói tin đầu tiên của mình so với gói tin thứ hai và gói tin thứ ba của mình.

Và vì vậy họ sẽ làm điều đó.

And your resource management will depend on that ordering.

Và việc quản lý tài nguyên của bạn sẽ phụ thuộc vào việc sắp xếp thứ tự đó.

And the ordering will be part of your error model.

Và việc sắp xếp thứ tự đó sẽ là một phần của mô hình lỗi của bạn.

And you'll say, well, this packet encountered an error, so every packet after it will encounter that error until somebody comes along and cleans up.

Và bạn sẽ nói, ừm, gói tin này gặp lỗi, vì vậy mọi gói tin sau nó sẽ gặp lỗi đó cho đến khi ai đó đến và khắc phục.

And this is the state of the world in the the Rocky V2 specification.

Và đây là tình hình hiện tại trong bản specification Rocky V2.

And by the time you realize what's happened and you've made that visible to software and given it software to manage, well, you've dug yourself in a hole that's kind of hard to get out of.

Và đến lúc bạn nhận ra điều gì đã xảy ra và bạn đã làm cho phần mềm nhìn thấy điều đó và cung cấp cho nó phần mềm để quản lý, thì bạn đã tự đào một cái hố mà khá khó để thoát ra.

Vậy chúng ta tiếp cận điều đó khác đi như thế nào?

Well, the most important thing is we did not change the application, we didn't change the frameworks we use, we didn't change the middleware libraries that you use, we didn't change Ethernet and ip.

Chà, điều quan trọng nhất là chúng ta không thay đổi ứng dụng, chúng ta không thay đổi các framework mà chúng ta sử dụng, chúng ta không thay đổi các thư viện middleware mà bạn sử dụng, chúng ta không thay đổi Ethernet và ip.

This will run over the data center network as it exists today.

Điều này sẽ chạy trên mạng trung tâm dữ liệu như hiện tại.

It will use the same software stacks that exist today.

Nó sẽ sử dụng các software stacks giống như hiện tại.

But from there it kind of goes like the fable of stone soup.

Nhưng từ đó nó giống như câu chuyện ngụ ngôn về món súp đá.

So these two Hungry travelers show up in a village, nobody will give them something to eat.

Thế là hai lữ khách đang đói bụng ghé vào một ngôi làng, không ai cho họ thứ gì để ăn.

So they take a pot or a JDF and they put a stone in it and some water or ethernet and IP and, and

Thế là họ lấy một cái nồi hoặc một JDF, bỏ một viên đá vào đó và một ít nước hoặc ethernet và IP, rồi

they start to boil it and people say, what are you doing?

họ bắt đầu đun sôi và mọi người hỏi, các bạn đang làm gì vậy?

Họ nói, chúng tôi đang làm món súp đá.

So the story progresses on until they managed to actually make a soup that everybody would like to eat.

Câu chuyện cứ tiếp diễn cho đến khi họ làm ra được món súp mà ai cũng muốn ăn.

Và đó là những gì chúng tôi đã làm ở đây.

We took LibFabric, which is an open source API.

Chúng tôi đã sử dụng LibFabric, một API mã nguồn mở.

Nó được thiết kế để không cần kết nối.

Subtitles ListPlay Video

Ultra Ethernet Thoát khỏi Sự Hỗn Loạn của Trật Tự do UEC trình bày (Ultra Ethernet Escaping the Chaos of Order presented by UEC)

process

access

impact

achieve