)]}'
{
  "commit": "be1925fb29c9b6d7356ee8c73fde7b88388f298f",
  "tree": "21f1c4363cff8270d0bee9c7ba04f8ca019b0066",
  "parents": [
    "3751ae416e9f90cff287396cfd0f59460d82fa15"
  ],
  "author": {
    "name": "Barret Rhoden",
    "email": "brho@cs.berkeley.edu",
    "time": "Thu Dec 14 16:23:59 2017 -0500"
  },
  "committer": {
    "name": "Barret Rhoden",
    "email": "brho@cs.berkeley.edu",
    "time": "Thu Dec 14 16:23:59 2017 -0500"
  },
  "message": "mlx4: Linearize large blocks to avoid dropping packets\n\nOn occasion I would get the \"Oversized header or SG list\" error.  It might\nhave been due to having too few TXBB slots for the number of fragments.\n\nOur TCP stack doesn\u0027t limit the number of EBDs it sends down the pipe yet.\nIn lieu of breaking the block into multiple blocks, we can linearize it.  I\nhad the same issue with r8169.\n\nThe longer term fixes:\n- Maybe a helper that breaks a block, but it\u0027d need to maintain the\n  headers, to include the length fields.\n- Peak at the first block in the queue or otherwise block until there is\n  enough room.  Need to be careful that we don\u0027t get a block that has more\nEBDs than the NIC has SG slots.\n- Give TCP (and other block producers) a way to know the max number of\n  EBDs.\n- Just use 16.\n\nI somewhat like the notion of having a limit and then have the helper break\nthe block at the appropriate layer, since you might not know where a block\nis going when you create it.  (Though TCP does - we do this with MSS\nalready).\n\nSigned-off-by: Barret Rhoden \u003cbrho@cs.berkeley.edu\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "ab51ae15e46110f165887911984aeea9d0773b42",
      "old_mode": 33188,
      "old_path": "kern/drivers/net/mlx4/en_tx.c",
      "new_id": "36db4ab6b49869afb4b257aacda346e790b4cb26",
      "new_mode": 33188,
      "new_path": "kern/drivers/net/mlx4/en_tx.c"
    }
  ]
}