How to receive a million packets per second
Last week during a casual conversation I overheard a colleague saying: "The Linux network stack is slow! You can't expect it to do more than 50 thousand packets per second per core!" That got me thinking. While I agree that 50kpps per core is probably the limit for any practical application, what is the Linux networking stack capable of? Let's rephrase that to make it more fun: On Linux, how hard
コラム - クラウド時代のオープンソース実践活用 | 第53回 NFVとIntel DPDK（前編）｜CTC教育サービス 研修/トレーニング
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes 第53回 NFVとIntel DPDK（前編） (中井悦司) 2014年10月 はじめに 先週、Red Hat Forum 2014/Tokyoで日本のオフィスに来ていたChris Wrightと会話をする機会があり、Intel DPDKについて、いろいろ教えてもらいました。Chrisは、以前は、Linuxカーネルや仮想化（Xen/KVM）の開発に深く関わっていましたが、現在は、「Technical Director of SDN at Red Hat」という肩書で、SDN関係の仕事をしています。OpenDaylightのボードメンバーやOpenStackのNFVサブチームにも参加しています。 Intel DPDKの話題になったのは、まさにこの
MII監視からARP監視によるボンディング切り替えへの変更方法
サーバのボンディング(bonding)の切り替えが起きず、 トラフィックを処理できない事象が発生した。 問題への対応を検討する。 ◆ 障害内容 サーバ側で、ボンディングのActive-Backup モード(mode=1)を利用し、 障害の検知方法としてMII監視を使っていた。 しかし、L2スイッチがリンクがアップしている状態で故障したため、 サーバ側では異常を検知できなかった。 その結果サーバ側での経路切り替えが起きず、トラフィックを処理できなくなった。 L2SW L2SW | ⇒ × | 左経路から右経路にbonding切り替えが起きない SERVER ◆ ボンディング切り替えの監視方法の変更絵検討 ボンディングのActive-Backup モード (mode=1) では障害の監視方法として MII監視とARP監視の２通りの設定がある。 ボンディングを切り替えるためのトリガ
Linux packet-forwarding
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
10GbE Adapter Iperf Performance Test Results
This testing looked at iperf performance and CPU utilization (using vmstat) of the Neterion Xframe1 and the Intel IXGB 10GbE adapters. I tested different sysctl and MMRBC parameters along with varying numbers and directions of flows. Summary: In the best case of single stream, single direction throughput, the Xframe1 sustained ~6.4Gb/s. The IXGB sustained 5.6-5.9Gb/s. CPU utilization was high for
Linux TCP Tuning
The aim of this post is to point out potential kernel tunables that might improve network performance in certain scenarios. As with any other post on the subject, make sure you test before and after you make an adjustment to have a measurable, quantitative result. For the most part, the kernel is smart enough to detect and adjust certain TCP options after boot, or even dynamically, e.g the Sliding
同じサブネットへのNIC 2枚指し、またはソースルーティングのおはなし - （ひ）メモ
「NIC 2枚刺し」というと「IP masqueradeを使ってLinuxでルーターを作ろう！」的な話を思い出す老害です。こんにちは。 NICを2枚生やしたサーバーから同じサブネットに両方の足をのばす機会があったのですが、じゃっかん躓いたのでそのメモです。 具体的にいうと、eth0の方は問題ないのですが、eth1についているIPアドレスへの疎通ができない、というものでした。 以下、 eth0についているIPアドレスが10.0.0.10 eth1についているIPアドレスが10.0.0.11 対向の別サーバーが10.0.0.100 という体で読んでください。 さて、 別サーバーからpingしつつ、eth1でtcpdumpしてみると、echo requestは届いているのが観測できました。が、echo replyを返していません。 # tcpdump -i eth1 -nl icmp liste
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
1.1. UEKについて
2010年9月に、オラクル社は、Oracle Linux 5を使用したデプロイメントに推奨されるカーネルとしてOracle Linux用の新しいUnbreakable Enterprise Kernel (UEK)を公開しました。Oracle Linux 5.5以降から、Red Hat互換カーネルまたはUEKのいずれかを使用できるようになりました。Oracle Linux 5.6で、UEKはデフォルト・カーネルになりました。 UEK作成の主な動機は、ExadataおよびExalogicによってエンジニアリングされたシステム用の高性能な最新のLinuxカーネルを提供することでした。カーネルは、CPUの数、メモリーおよびインフィニバンド接続の増加に応じてスケーリングする必要がありました。 オラクル社では、負荷の高いOracleワークロードで集中的にUEKをテストしており、UEKをOracleデ
Understanding TCP/IP Network Stack & Writing Network Apps | CUBRID blog
What We Write Understanding TCP/IP Network Stack & Writing Network Apps We cannot imagine Internet service without TCP/IP. All Internet services we have developed and used at NHN are based on a solid basis, TCP/IP. Understanding how data is transferred via the network will help you to improve performance through tuning, troubleshooting, or introduction to a new technology. This article will descri
Velocity 2013 TCP Tuning for the Web
Our Sr. Web Operations Engineer, Justin Lintz, goes over some parameters we tuned in TCP and NGINX to improve the performance and stability of our systems. These slides are a complement to a two part blog post found over on our engineering blog. http://engineering.chartbeat.com/2014/01/02/part-1-lessons-learned-tuning-tcp-and-nginx-in-ec2/ http://engineering.chartbeat.com/2014/02/12/part-2-lessons
Queueing in the Linux Network Stack
[A slightly shorter and edited version of this article appeared in the July 2013 issue of Linux Journal. Thanks to Linux Journal’s great copyright policy I’m still allowed to post this on my site. Go here to subscribe to Linux Journal.] Packet queues are a core component of any network stack or device. They allow for asynchronous modules to communicate, increase performance and have the side affec
Linuxカーネルにおけるネットワークスタック周りのChangeLog勉強メモ (2.6.0 ~ 2.6.20) - ゆううきブログ
最近，OSのネットワークスタックに興味があって，Linuxカーネルのネットワークスタック実装の変遷について調べてみた． 変更内容の粒度は割りと適当． TCPとかFireWallとかNIC周りは興味があるのでだいたい書いてる． Wireless系は興味ないので全部削ってる． ネットワークスタック周りだけでもかなり量が多かったので，とりあえず2.6.0から2.6.20までをまとめた． Linux 2.6.x 2.6.5 (2004/04/04) http://kernelnewbies.org/Linux_2_6_5 Netpoll infrastructure Netpollが導入された． Netpollは，I/Oシステムとネットワークシステムが完全には利用できないみたいな不安定な環境でカーネルがパケットを送受信できる仕組みのこと．受信したパケットがnetpoll宛かどうかをTCP/IPのヘ
送受信 - Linuxカーネルメモ
1. 受信処理 1.1 従来の受信処理 ネットワークインタフェースで受信したパケットは、デバイスドライバのH/W割り込み処理処理で刈り取られる。デバイスドライバは受信したパケットをカーネルの受信キューに積み、ソフトウェア割り込みを発生させる。 受信ソフトウェア割り込みのハンドラは、受信キューに積まれているパケットを取りだし該当プロトコルの受信ハンドラを呼び出す。 デバイスドライバの受信処理が受信キューにパケットを積むだけで、受信処理のメインはソフトウェア割り込み処理で実装しているのは、H/W割り込みの処理を極力短くしてシステムのレスポンスを向上させるため。 受信処理の流れを図1に示す。 1. 従来の受信処理ではデバイスドライバがネットワーク層にパケットを渡す際、netif_rx()を使用する。 2. ソフトウェア割込みを発生させる際、poll_listには仮想的なnet_device(ba
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://github.com/xtao/PF_RING/blob/master/drivers/PF_RING_aware/intel/igb/igb-5.2.5-zc/README
Linux Base Driver for 10 Gigabit Intel(R) Ethernet Network Connection
インテル® 10GbE サーバ アダプタ用 Linux* ドライバ: インテル ネットワーク アダプタ ユーザガイド
api.satoru.net
Interrupt Coalescence - eduPERT KB - GÉANT federated confluence